Gestión de Configuración

La gestión de configuración separa lo que cambia por entorno de cómo la automatización lo aplica. Los proyectos de infraestructura en Python utilizan plantillas, archivos de configuración en capas y almacenes de secretos para que los entornos de desarrollo, staging y producción permanezcan estructuralmente idénticos sin copiar pilas completas.

Receta

Tarjeta de receta de referencia rápida, lista para copiar y pegar.

from pydantic_settings import BaseSettings, SettingsConfigDict
 
class AppSettings(BaseSettings):
    model_config = SettingsConfigDict(env_file=".env", extra="ignore")
    environment: str = "dev"
    database_url: str
    log_level: str = "info"
 
settings = AppSettings()  # lee variables de entorno y opcionalmente .env localmente

# app.env.j2
APP_ENV={{ environment }}
DATABASE_URL={{ database_url }}
LOG_LEVEL={{ log_level }}

Cuándo usar esto:

• Misma plantilla, diferentes valores entre desarrollo/staging/producción
• Secretos fuera de git con referencias inyectadas en el momento del despliegue
• Validación de configuración antes de la aplicación con modelos Pydantic
• Indicadores de funciones y límites que difieren por entorno
• Ansible/Pulumi/Terraform consumiendo todos un esquema de configuración

Ejemplo de Trabajo

Configuración YAML en capas, renderizado Jinja2 y stub de búsqueda de secretos para un script de despliegue.

"""render_config.py - carga la configuración del entorno, fusiona secretos, renderiza plantilla."""
from __future__ import annotations
 
import json
from pathlib import Path
 
import yaml
from jinja2 import Environment, FileSystemLoader, select_autoescape
 
ROOT = Path(__file__).parent
CONFIG_DIR = ROOT / "config"
 
def load_yaml(path: Path) -> dict:
    with path.open() as f:
        return yaml.safe_load(f) or {}
 
def load_config(environment: str) -> dict:
    base = load_yaml(CONFIG_DIR / "base.yaml")
    env = load_yaml(CONFIG_DIR / f"{environment}.yaml")
    merged = {**base, **env, "environment": environment}
    return merged
 
def fetch_secret(name: str) -> str:
    # Producción: boto3.client("secretsmanager").get_secret_value(...)
    return f"SECRET::{name}"
 
def render(template_name: str, context: dict) -> str:
    env = Environment(
        loader=FileSystemLoader(ROOT / "templates"),
        autoescape=select_autoescape(),
    )
    template = env.get_template(template_name)
    return template.render(**context)
 
if __name__ == "__main__":
    cfg = load_config("staging")
    cfg["database_password"] = fetch_secret("db/password")
    output = render("service.env.j2", cfg)
    print(output)
    print(json.dumps({"rendered_for": cfg["environment"]}))

# config/base.yaml
log_level: info
service_port: 8080

# config/staging.yaml
database_host: staging.db.internal
feature_new_ui: true

# templates/service.env.j2
APP_ENV={{ environment }}
LOG_LEVEL={{ log_level }}
PORT={{ service_port }}
DATABASE_HOST={{ database_host }}
DATABASE_PASSWORD={{ database_password }}
FEATURE_NEW_UI={{ feature_new_ui }}

Lo que esto demuestra:

• La fusión de YAML base + entorno mantiene la estructura DRY (Don't Repeat Yourself)
• Los secretos se obtienen en el momento de la renderización, nunca se incluyen en las plantillas
• Jinja2 renderiza los archivos de entorno finales para la inyección en contenedores o el módulo template de Ansible
• La línea de registro JSON registra qué entorno se renderizó para auditoría

Análisis Profundo

Cómo Funciona

• Capa de datos: YAML/JSON/TOML por entorno + validación de esquema
• Capa de secretos: SSM, Secrets Manager, Vault o almacén de secretos de CI
• Capa de plantillas: Jinja2, envsubst o variables de Terraform/Pulumi
• Capa de aplicación: Ansible, Kubernetes o systemd cargan los artefactos renderizados
• Flujo de cambios: editar configuración en git → validar → renderizar → desplegar → verificar

Configuración vs. Secretos

Notas de Python

from pydantic import Field, SecretStr
from pydantic_settings import BaseSettings
 
class DeploySettings(BaseSettings):
    environment: str
    db_password: SecretStr = Field(alias="DATABASE_PASSWORD")
 
    def redacted(self) -> dict:
        return self.model_dump(mode="json", exclude={"db_password"})

Errores Comunes

• Secretos en prod.yaml: credenciales en el historial de git para siempre. Solución: almacenar ARN o nombres de secretos, resolver en tiempo de ejecución.
• Plantillas bifurcadas por entorno: deriva cuando un entorno recibe una corrección. Solución: una plantilla, solo datos específicos del entorno.
• Falta de validación: los errores tipográficos llegan a producción como despliegues fallidos. Solución: modelos Pydantic o JSON Schema en CI.
• Archivos renderizados legibles por cualquiera: chmod 644 en .env con contraseñas. Solución: propiedad 0600 solo para el usuario del servicio.
• Plantillas con entrada no confiable: SSTI (Server-Side Template Injection) si las plantillas incluyen contenido del usuario. Solución: mantener las plantillas internas; nunca incrustar cadenas de usuario en Jinja2.

Alternativas

Preguntas Frecuentes

Relacionado

• Conceptos Básicos de Automatización de Infraestructura - separación de entornos
• Ansible - módulo template y group_vars
• Secrets Manager & SSM - resolución de secretos de AWS
• Configuración y Secretos en Producción - inyección en tiempo de ejecución
• Mejores Prácticas de Automatización de Infraestructura - reglas de configuración versionada

Versiones de la pila: Esta página fue escrita para Python 3.14.0 (estable 3.14, mantenimiento 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, y uv 0.6+.