bon now

Cloud RunはKubernetesのPodと違い、気軽に外側からSSHとかでログインできない仕様になっている。なのでCloud Runで原因不明な不具合が起きてしまってサービスが止まってしまった場合、どうにかして当該コンテナイメージを使ってデバッグをするしかない。
ローカル環境やステージング環境でやればいいんじゃないですか？っていう意見もあると思うが、本番環境だけ特定の環境変数が違うとか連携しているサービスが違うとか割とあるんじゃないだろうか。 そういうわけで、僕の会社では検証用のサーバーをGCE+Dockerで立ち上げることにした。

前提

• Ruby on RailsのアプリがCloud Runで動いている
• Secret Manager使ってる
• Cloud SQLをVPCに置いていて外部疎通できないようにしている
• スクリプトを実行するGCEでgcloudコマンドが使えてCloud Runの存在するプロジェクトにアクセスできる

困ったこと

サーバーをGCE+Dockerで立ち上げる事自体はとても簡単で、GCEの内部からGoogle Container RegistryやGoogle Artifact Registryからイメージを落としてきて起動するだけで良い。問題は 環境変数 である。

本番サーバーの環境変数は、大体はHashicorpのVaultやその他類似製品によって暗号化された先のサービスに保存されているんじゃないかと思う。
今回はGoogle Secret Managerに保存していたわけでまぁあまり変わらない構成。

その他、別に秘匿性のない環境変数においても、TerraformやCloud Build、Cloud Runに環境変数を仕込んでことは割と多いだろう。というかそうするしかない。そして、サービスの規模が大きくなれば大きくなるほど、あるいはマイクロサービスとして切り出されれば切り出されるほど、気づかないうちに知らない環境変数が追加されているということが増えてくる。

解決策

正しい環境変数を毎回GCE+Dockerに設定しつつ同期するのは面倒くさい。そこで、さっきまで起動していたCloud Runから環境変数をぶっこ抜いてくればイケるんじゃね？というのが今回のネタ。導線が長かったがここから本題。

ということで1日で付け焼き刃的に作ったコードが以下。 <your-clou-run-service-name> のところを、環境変数が欲しいCloud Runのサービス名に置換すれば多分動いてくれるはず。

課題

• 改行を含んだSecret Managerの値に対応してない

改行が入ってると7行目あたりでおかしくなる。逆ポーランド記法使って末尾が \n か \r か \r\n だった場合、 { や } の対応を数えつつループすれば多分できるけどやってない。
どういうときに困るかと言うと、例えば環境変数にServiceAccountのキーとなるJSON文字列を改行込みで格納してるときとか。

まとめ

このときはなんかひらめきとコピペ力が高くて生産性が高かった気がする。多分今もっかいやって！と言われるとできない。
ただ、Rubyの Tempfile を使ってるところは意識してやっていて、もともとこいつを知ったのは昔「ファイルをZipで複数枚アップロードしてもらった時、それを解凍してループしながら処理する」とかいう要件の実装をする際に、解凍したファイルを一時的にどこに置くかを考えたとき。
あとCSVを出力するとき、1000行単位で処理したデータを一旦保存する先としても使った記憶がある。Tempfileが便利なのは、処理後にキレイに消えてディスク容量が空くことと、メモリを逼迫せずに済むこと。特に大量CSVを吐き出すという要件の場合は割と選択肢として上がりやすいのではないだろうか。まぁ最近は大容量のメモリを確保できるので問題ない場面は割と多いかもしれないが……。

誰かの参考になれば幸いです。