Modificar archivos directamente en un servidor de producción es una práctica riesgosa que puede generar inconsistencias entre el repositorio y lo que realmente corre en la máquina. La forma correcta de manejar la configuración es a través de variables de entorno y un archivo .env, lo que permite separar la lógica de la aplicación de sus valores sensibles.
¿Por qué no deberías modificar archivos directamente en producción?
Cuando se configura un servidor por primera vez, es tentador editar los archivos de la aplicación directamente para probar si los cambios corrigen problemas. Sin embargo, esto genera archivos modificados que quedan fuera de sincronía con el repositorio. Al ejecutar git status dentro del directorio del proyecto [0:29], se pueden ver esos cambios, y con git diff se confirma exactamente qué se alteró: en este caso, el ALLOW_HOST y la integración de Sentry [0:42].
La solución es traer todos los cambios desde el repositorio y utilizar un archivo .env para configurar la aplicación según el entorno donde se ejecute.
¿Qué variables de entorno se configuran en un proyecto Django?
El repositorio del proyecto incluye documentación sobre las variables disponibles [1:04]. Cada una cumple un rol específico:
- SECRET_KEY: clave que Django utiliza para encriptar datos sensibles como sesiones y tokens.
- DEBUG: controla si se muestran los detalles completos de un error en el navegador; debe estar en
False en producción.
- SENTRY_DSN: clave única que conecta la aplicación con la cuenta de Sentry para el monitoreo de errores [1:24].
- ALLOW_HOST: lista de dominios autorizados para acceder a la aplicación, por ejemplo
deploywithpython.local o deploywithpython.com [1:35].
- DATABASE_URL: define la conexión a la base de datos; por defecto apunta a un archivo SQLite, pero se puede cambiar a un servidor como Postgres [1:59].
¿Cómo crear el archivo .env en el servidor?
El proceso es directo. Dentro del servidor, se crea un archivo de texto plano llamado .env utilizando un editor como Bin [2:15]:
SENTRY_DSN=https://tu-clave@sentry.io/proyecto
ALLOW_HOST=deploywithpython.com
El valor de SENTRY_DSN se obtiene desde el panel de Sentry, en la sección Client Keys de la configuración del proyecto [2:27]. Para ALLOW_HOST, se coloca únicamente el dominio, sin protocolo (http:// o https://) [2:42].
¿Cómo aplicar los cambios del archivo .env?
Una vez guardado el archivo, los cambios no se aplican automáticamente. Es necesario reiniciar el servidor de UWSGI con el siguiente comando [2:55]:
bash
sudo service uwsgi restart
Al recargar el sitio, la aplicación debería seguir funcionando correctamente [3:03]. En el archivo settings.py del proyecto, el inicializador de Sentry ya toma el valor de DSN desde la variable de entorno, lo que significa que los cambios manuales previos pueden eliminarse sin problema [3:13].
¿Qué sigue después de configurar las variables de entorno?
Con el archivo .env funcionando, el siguiente paso es conectar un motor de base de datos diferente a SQLite. La variable DATABASE_URL ya está preparada para recibir una cadena de conexión a Postgres, que se creará dentro de la consola de AWS [3:25]. Esto permite escalar la aplicación y manejar datos de forma más robusta en producción.
Si ya estás trabajando con tu propio servidor, prueba crear tu archivo .env y comparte cómo organizas tus variables de entorno en los comentarios.
