環境全体で設定をどのように管理しますか?

Question

Accepted Answer

Django の設定は `settings.py` に存在しますが、実際のアプリケーションでは **環境ごとに異なる設定** (開発、ステージング、本番) が必要であり、**シークレットをコードの外に保つ** 必要があります。これを正しく管理することは、運用上の必要性とセキュリティ要件の両方です。

## 単一の settings.py の問題

```python
# ❌ hardcoded, environment-mixed, and INSECURE settings
DEBUG = True                                    # must be False in production!
SECRET_KEY = "hardcoded-secret-in-code"          # ❌ secret committed to git
DATABASES = {"default": {"PASSWORD": "prod-pw"}} # ❌ production password in code
```

値をハードコーディングすると環境が混在し、さらに重大なことに、シークレット (SECRET_KEY、データベースパスワード、API キー) がバージョン管理にコミットされてしまい、これは重大なセキュリティ侵害です。

## ソリューション 1: 環境変数から設定を読み込む

```python
import os
from pathlib import Path

SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]    # from the environment, NOT code
DEBUG = os.environ.get("DJANGO_DEBUG", "False") == "True"
ALLOWED_HOSTS = os.environ.get("ALLOWED_HOSTS", "").split(",")
DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": os.environ["DB_NAME"],
        "PASSWORD": os.environ["DB_PASSWORD"],   # injected per environment
    }
}
# tools like django-environ / python-decouple make this cleaner (+ .env file support)
```

**環境変数** から設定 (特にシークレット) を読み込むことで、それをコードの外に保ち、同じコードベースが異なるインジェクションされた値を持つ任意の環境で実行できます (12 要素アプリケーションアプローチ)。

## ソリューション 2: 環境ごとに設定ファイルを分割する

```text
settings/
  base.py          # shared settings (apps, middleware, templates)
  development.py   # from base import *; DEBUG=True, local DB, debug toolbar
  production.py    # from base import *; DEBUG=False, security hardening, real DB
  test.py          # test-specific settings
```

```python
# production.py
from .base import *
DEBUG = False
ALLOWED_HOSTS = ["example.com"]
SECURE_SSL_REDIRECT = True            # production-only security settings
# select via: DJANGO_SETTINGS_MODULE=config.settings.production
```

共有の `base.py` と環境ごとのファイル (DJANGO_SETTINGS_MODULE で選択) に設定を分割することで、環境固有の設定をきれいに分離しながら、共通設定を共有できます。

## 本番環境の重要な設定

```python
DEBUG = False                  # ❗ NEVER True in production — leaks sensitive error info
ALLOWED_HOSTS = ["example.com"] # required when DEBUG=False
SECRET_KEY = os.environ[...]    # strong, secret, from the environment
# + SECURE_SSL_REDIRECT, SESSION_COOKIE_SECURE, HSTS, etc. for hardening
```

```text
✓ NEVER commit secrets — use env vars / a secret manager; gitignore .env
✓ DEBUG=False in production (DEBUG=True leaks tracebacks, settings → security risk)
✓ Commit a .env.example documenting required variables (no real values)
```

## なぜ重要なのか

環境全体で設定を管理することは、実際の Django アプリケーションにおいて、**運用上の必要性** と **重要なセキュリティ実践** の両方です。

アプリケーションは環境全体で異なる動作をする必要があります — 開発では `DEBUG=True` と便利なローカル設定が必要であり、本番環境では `DEBUG=False`、セキュリティ強化、実際のデータベース、適切なホストが必要です — そして、単一のハードコーディングされた `settings.py` はこれらすべてに対応することはできません。

さらに重要なのは、これが **重大なセキュリティの懸念事項** であることです。シークレット (SECRET_KEY、データベースパスワード、API キー) をハードコーディングすると、それらがバージョン管理にコミットされてしまい、これは最も一般的で重大なセキュリティ侵害の 1 つです (リポジトリアクセス権のある人、または公開リポジトリでは、アプリケーションとデータのカギを手に入れられます)。

ソリューションを理解することが重要です — **環境変数** から設定とシークレットを読み込む (コードの外に保つ、12 要素アプローチ、多くの場合 django-environ などのツールと gitignored `.env` ファイルを使用) そして **設定を分割** して、共有ベースと環境ごとのファイルにする — これは Django を安全かつ正しくデプロイするために必須です。

**重要な本番環境設定** を知ること (特に `DEBUG` は本番環境では `False` である必要があること — `DEBUG=True` はトレースバック、ソースパス、設定を攻撃者に漏らすため、さらに `ALLOWED_HOSTS` とセキュリティ強化) は本番環境で必須の知識です。

設定管理を正しく行うこと — 環境ではシークレット、環境に応じた設定、安全な本番環境のデフォルト — は Django アプリケーションをプロとして実行し、漏えいしたシークレットまたは誤設定された本番環境から生じる重大な脆弱性を回避するための基本です。これは実際のデプロイメントのための重要で実践的には重要な知識を作成します。