mhKubernetesでアプリケーションを動かすとき、設定値（DBの接続先、APIキー、アプリのモードなど）をどうやって渡すかは重要な設計ポイントです。
特に以下のような手段があります：
- 環境変数
- ConfigMap
- Secret
- コマンドライン引数
- マウントされた設定ファイル
この章では 「環境変数 vs ConfigMap / Secret」 に焦点を当てて、それぞれどんなときに使うのが適切なのかを見ていきます。
🧪 そもそも「環境変数」とは？
アプリケーションのプロセスが起動したときに参照できるキーと値のセットです。よく使われる例：
ENV=production
DB_HOST=mysql.local環境変数はコードの外に設定を分離できるため、12 Factor App の原則にも合致しています。
Kubernetesでは以下のように環境変数を指定できます。
env:
- name: APP_MODE
value: "production"🔄 ConfigMap / Secretを使った環境変数の指定
Kubernetesでは、ConfigMapやSecretの値を「環境変数として注入」できます。
env:
- name: DB_HOST
valueFrom:
configMapKeyRef:
name: db-config
key: hostSecretから渡すときも同様です。
🎯 使い分けの基本方針
| 方法 | 向いているケース | 具体例 |
|---|---|---|
| 環境変数（直接指定） | 値が固定で、変更の可能性が低い | ENV=production や PORT=8080 |
| ConfigMap | アプリ設定や接続先など、非機密な設定を外部化 | DBのホスト名、アプリの表示モード、ログレベルなど |
| Secret | パスワードやAPIキーなど機密情報 | DBパスワード、トークン、証明書など |
🟡 環境変数（直接指定）のメリットと注意点
✅ メリット：
- シンプルで記述が少ない
- すぐに試したいときに便利
⚠️ 注意点：
- 値の変更にはPodの再デプロイが必要
- ソース管理に載せると危険（特に機密情報）
🟢 ConfigMap / Secretを経由するメリット
- 再利用性が高い（複数のPodで共通化できる）
- 分離性が高い（設定とPod定義を切り離せる）
- 更新が管理しやすい（kubectlで適用しやすい）
たとえば、以下のような構成がよくあります：
ConfigMap:
app.env: "staging"
log.level: "debug"
Secret:
db.password: "pa$$word123"これらを必要なコンテナに環境変数として注入すれば、アプリ側の書き方は変わりません。
📝 実運用でのTips
| シーン | おすすめの方法 | 理由 |
|---|---|---|
| ステージング環境の切り替え | ConfigMap | 頻繁に変更したい非機密な情報だから |
| データベース接続情報 | Secret + 環境変数 | 機密なのでSecret、環境変数で渡すとアプリが扱いやすい |
| 一時的なテスト値 | 環境変数（直接指定） | 手軽で即反映できるため（ただしGitには注意） |
🔚 まとめ
| 比較項目 | 環境変数（直接指定） | ConfigMap | Secret |
|---|---|---|---|
| 安全性 | △ | ○ | ◎ |
| 柔軟性 | △ | ◎ | ◎ |
| 保守性 | △ | ◎ | ◎ |
| 使いどころ | 固定値や実験用 | 非機密な外部設定 | 機密情報の安全な管理 |
📌 最後に
Kubernetesに慣れてくると、設定の「渡し方」「管理方法」は自然と設計に組み込まれていきます。
「環境変数だけで管理する」のは小規模な開発では便利ですが、運用環境では ConfigMapやSecretに切り出すのが一般的です。再利用性とセキュリティが格段に上がるからです。
