Wie verwaltest du Einstellungen über verschiedene Umgebungen hinweg?

Question

Accepted Answer

Django-Konfiguration befindet sich in `settings.py`, aber echte Anwendungen benötigen **unterschiedliche Einstellungen pro Umgebung** (Entwicklung, Staging, Produktion) und müssen **Geheimnisse aus dem Code heraushalten**. Dies korrekt zu verwalten ist sowohl eine betriebliche Notwendigkeit als auch eine Sicherheitsanforderung.

## Das Problem mit einer einzelnen 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
```

Das Hardcodieren von Werten vermischt Umgebungen und – kritischerweise – speichert Geheimnisse (SECRET_KEY, Datenbankpasswörter, API-Schlüssel) in der Versionskontrolle, ein schwerwiegender Sicherheitsmangel.

## Lösung 1: Konfiguration aus Umgebungsvariablen lesen

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

Das Lesen von Konfiguration (besonders Geheimnisse) aus **Umgebungsvariablen** hält sie aus dem Code fern – die gleiche Codebasis läuft in jeder Umgebung mit verschiedenen eingespielten Werten (der Twelve-Factor-Ansatz).

## Lösung 2: Settings-Dateien pro Umgebung aufteilen

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

Das Aufteilen der Einstellungen in eine gemeinsame `base.py` plus umgebungsspezifische Dateien (ausgewählt über `DJANGO_SETTINGS_MODULE`) trennt sauber die umgebungsspezifische Konfiguration, während gemeinsame Einstellungen geteilt werden.

## Kritische Produktionseinstellungen

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

## Warum es wichtig ist

Die Verwaltung von Einstellungen über Umgebungen hinweg ist sowohl eine **betriebliche Notwendigkeit** als auch eine **kritische Sicherheitspraxis** für jede echte Django-Anwendung.

Anwendungen müssen sich über verschiedene Umgebungen unterschiedlich verhalten – Entwicklung benötigt `DEBUG=True` und bequeme lokale Einstellungen, während Produktion `DEBUG=False`, Sicherheitshärtung, echte Datenbanken und korrekte Hosts erfordert – und eine einzelne hartcodierte `settings.py` kann nicht allen dienen.

Wichtig ist vor allem, dass dies ein **großes Sicherheitsrisiko** darstellt: Das Hardcodieren von Geheimnissen (dem SECRET_KEY, Datenbankpasswörtern, API-Schlüsseln) speichert sie in der Versionskontrolle, einer der häufigsten und schwerwiegendsten Sicherheitsverletzungen (jeder mit Repository-Zugriff oder in einem öffentlichen Repository erhält die Schlüssel zu deiner Anwendung und Daten).

Das Verstehen der Lösungen – Lesen von Konfiguration und Geheimnissen aus **Umgebungsvariablen** (sie aus dem Code holen, der Twelve-Factor-Ansatz, oft mit Tools wie django-environ und gitignorierten `.env`-Dateien) und **Aufteilen der Einstellungen** in eine gemeinsame Basis plus umgebungsspezifische Dateien – ist wesentlich für eine sichere und korrekte Django-Bereitstellung.

Das Kennen der **kritischen Produktionseinstellungen** (besonders dass `DEBUG` in der Produktion `False` sein muss, da `DEBUG=True` Tracebacks, Quellpfade und Einstellungen an Angreifer leckt, plus `ALLOWED_HOSTS` und Sicherheitshärtung) ist unverhandelbares Produktionswissen.

Die Einstellungsverwaltung richtig zu gestalten – Geheimnisse in der Umgebung, umgebungsgerechte Konfiguration, sichere Produktionsstandards – ist grundlegend für den professionellen Betrieb von Django-Anwendungen und für die Vermeidung der schwerwiegenden Anfälligkeiten, die aus geleakten Geheimnissen oder falsch konfigurierten Produktionsumgebungen entstehen, was es zu wichtigem, praktisch-kritischem Wissen für jede echte Bereitstellung macht.