はじめに
Google Cloud Run 上で Python アプリを動かす際に「環境変数をどう管理すべきか?」というテーマを解説します。
「os.getenv() で十分じゃないの?」
「.env ファイルは本番でも必要?」
こういった疑問が発生したので、調べてCloud Run 向けのベストプラクティスをまとめました。
Cloud Run では環境変数が“主役”
Cloud Run は、コンテナ起動時に 環境変数を注入して設定を渡す仕組みです。
DB接続URLやAPIキー、バケット名など、アプリ構成のあらゆる情報を環境変数で制御します。
だからこそ、環境変数を安全かつ整理された形で扱うことが、保守性・信頼性を大きく左右します。
よくあるアンチパターン
import os
DB_URL = os.getenv("DB_URL")
BUCKET = os.getenv("BUCKET_NAME")
シンプルに見えますが、これにはいくつかの問題があります。
- どの環境変数を使っているか一覧できない
- 型がすべて文字列扱い(True/False も str)
- テスト時に上書きしづらい
- .env ファイル読み込みが分散しがち
これが10個、20個と増えてくると、コード全体がスパゲッティ化していきます。
ベストプラクティス:設定クラスを作る
Cloud Run 向けのおすすめは、pydantic-settingsを使って 「設定クラス」 を作ることです。
settings.py
from pydantic_settings import BaseSettings
class Settings(BaseSettings):
project_id: str
region: str
db_url: str
bucket_name: str
debug: bool = False
class Config:
env_prefix = "" # 例: "MYAPP_" などを付けてもOK
env_file = ".env" # ローカル開発用
settings = Settings()
これで .env や Cloud Run の環境変数から自動で値を取得してくれます。
IDE補完も効くし、型の保証もばっちりです。
ローカル開発時の .env 例
PROJECT_ID=my-project
REGION=asia-northeast1
DB_URL=postgresql://user:pass@localhost/db
BUCKET_NAME=my-bucket
DEBUG=True
これを .gitignore に入れて Git に上げないようにします。
アプリからはこんな感じで呼び出せます👇
from settings import settings
print(settings.db_url)
print(settings.debug)
Cloud Run での設定方法
Cloud Run の本番環境では .env は不要。
代わりに、環境変数を直接登録します。
gcloud run deploy my-service \
--set-env-vars PROJECT_ID=my-project \
--set-env-vars REGION=asia-northeast1 \
--set-env-vars DB_URL=postgresql://user:pass@cloudsql/db \
--set-env-vars BUCKET_NAME=my-bucket \
--set-env-vars DEBUG=False
Cloud Run が起動時にこれらの環境変数を注入し、settings クラスが自動で読み取ります。
設定クラスを使うメリット
- 一元管理
→すべての設定を settings.py に集約 - 型安全
→bool/int/str などを自動バリデーション - IDE補完
→settings. で候補が出る - 未設定検知
→必須変数がなければ起動時にエラー - テスト容易
→テストで簡単にモック可能 - ステージごとの切り替えも簡単
開発・本番などで設定を切り替えたいときは、次のようにします👇
import os
from pydantic_settings import BaseSettings
class Settings(BaseSettings):
environment: str = "dev"
db_url: str
class Config:
env_file = f".env.{os.getenv('ENVIRONMENT', 'dev')}"
Cloud Run に
ENVIRONMENT=prod
を設定すれば、自動的に .env.prod を読むようになります。
どのモジュールでも以下のように呼べます:
from settings import settings
これでアプリ全体の設定が統一され、保守性もぐっと上がります。
まとめ
Cloud Run は「設定ファイルが存在しない代わりに環境変数で全て制御する」構造です。
そのため、設定クラスを作って環境変数を型安全に一元管理するのがベストです。
設定まわりが整うと、Cloud Run の運用は一気にスムーズになります。
「設定はコードで管理する」——この発想を持つだけで、デプロイ後のトラブルが激減します。
ぜひあなたの Cloud Run プロジェクトにも導入してみてください 🚀