TL;DR
- Cloud Runのデプロイが突然タイムアウトするようになった
- コンテナは正常に起動しているのに、トラフィック割り当てで失敗
- 原因は、壊れたリビジョンがトラフィック設定に残っていたこと
-
--remove-tagsで問題のリビジョンへの参照を削除して解決
発生した問題
GitHub Actionsからprod環境にCloud Runをデプロイしようとすると、以下のエラーでタイムアウトする。
Assigning traffic to latest specified targets. Resource readiness deadline exceeded.
dev環境では問題なくデプロイできる。prod環境だけがこの状態になった。
状況の整理
試したこと（効果なし）
- VPC設定をワークフローから削除 → 変わらず
- Cloud ConsoleからVPC設定をクリア → 変わらず
-
--clear-networkフラグを追加 → 変わらず - タイムアウト時間を延長 → 意味なし
ログを確認
Cloud Runのログを確認すると、コンテナ自体は正常に起動していた。
Starting new instance. Reason: DEPLOYMENT_ROLLOUT
Server is running on http://0.0.0.0:8080
Default STARTUP TCP probe succeeded after 1 attempt for container "my-api-1" on port 8080.
STARTUP probeも成功している。コンテナに問題はない。
原因の特定
サービスの設定を詳しく確認した。
gcloud run services describe my-api \
--region=asia-northeast1 \
--project=my-project \
--format=yaml
すると、spec.trafficとstatus.trafficに差異があることがわかった。
spec:
traffic:
- revisionName: my-api-00015-broken # ← これが問題
tag: broken-vpc-tag
# ... 他のリビジョン
- percent: 100
revisionName: my-api-00010-healthy
status:
traffic:
# my-api-00015-broken が存在しない
my-api-00015-brokenはspec.trafficに記載されているが、status.trafficには存在しない。
なぜこうなったか
原因は単純なオペミスだった。
dev環境用のVPC設定（--network=vpc-dev --subnet=subnet-dev）を、誤ってprod環境にデプロイしてしまった。prod環境にはこのVPCが存在しないため、リビジョンが壊れた状態で作成された。
解決方法
問題のリビジョンへのタグを削除する。
gcloud run services update-traffic my-api \
--remove-tags=broken-vpc-tag \
--region=asia-northeast1 \
--project=my-project
これで壊れたリビジョンへの参照がなくなり、次のデプロイが成功するようになった。
再発防止
VPC設定は環境変数化する
環境ごとに異なるVPC設定は、ハードコードせずに環境変数やSecretで管理する。
# bad
flags: >
--network=vpc-dev
--subnet=subnet-dev
# good
flags: >
--network=${{ vars.VPC_NETWORK }}
--subnet=${{ vars.VPC_SUBNET }}
まとめ
- 「Resource readiness deadline exceeded」はコンテナの問題とは限らない
- トラフィック設定に壊れたリビジョンが残っていると、全てのデプロイが失敗する
-
gcloud run services describeでspec.trafficとstatus.trafficを比較すると原因がわかることがある - 解決には
--remove-tagsで問題のリビジョンへの参照を削除する - 内容が皆さまの開発の一助となれば幸いです