Как вы управляете параметрами конфигурации в разных окружениях?

Question

Accepted Answer

Конфигурация Django находится в `settings.py`, но реальные приложения требуют **разных параметров для каждого окружения** (разработка, staging, production) и должны хранить **секреты вне кода**. Правильное управление этим — как операционная необходимость, так и требование безопасности.

## Проблема с единственным 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)
```

Чтение конфигурации (особенно секретов) из **переменных окружения** хранит её вне кода — один и тот же кодовой код запускается в любом окружении с разными введёнными значениями (подход двенадцати факторов).

## Решение 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`) чисто разделяет специфичную для окружения конфигурацию, при этом делясь общими параметрами.

## Критические параметры production

```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` и удобных локальных параметров, в то время как production требует `DEBUG=False`, усиления безопасности, реальных баз данных и правильных хостов — а единственный жёстко заданный `settings.py` не может обслуживать всё это.

Ещё важнее, это **серьёзная проблема безопасности**: жёсткое задание секретов (SECRET_KEY, пароли БД, API ключи) коммитит их в систему контроля версий, один из наиболее распространённых и серьёзных нарушений безопасности (любой, у кого есть доступ к репозиторию, или в публичном репозитории получает ключи к вашему приложению и данным).

Понимание решений — чтение конфигурации и секретов из **переменных окружения** (хранение их вне кода, подход двенадцати факторов, часто с инструментами вроде django-environ и файлами `.env` в .gitignore) и **разделение параметров** на общую базу плюс файлы для каждого окружения — необходимо для безопасного и корректного развёртывания Django.

Знание **критических параметров production** (в особенности, что `DEBUG` должен быть `False` в production, так как `DEBUG=True` утекает traceback'и, пути к исходникам и параметры атакующим, плюс `ALLOWED_HOSTS` и усиление безопасности) — это обязательное знание для production.

Правильное управление параметрами — секреты в окружении, специфичная для окружения конфигурация, безопасные настройки production — является фундаментом для профессионального запуска приложений Django и избежания серьёзных уязвимостей, которые возникают из утёкших секретов или неправильной конфигурации production окружения, делая это важным и практически критическим знанием для любого реального развёртывания.