Kuinka hallitset asetuksia eri ympäristöissä?

Question

Accepted Answer

Django-konfiguraatio sijaitsee `settings.py`-tiedostossa, mutta oikeat sovellukset tarvitsevat **erilaisia asetuksia eri ympäristöissä** (kehitys, väliaikainen, tuotanto) ja niissä on oltava **salaisuudet pois koodista**. Tämän oikea hallinta on sekä operatiivinen välttämättömyys että turvavaatimus.

## Ongelma yksittäisen settings.py:n kanssa

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

Arvojen kovakoodaaminen sekoittaa ympäristöt ja – kriittisesti – lisää salaisuudet (SECRET_KEY, tietokannan salasanat, API-avaimet) versionhallintaan, mikä on vakava turvaloukkaus.

## Ratkaisu 1: lue konfiguraatio ympäristömuuttujista

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

Konfiguraation lukeminen (erityisesti salaisuuksien) **ympäristömuuttujista** pitää ne poissa koodista – sama koodikanta toimii missä tahansa ympäristössä erilaisten injektoidun arvojen kanssa (twelve-factor -lähestymistapa).

## Ratkaisu 2: jaa asetustiedostot ympäristöittäin

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

Asetusten jakaminen jaettuun `base.py`-tiedostoon sekä ympäristökohtaisiin tiedostoihin (valittu `DJANGO_SETTINGS_MODULE`-muuttujan kautta) erottaa selkeästi ympäristökohtaisen konfiguraation ja samalla jakaa yhteiset asetukset.

## Kriittiset tuotantoasetukset

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

## Miksi se on tärkeää

Asetusten hallinta eri ympäristöissä on sekä **operatiivinen välttämättömyys** että **kriittinen turvakäytäntö** jokaiselle todelliselle Django-sovellukselle.

Sovelluksilla on oltava erilaiset käyttäytymismallit ympäristöissä – kehitys tarvitsee `DEBUG=True`-asetuksen ja kätevät paikalliset asetukset, kun taas tuotanto vaatii `DEBUG=False`-asetusta, turvallisuuden vahvistamista, oikeita tietokantoja ja oikeita isäntänimiä – ja yksittäinen kovakoodattu `settings.py` ei voi palvella kaikkia näistä.

Vieläkään tärkeämpää, tämä on **merkittävä turvaongelma**: salaisuuksien kovakoodaaminen (SECRET_KEY, tietokannan salasanat, API-avaimet) lisää ne versionhallintaan, yksi yleisimmistä ja vakavimmista tietoturvaloukkaus (kuka tahansa, jolla on pääsy repositorioon tai julkisessa repositoriossa, saa sovelluksesi ja datasi avaimet).

Ratkaisujen ymmärtäminen – konfiguraation ja salaisuuksien lukeminen **ympäristömuuttujista** (pitää ne poissa koodista, twelve-factor -lähestymistapa, usein django-environ-kaltaisten työkalujen ja gitignore-mukaisten `.env`-tiedostojen kanssa) ja **asetusten jakaminen** jaettuun perusasetukseen sekä ympäristökohtaisiin tiedostoihin – on välttämätöntä Django-sovelluksien turvalliselle ja oikealle käyttöönotolle.

**Kriittisten tuotantoasetusten** tuntemus (erityisesti että `DEBUG` on oltava `False` tuotannossa, koska `DEBUG=True` paljastaa pinokäyntijäljitykset, lähdekoodin polut ja asetukset hyökkääjille, sekä `ALLOWED_HOSTS` ja turvallisuuden vahvistaminen) on pakollista tuotanto-osaamista.

Asetusten hallinnan saaminen oikein – salaisuudet ympäristössä, ympäristölle sopivat asetukset, turvallisen tuotannon oletusarvot – on perustavanlaatuista Django-sovellusten ammattimaista käyttöönottoa ja vakavien haavoittuvuuksien välttämistä, jotka tulevat paljastuneista salaisuuksista tai väärin määritetyistä tuotantoympäristöistä, mikä tekee siitä tärkeää, käytännössä kriittistä osaamista jokaiselle todelliselle käyttöönotolle.