Open8
【GoogleCloud/GCP】Cloud Run Tips📝 Cloud Run サービスとDeployについて📝
ピン留めされたアイテム
まさぴょん🐱GitHub を利用したCloud Run サービス Deploy📝
- Repository側にGitHub App を追加する必要があります。
ピン留めされたアイテム
まさぴょん🐱Cloud Runの環境変数について📝
以下では 「Cloud Run コンソールで設定した環境変数は .env の代わりになるのか？」 を中心に、仕組み・優先順位・運用の勘どころを整理します。
サマリー📝
Cloud Run の 「Variables & Secrets」タブで設定したキー／値は、インスタンス起動時に Linux 環境変数としてコンテナに注入 されます。
- 同じ名前の変数を Dockerfile の
ENVや.envファイルより優先 して上書きします ([Google Cloud][1])。 - ただし
.envを自前で読み込むライブラリ（dotenv など）を使う場合は、その 読込タイミング によっては Cloud Run 側で注入された値が上書きされる／されないが変わります。 - 機密情報は
.envや環境変数にベタ書きせず、Secret Manager を参照する環境変数 に切り替えるのが推奨です ([Google Cloud][2], [Stack Overflow][3])。
Cloud Run の環境変数のしくみ
1. 設定場所と反映タイミング
| 方法 | 反映タイミング | 備考 |
|---|---|---|
Cloud Run コンソール／gcloud run deploy … --set-env-vars
|
新しいリビジョンの起動時 に OS 環境変数として注入 | 設定変更＝新リビジョン発行 ([Google Cloud][1]) |
Dockerfile ENV 行 |
イメージビルド時に固定。値はコンテナ起動時にそのまま渡る | Cloud Run 側に同名があると上書きされる ([Google Cloud][1]) |
.env ファイル & dotenv |
アプリ起動時にアプリが自分で読み込む | ファイルをイメージに含める必要あり。ランタイム優先度はアプリ実装依存 |
2. 優先順位
公式ドキュメントが明示しているとおり、サービス側で設定した値が最優先です ([Google Cloud][1])。
そのため Dockerfile に ENV DATABASE_URL=dev と書き、Cloud Run で DATABASE_URL=prod を指定した場合、実行時に prod が効きます。
.env ファイルとの違いと落とし穴
| 項目 | Cloud Run env |
.env ファイル |
|---|---|---|
| 保存場所 | Cloud Run 設定メタデータ | コンテナ内（イメージに焼き込むか、ボリューム） |
| 入れ替え | 新リビジョンごとに UI / CLI で変更 | 画像を再ビルドしない限り変更困難 |
| ログや crash dump に残るリスク | あり（メモリ） ([Reddit][4]) | あり（ファイルシステム） |
| オンラインでのローテーション | 可能 | イメージ再ビルド必須 |
dotenv 利用時の典型的パターン
// 起動直後に dotenv.config() を呼ぶと、Cloud Run の変数で上書きされる
import 'dotenv/config';
console.log(process.env.API_KEY);
- dotenv が先にロード → Cloud Run の値で上書き（問題なし）
- 逆に “後から”
.envを読むと Cloud Run で設定した値を潰してしまうので注意が必要です。Stack Overflow でも同様の質問が散見されます ([Stack Overflow][5], [Reddit][6])。
本番運用のベストプラクティス
1. 機密情報は Secret Manager へ
- Cloud Run では Secrets を 環境変数として参照 でき、コードは変更せずに済む ([Google Cloud][2], [Medium][7])。
- UI 上でも「Add secret reference」で
.envの代わりに設定可能。
2. IaC で一元管理
-
gcloud run services update --update-env-varsや Terraform のgoogle_cloud_run_v2_serviceでバージョン管理すると、人為ミスを避けられます ([Google Cloud][1])。
3. ローカル開発との合わせ技
-
ローカルは
.env、本番は Cloud Run env という二段構えが定番 ([Medium][8])。 - 変数名を完全に一致させ、コード側で
process.env.X ?? 'default'のようにフォールバックを書いておくと安全。
4. デプロイ時の build-time 依存に注意
- Next.js や Vite などの静的ビルド系フロントは、ビルド時点の環境変数を取り込むため、Cloud Run で設定しても反映されないケースがあります（
VITE_prefix など）。この場合は Cloud Build 側で--build-argや CI の環境変数を使ってください ([Reddit][6])。
参考・引用📝
ピン留めされたアイテム
まさぴょん🐱Cloud Runのカスタムドメイン設定📝 Ver. ロードバランサを使用する場合📝
まさぴょん🐱Cloud Run サービスについて📝
まさぴょん🐱Cloud Run へのデプロイ📝
Hono
React/Vite
React Router on BunをCloudRunで動かす
Cloud Run ✖️ Web Socket App Deploy
まさぴょん🐱Cloud Run のネットワーク構成と認証について📝
まさぴょん🐱Cloud RunとCloudSQLの接続について📝
まさぴょん🐱Cloud RunのServerログを確認する📝
