Kaip tu valdai nustatymus skirtingose aplinkose?

Question

Accepted Answer

Django konfigūracija gyvena `settings.py` faile, bet tikros programos reikalinga **skirtingi nustatymai kiekvienai aplinkai** (development, staging, production) ir turi **nepalikti slapumų kode**. Teisingas šio valdymas yra ir operacinis poreikis, ir saugumo reikalavimas.

## Problema su vienu 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
```

Reikšmių įkietinimas sumaišo aplinkas ir — kritiškai — įsigalioja slapumus (SECRET_KEY, duomenų bazės slaptažodžiai, API raktai) į versijos kontrolę, tai yra rimtas saugumo pažeidimas.

## Sprendimas 1: nuskaityti konfigūraciją iš aplinkos kintamųjų

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

Konfigūracijos nuskaitimas (ypač slapumų) iš **aplinkos kintamųjų** palikti jį iš kodo — tas pats kodeksu bėga bet kurioje aplinkoje su skirtingomis suinjetuotomis reikšmėmis (dvylika faktorių metodas).

## Sprendimas 2: padalinti nustatymo failus pagal aplinką

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

Nustatymų padalijimas į bendrą `base.py` ir aplinkos-specifiniais failais (pasirinkta per `DJANGO_SETTINGS_MODULE`) gražiai atskiria aplinkos-specifinę konfigūraciją, tuo tarpu dažnindami bendrus nustatymus.

## Kritiniai gamybos nustatymai

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

## Kodėl tai svarbu

Nustatymų valdymas skirtingose aplinkose yra ir **operacinis poreikis**, ir **kritinis saugumo žingsnis** bet kuriai tikrai Django programai.

Programos turi elgtis skirtingai aplinkose — plėtojimas reikalinga `DEBUG=True` ir patogi vietiniai nustatymai, o gamyba reikalinga `DEBUG=False`, saugumo sustiprinti, tikros duomenų bazės, ir tinkamas hosts — ir vienas įkietintas `settings.py` negali paslaugti visų šių.

Svarbu pasakyti, tai yra **didelis saugumo susirūpinimas**: slapumų įkietinimas (SECRET_KEY, duomenų bazės slaptažodžiai, API raktai) įsigalioja jūs į versijos kontrolę, vienas iš dažniausių ir rimčiausių saugumo pažeidimų (kas nors su repo prieiga, arba viešame repo, gauna raktus į jūsų programą ir duomenis).

Supratimas sprendimų — nuskaityti konfigūraciją ir slapumus iš **aplinkos kintamųjų** (išlaikant juos iš kodo, dvylika faktorių metodas, dažnai su įrankiais kaip django-environ ir `.env` failais, neįtrauktais į git) ir **padalinti nustatymus** į bendrą bazę ir aplinkos-specifiniais failais — yra būtinas Django saugiam ir teisingam diegimui.

Žinojimas **kritinių gamybos nustatymų** (ypač tai, kad `DEBUG` turi būti `False` gamyboje, nes `DEBUG=True` nuslepia išimčių apraš, šaltinio kelius ir nustatymus į atachuotojas, plius `ALLOWED_HOSTS` ir saugumo sustiprinimas) yra nepersenėlys gamybos žinojimu.

Teisingo nustatymų valdymo — slapumų aplinkoje, aplinkos-tinkama konfigūracija, saugūs gamybos numatymai — yra pagrindinis Django programų profesionaliam veikimui ir iš saugumų grėsmių vengimui, iš kurie ateina iš nutekmų slapumų arba neteisingai sukonfigūruotos gamybos aplinkos, daro jį svarbiu, praktiniu-kritišku žinojimu bet kuriam tikram diegimui.