Jak zarządzasz ustawieniami w różnych środowiskach?

Question

Accepted Answer

Konfiguracja Django znajduje się w `settings.py`, ale rzeczywiste aplikacje wymagają **różnych ustawień dla każdego środowiska** (development, staging, production) i muszą trzymać **sekrety poza kodem**. Prawidłowe zarządzanie tym jest zarówno koniecznością operacyjną, jak i wymogiem bezpieczeństwa.

## Dlaczego to ważne

Zarządzanie ustawieniami w różnych środowiskach jest zarówno **koniecznością operacyjną** jak i **krytyczną praktyką bezpieczeństwa** dla każdej rzeczywistej aplikacji Django.

Aplikacje muszą zachowywać się inaczej w różnych środowiskach — development potrzebuje `DEBUG=True` i wygodnych ustawień lokalnych, podczas gdy production wymaga `DEBUG=False`, wzmocnienia bezpieczeństwa, rzeczywistych baz danych i odpowiednich hostów — a pojedynczy na sztywno zakodowany `settings.py` nie może służyć wszystkim tym celom.

Co ważniejsze, jest to **poważny problem bezpieczeństwa**: zakodowanie sekretów (SECRET_KEY, hasła do bazy danych, klucze API) na sztywno zapisuje je w kontroli wersji, jeden z najczęstszych i najpoważniejszych naruszeń bezpieczeństwa (każdy, kto ma dostęp do repozytorium, lub w publicznym repozytorium, uzyskuje klucze do twojej aplikacji i danych).

Zrozumienie rozwiązań — odczytywanie konfiguracji i sekretów ze **zmiennych środowiskowych** (trzymając je poza kodem, podejście twelve-factor, często z narzędziami takimi jak django-environ i plikami `.env` ignorowanymi przez gitignore) oraz **podział ustawień** na wspólną bazę plus pliki dla każdego środowiska — jest niezbędne do bezpiecznego i prawidłowego wdrażania Django.

Znajomość **krytycznych ustawień produkcyjnych** (szczególnie że `DEBUG` musi być `False` w production, ponieważ `DEBUG=True` ujawnia traceback'i, ścieżki źródłowe i ustawienia ataczkującym, plus `ALLOWED_HOSTS` i wzmocnienie bezpieczeństwa) jest nie do negocjowania w produkcyjnej wiedzy.

Prawidłowe zarządzanie ustawieniami — sekrety w środowisku, konfiguracja odpowiadająca środowisku, bezpieczne ustawienia domyślne produkcji — jest fundamentem do profesjonalnego uruchamiania aplikacji Django i unikania poważnych luk w zabezpieczeniach, które wynikają z wyciekłych sekretów lub błędnie skonfigurowanych środowisk produkcyjnych, co czyni to ważną, praktycznie krytyczną wiedzą dla każdego rzeczywistego wdrożenia.

```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
```

Zakodowanie na sztywno wartości mieszają środowiska i — co krytyczne — zapisuje sekrety (SECRET_KEY, hasła bazy danych, klucze API) w kontroli wersji, poważne naruszenie bezpieczeństwa.

## Rozwiązanie 1: odczytaj konfigurację ze zmiennych środowiskowych

```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)
```

Odczytywanie konfiguracji (szczególnie sekretów) ze **zmiennych środowiskowych** trzyma je poza kodem — ta sama baza kodu działa w każdym środowisku z różnymi wstrzykiwanymi wartościami (podejście twelve-factor).

## Rozwiązanie 2: podziel pliki ustawień na środowiska

```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
```

Podział ustawień na wspólny `base.py` plus pliki dla każdego środowiska (wybierane przez `DJANGO_SETTINGS_MODULE`) czysto oddziela konfigurację specyficzną dla środowiska, jednocześnie udostępniając wspólne ustawienia.

## Krytyczne ustawienia produkcyjne

```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)
```