¿Cómo gestiona la configuración en diferentes entornos?

Question

Accepted Answer

La configuración de Django reside en `settings.py`, pero las aplicaciones reales necesitan **diferentes configuraciones por entorno** (desarrollo, staging, producción) y deben mantener **secretos fuera del código**. Gestionar esto correctamente es tanto una necesidad operativa como un requisito de seguridad.

## Por qué es importante

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

Los valores codificados mezclan entornos y — de manera crítica — envían secretos (SECRET_KEY, contraseñas de base de datos, claves de API) al control de versiones, una brecha de seguridad grave.

## Solución 1: leer configuración desde variables de entorno

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

Leer configuración (especialmente secretos) desde **variables de entorno** la mantiene fuera del código — el mismo codebase se ejecuta en cualquier entorno con valores inyectados diferentes (el enfoque twelve-factor).

## Solución 2: dividir archivos de configuración por entorno

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

Dividir la configuración en un `base.py` compartido más archivos por entorno (seleccionados mediante `DJANGO_SETTINGS_MODULE`) separa limpiamente la configuración específica del entorno mientras se comparten los ajustes comunes.

## Configuraciones críticas de producción

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

## Por qué es importante

Gestionar configuraciones en diferentes entornos es tanto una **necesidad operativa** como una **práctica de seguridad crítica** para cualquier aplicación Django real.

Las aplicaciones deben comportarse de manera diferente en entornos — el desarrollo necesita `DEBUG=True` y configuraciones locales convenientes, mientras que la producción requiere `DEBUG=False`, endurecimiento de seguridad, bases de datos reales y hosts apropiados — y un único `settings.py` codificado no puede servir para todos estos.

Más importante aún, este es un **problema de seguridad grave**: codificar secretos (la SECRET_KEY, contraseñas de base de datos, claves de API) los envía al control de versiones, una de las brechas de seguridad más comunes y graves (cualquiera con acceso al repositorio, o en un repositorio público, obtiene las claves de tu aplicación y datos).

Entender las soluciones — leer configuración y secretos desde **variables de entorno** (manteniéndolos fuera del código, el enfoque twelve-factor, frecuentemente con herramientas como django-environ y archivos `.env` ignorados por git) y **dividir configuraciones** en una base compartida más archivos por entorno — es esencial para desplegar Django de manera segura y correcta.

Conocer las **configuraciones críticas de producción** (especialmente que `DEBUG` debe ser `False` en producción, ya que `DEBUG=True` filtra tracebacks, rutas de fuentes y configuraciones a atacantes, además de `ALLOWED_HOSTS` y endurecimiento de seguridad) es conocimiento de producción innegociable.

Gestionar correctamente la configuración — secretos en el entorno, configuración apropiada para el entorno, valores predeterminados seguros de producción — es fundamental para ejecutar aplicaciones Django de manera profesional y evitar las vulnerabilidades graves que provienen de secretos filtrados o entornos de producción mal configurados, lo que lo hace conocimiento importante y crítico en la práctica para cualquier despliegue real.