Hvordan styrer du innstillinger på tvers av miljøer?

Question

Accepted Answer

Django-konfigurasjonen ligger i `settings.py`, men virkelige applikasjoner trenger **ulike innstillinger per miljø** (utvikling, staging, produksjon) og må holde **hemmeligheter utenfor koden**. Å håndtere dette riktig er både en operasjonell nødvendighet og et sikkerhetskrav.

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

Hardkoding av verdier blander miljøer og — kritisk — committer hemmeligheter (SECRET_KEY, databasepassord, API-nøkler) inn i versjonskontroll, som er en alvorlig sikkerhetsbrist.

## Løsning 1: les config 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)
```

Å lese config (spesielt hemmeligheter) fra **miljøvariabler** holder det utenfor koden — samme kodebase kjører i hvilket som helst miljø med ulike injiserte verdier (twelve-factor-tilnærmingen).

## Løsning 2: del innstillingsfiler per 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
```

Å dele innstillinger i en delt `base.py` pluss per-miljø-filer (valgt via `DJANGO_SETTINGS_MODULE`) separerer miljø-spesifikke innstillinger på en ryddig måte samtidig som felles innstillinger deles.

## Kritiske produksjonsinnstillinger

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

Å styre innstillinger på tvers av miljøer er både en **operasjonell nødvendighet** og en **kritisk sikkerhetspraksis** for enhver virkelig Django-applikasjon.

Applikasjoner må oppføre seg forskjellig på tvers av miljøer — utvikling trenger `DEBUG=True` og praktiske lokale innstillinger, mens produksjon krever `DEBUG=False`, sikkerhetshardening, reelle databaser og riktige verter — og en enkelt hardkodet `settings.py` kan ikke tjene alle disse.

Og — enda viktigere — dette er en **stor sikkerhetsbetenkelig**: hardkoding av hemmeligheter (SECRET_KEY, databasepassord, API-nøkler) committer dem til versjonskontroll, en av de vanligste og alvorligste sikkerhetsbristene (hvem som helst med tilgang til repo, eller i et offentlig repo, får nøklene til applikasjonen og dataene dine).

Å forstå løsningene — å lese config og hemmeligheter fra **miljøvariabler** (holde dem utenfor koden, twelve-factor-tilnærmingen, ofte med verktøy som django-environ og gitignorerte `.env`-filer) og **dele innstillinger** i en delt base pluss per-miljø-filer — er essensielt for å distribuere Django sikkert og riktig.

Å kjenne de **kritiske produksjonsinnstillingene** (spesielt at `DEBUG` må være `False` i produksjon, siden `DEBUG=True` lekkjer tracebacks, kildestier og innstillinger til angripere, pluss `ALLOWED_HOSTS` og sikkerhetshardening) er ikke-forhandlingsbar produksjonsviten.

Å få innstillingsstyring rett — hemmeligheter i miljøet, miljø-passende konfigurasjon, sikre produksjonsstandarder — er grunnleggende for å kjøre Django-applikasjoner profesjonelt og unngå de alvorlige sårbarhetene som kommer fra lekte hemmeligheter eller feilkonfigurerte produksjonsmiljøer, noe som gjør det viktig, praktisk-kritisk kunnskap for enhver virkelig distribusjon.