Bagaimanakah anda menguruskan tetapan merentasi persekitaran?

Question

Accepted Answer

Konfigurasi Django berada dalam `settings.py`, tetapi aplikasi sebenar memerlukan **tetapan berbeza setiap persekitaran** (pembangunan, staging, pengeluaran) dan mesti menyimpan **rahsia di luar kod**. Menguruskan ini dengan betul adalah kedua-dua keperluan operasi dan keperluan keselamatan.

## Masalah dengan settings.py tunggal

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

Menetapkan nilai secara hardcode mencampuradukkan persekitaran dan — yang paling kritikal — menyerahkan rahsia (SECRET_KEY, kata laluan pangkalan data, kunci API) ke dalam kawalan versi, satu pelanggaran keselamatan yang serius.

## Penyelesaian 1: baca konfigurasi daripada pemboleh ubah persekitaran

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

Membaca konfigurasi (terutamanya rahsia) daripada **pemboleh ubah persekitaran** mengekalkannya di luar kod — pangkalan kod yang sama berjalan dalam mana-mana persekitaran dengan nilai berbeza yang disuntik (pendekatan twelve-factor).

## Penyelesaian 2: pecahkan fail tetapan setiap persekitaran

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

Memecahkan tetapan kepada `base.py` sepunya ditambah fail setiap persekitaran (dipilih melalui `DJANGO_SETTINGS_MODULE`) mengasingkan konfigurasi khusus persekitaran dengan kemas sambil berkongsi tetapan biasa.

## Tetapan pengeluaran yang kritikal

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

## Mengapa ia penting

Menguruskan tetapan merentasi persekitaran adalah kedua-dua **keperluan operasi** dan **amalan keselamatan kritikal** untuk mana-mana aplikasi Django sebenar.

Aplikasi mesti berkelakuan berbeza merentasi persekitaran — pembangunan memerlukan `DEBUG=True` dan tetapan tempatan yang mudah, manakala pengeluaran memerlukan `DEBUG=False`, pengukuhan keselamatan, pangkalan data sebenar, dan hos yang betul — dan satu `settings.py` hardcode tunggal tidak boleh memenuhi kesemuanya.

Yang lebih penting, ini ialah **kebimbangan keselamatan yang besar**: menetapkan rahsia secara hardcode (SECRET_KEY, kata laluan pangkalan data, kunci API) menyerahkannya ke kawalan versi, salah satu pelanggaran keselamatan yang paling biasa dan serius (sesiapa dengan akses repo, atau dalam repo awam, mendapat kunci kepada aplikasi dan data anda).

Memahami penyelesaiannya — membaca konfigurasi dan rahsia daripada **pemboleh ubah persekitaran** (mengekalkannya di luar kod, pendekatan twelve-factor, selalunya dengan alat seperti django-environ dan fail `.env` yang di-gitignore) dan **memecahkan tetapan** kepada satu base sepunya ditambah fail setiap persekitaran — adalah penting untuk menggunakan Django dengan selamat dan betul.

Mengetahui **tetapan pengeluaran yang kritikal** (terutamanya bahawa `DEBUG` mesti `False` dalam pengeluaran, kerana `DEBUG=True` membocorkan traceback, laluan sumber, dan tetapan kepada penyerang, ditambah `ALLOWED_HOSTS` dan pengukuhan keselamatan) ialah pengetahuan pengeluaran yang tidak boleh ditawar.

Menguruskan tetapan dengan betul — rahsia dalam persekitaran, konfigurasi yang sesuai dengan persekitaran, lalai pengeluaran yang selamat — adalah asas untuk menjalankan aplikasi Django secara profesional dan mengelakkan kerentanan serius yang timbul daripada rahsia yang bocor atau persekitaran pengeluaran yang tersalah konfigurasi, menjadikannya pengetahuan yang penting dan kritikal secara praktikal untuk mana-mana penggunaan sebenar.