--env-fileでDocker Envファイルを使用する

Envファイルによる設定管理

containerに多くの環境変数が必要な場合、すべてを-eフラグで列挙するのは扱いにくくなります。--env-fileフラグはファイルから変数を読み込みます：

docker run -d --env-file ./app.env my-app

Envファイルのフォーマット

ファイルはシンプルなKEY=VALUEフォーマットに従い、1行に1変数です：

# データベース設定
DB_HOST=localhost
DB_PORT=5432
DB_USER=admin
DB_PASS=secretpassword
DB_NAME=myapp

# アプリケーション設定
NODE_ENV=production
PORT=3000
LOG_LEVEL=info

# 外部サービス
REDIS_URL=redis://cache:6379
SMTP_HOST=mail.example.com

ファイルフォーマットのルール

• #で始まる行はコメントです（無視されます）。
• 空行は無視されます。
• 各行はKEY=VALUEフォーマットである必要があります。
• 値を囲むクォートは文字通りに含まれます（KEY="value"はDockerの一部のバージョンではクォートを含む"value"に設定されます）。
• 変数展開はありません（$VARの参照は解決されません）。

複数のEnvファイル

複数の--env-fileフラグを指定できます。後のファイルは重複するキーの場合、前のファイルを上書きします：

docker run -d \
  --env-file ./base.env \
  --env-file ./production.env \
  my-app

一般的なパターンは、ベース設定と環境固有のオーバーライドを持つことです：

base.env          # 共有のデフォルト値
development.env   # 開発固有のオーバーライド
staging.env       # ステージングのオーバーライド
production.env    # 本番のオーバーライド

優先順位のルール

同じ変数が複数の場所で定義されている場合、以下の優先順位です（高い方が優先）：

1. コマンドラインの-e KEY=VALUE
2. --env-file（後のファイルが前のファイルを上書き）
3. Dockerfile内のENV命令

# CLIフラグがenvファイルに優先
docker run -e LOG_LEVEL=debug --env-file ./production.env my-app
# production.envに'info'と書いてあっても、LOG_LEVELは'debug'になる

環境固有のファイル

envファイルを環境ごとに整理します：

config/
  base.env           # DB_HOST、REDIS_URLなど
  development.env    # LOG_LEVEL=debug、NODE_ENV=development
  production.env     # LOG_LEVEL=warn、NODE_ENV=production
  secrets.env        # API_KEY、DB_PASS（gitにコミットしないこと）

セキュリティのベストプラクティス

• secrets.envをバージョン管理にコミットしないでください。 .gitignoreに追加してください。
• ドキュメント用にプレースホルダー値を持つ.env.exampleをテンプレートとして使用してください。
• CI/CDシステムでは、デプロイ時にvault（HashiCorp Vault、AWS Secrets Manager）からenvファイルにシークレットを注入してください。
• ファイルパーミッションを制限してください：chmod 600 secrets.env。
• 定期的にシークレットをローテーションし、envファイルを更新してください。