Hvordan administrerer du indstillinger på tværs af miljøer?

Question

Accepted Answer

Django-konfiguration lever i `settings.py`, men rigtige applikationer har brug for **forskellige indstillinger pr. miljø** (udvikling, staging, produktion) og må holde **hemmeligheder uden for koden**. At administrere dette korrekt er både en operationel nødvendighed og et sikkerhedskrav.

## Problemet med en enkelt 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
```

Hardkodning af værdier blander miljøer og — kritisk — committed hemmeligheder (SECRET_KEY, databaseadgangskoder, API-nøgler) til versionskontrol, en alvorlig sikkerhedsbrist.

## Løsning 1: læs konfiguration fra miljøvariabler

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

At læse konfiguration (især hemmeligheder) fra **miljøvariabler** holder det uden for koden — den samme kodebase kører i ethvert miljø med forskellige injicerede værdier (twelve-factor-tilgangen).

## Løsning 2: opdel indstillingsfiler pr. miljø

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

Opdeling af indstillinger i en delt `base.py` plus miljø-specifikke filer (valgt via `DJANGO_SETTINGS_MODULE`) adskiller miljø-specifikke konfigurationen rent, mens fælles indstillinger deles.

## Kritiske produktionsindstillinger

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

## Hvorfor det betyder noget

At administrere indstillinger på tværs af miljøer er både en **operationel nødvendighed** og en **kritisk sikkerhedspraksis** for enhver rigtig Django-applikation.

Applikationer skal opføre sig forskelligt på tværs af miljøer — udvikling har brug for `DEBUG=True` og praktiske lokale indstillinger, mens produktion kræver `DEBUG=False`, sikkerhedshærdning, rigtige databaser og korrekte hosts — og en enkelt hardkodet `settings.py` kan ikke tjene alle disse.

Mere vigtigt er dette et **større sikkerhedsproblem**: hardkodning af hemmeligheder (SECRET_KEY, databaseadgangskoder, API-nøgler) committer dem til versionskontrol, en af de hyppigste og mest alvorlige sikkerhedsbristinger (alle med repo-adgang, eller i et offentligt repo, får nøglerne til din applikation og data).

At forstå løsningerne — at læse konfiguration og hemmeligheder fra **miljøvariabler** (holder dem uden for koden, twelve-factor-tilgangen, ofte med værktøjer som django-environ og gitignorerede `.env`-filer) og **opdele indstillinger** i en delt base plus miljø-specifikke filer — er væsentligt for at udrullet Django sikkert og korrekt.

At kende de **kritiske produktionsindstillinger** (især at `DEBUG` skal være `False` i produktion, da `DEBUG=True` lækker stack traces, stisystemer og indstillinger til angribere, plus `ALLOWED_HOSTS` og sikkerhedshærdning) er ikkeforhandelbar produktionsviden.

At få indstillingsstyring rigtigt — hemmeligheder i miljøet, miljø-passende konfiguration, sikre produktionsstandarder — er grundlæggende for at køre Django-applikationer professionelt og undgå de alvorlige sårbarheder, der kommer fra lækkede hemmeligheder eller fejlkonfigurerede produktionsmiljøer, hvilket gør det vigtig, praktisk-kritisk viden for enhver rigtig udrulning.