cloud runついて
概要
- dockerのコンテナをデプロイして最小限の構成で動作させられるもの
- cloud functionより高級でkubernetesより低級
- 一回あたりの実行コストがとても安い
- 分散性能が高く、大量に並列に実行することに向いている
- コンテナの実行ユーザが
rootではない別の権限で動くことになる- PosixPathの
~や環境変数の$HOME,$USERなどは正常に動作しなくなるので、非依存にする必要がある
- PosixPathの
公式ドキュメント
動かすのに必要な権限
- cloud run admin
- cloud logging admin
- デプロイ・起動に関係ないように見えるが、この権限がないと起動することができない
- cloud storage作成・書き込み権限(コンテナレジストリが依存)
dockerのコンテナの配置先
- Container Registry
- Artifact Registry
シークレットの管理
- Cloud Runの環境変数に設定すると、シークレットとして扱われる
- バックエンドの実態はSecret Manager
デプロイ
リソースを指定しない場合
$ gcloud run deploy <my-api> --image=gcr.io/<my-project>/name
リソースを指定する場合
$ gcloud run deploy <my-api> --image=gcr.io/<my-project>/name \
--cpu=2 \
--max-instances=2 \
--memory=8G \
--min-instances=0 \
--timeout=300 \
--port=5050
ポートは環境変数で指定する
$PORTで公開ポートが指定できるほうが良いとされている- 例えば、
PORT=5050と設定したとしても、cloud run環境では必ずhttpsのデフォルトポート443にリダイレクトされる
gitからの継続デプロイ
- 別サービスの
cloud buildと連携する- 特定のgithub等のレポジトリの特定のブランチが更新されたらDockerfileを用いてbuild & pushするということができる
カスタムドメインのマッピング
cloud run->カスタムドメインを管理
アクセス制限
- IAMでアクセスを限定することができる
- httpsのheaderにIAMの秘密鍵から一時的な鍵を生成して認証に用いるという方式
- IP制限
- できない(ロードバランサを挟むとできる)
- よくあるヒューリスティック
- アクセス制限のセキュリティをなくして
X-Api-Keyで認証する
- アクセス制限のセキュリティをなくして
IAMでのアクセス制限の具体例
curlでアクセスする場合
$ curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://*****.run.app
requestsを用いる場合
TOKEN = os.popen("gcloud auth print-identity-token").read().strip()
headers = {"x-api-key": "<any plane secret key.>", "Authorization": f"Bearer {TOKEN}"}
params = {"hoo": "bar"}
with requests.post(URL, json=params, headers=headers) as r:
print(r.text) # 結果を得る
コーナーケースの挙動
メモリーのオーバーフローが発生するとき
- コンテナがシャットダウンされる
- cloud loggingにはログが出力されるので、原因不明にはならない
- ステータスコードが
503になる
非同期APIのとき
- APIサーバが値を戻した時点でコンテナがシャットダウンされる
- なにかコンテナがシャットダウンされないようにする仕組みもあるようである