Variables de entorno Django en servidor

Adopta una configuración segura y reproducible: deja de editar archivos en producción y centraliza los ajustes en variables de entorno. Así mejoras seguridad, trazabilidad y velocidad de despliegue, apoyándote en el repositorio y un archivo .env que la aplicación leerá al iniciar.

¿Por qué dejar de editar en producción y usar variables de entorno?

Modificar archivos directamente en el servidor puede introducir errores y dificulta auditar cambios. La transición a cambios desde el repositorio y a un .env reduce riesgos y estandariza la configuración entre entornos.

• Se detectaron cambios locales con git para debugging y Sentry, además de un uso previo de env.list.
• La rama develop contiene documentación para correr en local y la guía de variables de entorno.
• La configuración pasará a variables como SECRET_KEY, DEBUG, SENTRY_DSN, ALLOW_HOST y DATABASE_URL.

¿Qué prácticas con git confirman el estado actual?

• Ejecutar git status para ver archivos modificados.
• Revisar cambios con git diff y confirmar ediciones a allow_host e instalación de Sentry.

¿Qué variables de entorno clave se configuran en Django?

Estas variables hacen la configuración explícita y portable entre entornos.

• SECRET_KEY: clave de cifrado en Django para datos sensibles.
• DEBUG: activa o desactiva detalles de error en navegador.
• SENTRY_DSN: integra Sentry para capturar y enviar errores a tu cuenta.
• ALLOW_HOST: lista de dominios permitidos para acceder a la app; usa solo el dominio, sin protocolo.
• DATABASE_URL: define el motor y la conexión a base de datos; por defecto es sqlite con archivo local y luego podrá apuntar a postgres.

Puntos clave. - Ejemplos de host: deploying_with_python.local y .com; luego se deja solo deploying_with_python. - La documentación de variables indica qué opciones están disponibles y cómo usarlas.

¿Cómo crear y cargar el archivo .env en el servidor?

El objetivo es que el código lea los valores desde un archivo simple y que el servicio los aplique al reiniciar.

• Ir a la ruta de la app: server/apps/Django.
• Crear un archivo de texto: bin.env con tu editor preferido.
• Pegar SENTRY_DSN usando el valor previo o desde Sentry en settings, client_keys.
• Definir ALLOW_HOST copiándolo de la documentación y usando solo el dominio.
• Guardar el archivo y reiniciar servicios para aplicar cambios.

¿Qué comandos y rutas necesitas?

• Ruta de la app: server/apps/Django.
• Reinicio del servicio de la aplicación: sudo service uwsgi restart.
• Verificación: recargar el sitio y confirmar que funciona correctamente.

¿Qué efectos observarás tras reiniciar uwsgi?

• El inicializador de Sentry en settings toma su DSN desde la variable de entorno.
• Puedes eliminar cambios manuales hechos en el servidor porque la configuración ahora vive en .env.
• Queda listo el .env para migrar de sqlite a postgres cuando se provisionen recursos en AWS.

¿Ya centralizaste tu configuración en .env? Cuéntame en comentarios qué variables te resultan imprescindibles y qué comandos usas para validar tu despliegue.