Bạn quản lý settings xuyên các môi trường như thế nào?

Question

Accepted Answer

Cấu hình của Django nằm trong `settings.py`, nhưng các ứng dụng thực cần **settings khác nhau cho mỗi môi trường** (development, staging, production) và phải giữ **secret nằm ngoài mã**. Quản lý điều này đúng cách vừa là một nhu cầu vận hành vừa là một yêu cầu bảo mật.

## Vấn đề với một settings.py duy nhất

```python
# ❌ settings hard-code, trộn lẫn môi trường, và KHÔNG AN TOÀN
DEBUG = True                                    # phải là False trong production!
SECRET_KEY = "hardcoded-secret-in-code"          # ❌ secret bị commit vào git
DATABASES = {"default": {"PASSWORD": "prod-pw"}} # ❌ mật khẩu production trong mã
```

Hard-code giá trị trộn lẫn các môi trường và — quan trọng — commit secret (SECRET_KEY, mật khẩu database, API key) vào version control, một vi phạm bảo mật nghiêm trọng.

## Giải pháp 1: đọc config từ biến môi trường

```python
import os
from pathlib import Path

SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]    # từ môi trường, KHÔNG phải mã
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"],   # tiêm vào theo từng môi trường
    }
}
# các công cụ như django-environ / python-decouple làm điều này gọn hơn (+ hỗ trợ file .env)
```

Đọc config (đặc biệt là secret) từ **biến môi trường** giữ nó nằm ngoài mã — cùng một codebase chạy trong bất kỳ môi trường nào với các giá trị tiêm vào khác nhau (cách tiếp cận twelve-factor).

## Giải pháp 2: tách file settings theo môi trường

```text
settings/
  base.py          # settings chung (apps, middleware, templates)
  development.py   # from base import *; DEBUG=True, DB cục bộ, debug toolbar
  production.py    # from base import *; DEBUG=False, cứng hóa bảo mật, DB thật
  test.py          # settings riêng cho test
```

```python
# production.py
from .base import *
DEBUG = False
ALLOWED_HOSTS = ["example.com"]
SECURE_SSL_REDIRECT = True            # settings bảo mật chỉ cho production
# chọn qua: DJANGO_SETTINGS_MODULE=config.settings.production
```

Tách settings thành một `base.py` chung cộng các file theo từng môi trường (chọn qua `DJANGO_SETTINGS_MODULE`) tách biệt gọn gàng cấu hình riêng môi trường trong khi chia sẻ settings chung.

## Các settings production then chốt

```python
DEBUG = False                  # ❗ KHÔNG BAO GIỜ True trong production — rò rỉ thông tin lỗi nhạy cảm
ALLOWED_HOSTS = ["example.com"] # bắt buộc khi DEBUG=False
SECRET_KEY = os.environ[...]    # mạnh, bí mật, từ môi trường
# + SECURE_SSL_REDIRECT, SESSION_COOKIE_SECURE, HSTS, v.v. để cứng hóa
```

```text
✓ KHÔNG BAO GIỜ commit secret — dùng biến môi trường / secret manager; gitignore .env
✓ DEBUG=False trong production (DEBUG=True rò rỉ traceback, settings → rủi ro bảo mật)
✓ Commit một .env.example tài liệu hóa các biến cần thiết (không có giá trị thật)
```

## Tại sao điều này quan trọng

Quản lý settings xuyên các môi trường vừa là một **nhu cầu vận hành** vừa là một **thực hành bảo mật then chốt** cho bất kỳ ứng dụng Django thực nào.

Ứng dụng phải hành xử khác nhau xuyên các môi trường — development cần `DEBUG=True` và settings cục bộ tiện lợi, trong khi production yêu cầu `DEBUG=False`, cứng hóa bảo mật, database thật, và host phù hợp — và một `settings.py` hard-code duy nhất không thể phục vụ tất cả những điều này.

Quan trọng hơn, đây là một **mối quan tâm bảo mật lớn**: hard-code secret (SECRET_KEY, mật khẩu database, API key) commit chúng vào version control, một trong những vi phạm bảo mật phổ biến và nghiêm trọng nhất (bất kỳ ai có quyền truy cập repo, hoặc trong một repo công khai, đều có được chìa khóa vào ứng dụng và dữ liệu của bạn).

Hiểu các giải pháp — đọc config và secret từ **biến môi trường** (giữ chúng nằm ngoài mã, cách tiếp cận twelve-factor, thường với các công cụ như django-environ và file `.env` được gitignore) và **tách settings** thành một base chung cộng các file theo từng môi trường — là thiết yếu để triển khai Django an toàn và đúng đắn.

Biết các **settings production then chốt** (đặc biệt là `DEBUG` phải là `False` trong production, vì `DEBUG=True` rò rỉ traceback, đường dẫn nguồn, và settings cho kẻ tấn công, cộng với `ALLOWED_HOSTS` và cứng hóa bảo mật) là kiến thức production không thể thương lượng.

Làm đúng việc quản lý settings — secret trong môi trường, cấu hình phù hợp môi trường, mặc định production an toàn — là nền tảng để vận hành các ứng dụng Django một cách chuyên nghiệp và tránh các lỗ hổng nghiêm trọng đến từ secret bị rò rỉ hoặc môi trường production cấu hình sai, khiến nó trở thành kiến thức quan trọng, thiết yếu thực tế cho bất kỳ triển khai thực nào.