かつて秘密情報は環境変数に追い出せと言われた
- ハードコードすんな、設定ファイルもダメだ
- これは OSS 化する際には絶対に必要な作法だが、認証情報の更新などの際に実際の動作には何も変更がないのにコード側を修正、再デプロイが必要になるという点でもイマイチ
- III. 設定 - The Twelve-Factor App （日本語訳）
Googleさんは環境変数に秘密情報をセットするなと言う
これは昔からそうで、
- 環境変数はプロジェクトの Read 権限さえあれば確認できたり
- 環境変数にセットする処理そのものがログに残ってしまう
ため。まぁ簡単に言うと Google のインフラの設計がそうなっているから。
昔からそうなんだけど、明言されているドキュメントは見つけにくい。改めて確認したところ、Cloud Run のドキュメントには書かれていることを発見できた。
注意: 環境変数をシークレットの保存と利用に使用しないでください。環境変数は、プロジェクト閲覧者以上の権限を持つユーザーに表示されます。代わりに、シークレットの使用ページの説明に沿って...
やりたいこと
実ブラウザを使い、認証が必要で API のないサイトから自動で必要な情報を取得し、それをチェックする処理を定期的に行いたい。
業務でもプライベー...
App Engineの自動再起動には超えるべきステップが二つある
- Google App Engine は Compute Engine のように素朴な VM ではないので OS 内部から再起動することはできない
- App Engine の instance は service, version で特定しないといけない
- App Engineには機能がないのでスケジュールは外部から与える必要がある
※ VM インスタンスの起動と停止をスケジュールする | Compute Engine ドキュメント | Google Cloud Compute Engine にはインスタンススケジュールがある
instanceの特定
App Engine の概要 | App Engine ドキュメント | Google C...
App Engineの定期実行で困っていたこと
Google App Engine でバッチジョブを動かしていて、ある時「何のエラーも出ていないが処理が止まってしまう」状態に遭遇した。いわゆるフリーズ / ストールしている状態。
そういや昔は Windows の OS そのものが連続何日間稼働で無反応になるだの、Webサーバが無反応になるだの色々あったけど、最近はこういうことに気を使う必要があるケースはほとんどなかったなーなどと思いながら、はてどうしたもんかと考えていた。
- このプロセスは24h稼働させっぱなしではなく、必要なタイミングに自動で起動して自動で終了する予定なので、常時外形監視のような形でエラーを拾うのもなかなか面倒な仕組みになってしまう1
- プロセスは何のログも吐かなくなってしまうので、プログラムコード自体を修正せずに中の情報を引き出すのは難しい
- 正常に動作しているログは逐一出力しているが、「特定のタイミングで一定時間以上正常なログが途切れている」みたいな条件での監視をアリもののサービスだけで実現するのはなかなか難しそう
<...
何を今さらシリーズ。
データの安全性、共有可能性には段階がある
「一部」のグレードがもっと細かくなるかどうかの違いはあるにせよ、基本は以下のような3段階になるはず。
- 一部の人のみ利用可能なデータ
- 一定までの配慮で共有可能なデータ
- 完全に公開、共有可能なデータ
データ共有が始まると共有物は無限に増える
多くの場合、組織は 1 ではなく 2 のグレーな状態のデータを扱っている。具体的にはさすがに社内限定くらいはなんとなく思っているが、特定の業務に携わっている人のみ限定して閲覧可能、みたいなもデータも当然増えてくる。（例えば個人情報、プライバシー情報など）
<figure c...
自分が何らかのソフトウェアシステムを考える際に意識していることを平易に、直感的に書き起こしておく試み。
何を当たり前のことを、と思われたなら成功。
やりたいこととシステムの立ち位置
本来システムはユーザーと目的によって最適解が異なる
目的の達成をシステムは支援する。
たまたま同じデータを利用すると同じシステムを解としたくなる
<figure class="j...
課題
command | original-filter上記のような pipe をまたいだ shell script を CI で利用していたが、前段のコマンドの失敗を exit status として伝えることができておらず、CI は常に succeed 扱いになっていた。
command は fail しているのに original-filter は succeed なので常に succeed 扱い。
解決
【POSIX準拠】set -o pipefailを使おう！ただしdash、テメーはダメだ #ShellScript - Qiita
がすべてなのだが、
- 昨今、便利なクラウドは Ubuntu ベースが多く、今回の CI も Ubuntu なため、
/bin/shを shebang に指定したスクリプトは（恐らく）dash で動いており、上の指定は意図通り動作しない- ということで改修箇所は以下の通り。
# /bin/bash set -o pipefail感想
dash なぁ…。bash や zsh を標準に...
今回やりたかったのは Cloud IAP という Google がいい具合に処理してくれる認証用の proxy サーバを Cloud Run の前段に置き、特定の人しかアクセスできないようにすること。
Cloud Run には直接 IAP を設定することができず、必要な準備がいくつかある。今回はこの実現のために必要な準備を確認した。
Cloud IAP, Cloud Load Balancingをおさらい
Cloud Run は Cloud Functions 同様、そもそも認証情報付きでしかアクセスできないようにすることもできるが、Cloud IAP ( Indentity-Aware Proxy ) はアカウント単位で許可する人を登録したり、Google Workspace と組み合わせてドメイン丸ごとに対して設定することで、社内限定公開のようなものをお手軽に実現できるスグレモノだ。ただし Cloud IAP を直接設定できるのは App Engine ( GAE ) だけで、それ以外は Cloud Load Balancing のアプリケーションロードバランサと組み合わせる必要がある。
Cloud Load Balancing には L7 アプリケーションロードバランサ（外部/内部）、L4 ネットワークロードバランサ（外部/内部、プロキシ/パススルー）があるが、今回利用するのは外部アプリケーションロードバランサになる。VPN を使わず、インターネ...
</div>
