Despliega Django en Nodion

Despliega Django paso a paso

1. Añade Gunicorn, WhiteNoise y un driver de base de datos Nodion arranca Gunicorn, pero no lo instala, así que tiene que estar en tus dependencias. Gunicorn no sirve archivos estáticos; de eso se encarga WhiteNoise con lo que escribe collectstatic. Fija la versión de Python en .python-version, porque un rango como requires-python = ">=3.10" elige la versión más reciente. requirements.txt

   Django>=5.2
   gunicorn
   whitenoise
   dj-database-url
   psycopg[binary]

2. Lee la configuración del entorno collectstatic se ejecuta durante la build, donde solo existen las variables marcadas con Build, así que la configuración tiene que poder importarse sin los secretos de runtime. Django solo comprueba SECRET_KEY cuando se usa. Añade WhiteNoise justo después de SecurityMiddleware. settings.py

   import os
   import dj_database_url
   
   SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY", "")
   DEBUG = os.environ.get("DJANGO_DEBUG") == "1"
   ALLOWED_HOSTS = os.environ.get("DJANGO_ALLOWED_HOSTS", "").split(",")
   CSRF_TRUSTED_ORIGINS = [f"https://{h}" for h in ALLOWED_HOSTS if h]
   
   DATABASES = {"default": dj_database_url.config(conn_max_age=600)}
   
   STATIC_ROOT = BASE_DIR / "staticfiles"
   # MIDDLEWARE: "whitenoise.middleware.WhiteNoiseMiddleware"
   # right after "django.middleware.security.SecurityMiddleware"

3. Responde al health check antes de comprobar el host El health check de Nodion llama a cada instancia por su dirección interna, que no está en ALLOWED_HOSTS, así que Django respondería con un 400 y la release nunca entraría en producción. Pon un middleware sencillo en primer lugar en MIDDLEWARE y configura /healthz como ruta del health check en los ajustes de la app. health.py

   from django.http import HttpResponse
   
   
   class HealthCheckMiddleware:
       def __init__(self, get_response):
           self.get_response = get_response
   
       def __call__(self, request):
           if request.path == "/healthz":
               return HttpResponse("ok")
           return self.get_response(request)

4. Ejecuta las migraciones en cada despliegue Una línea release: en un Procfile se ejecuta una vez por build, después de la build y antes de que arranque la nueva versión. Si falla, el despliegue se detiene y la versión en ejecución sigue activa. Procfile

   release: python manage.py migrate --noinput

5. Crea la app y la base de datos Crea una aplicación desde tu repositorio en la región EU Central, después una base de datos PostgreSQL en la misma región, y vincúlala en la pestaña Environment: la app recibe DATABASE_URL en el siguiente despliegue. Define DJANGO_SECRET_KEY como secreto y DJANGO_ALLOWED_HOSTS con el hostname de tu app y tus propios dominios, y haz push.

A tener en cuenta

• Celery y otros workersAñade al Procfile worker: celery -A myproject worker junto con una línea web: gunicorn myproject.wsgi --bind 0.0.0.0:$PORT explícita; sin una línea web:, la primera entrada del Procfile que no sea release: pasa a ser el comando por defecto. Después, en la pestaña Processes, añade un proceso llamado worker sin puerto. Valkey en la misma región te da REDIS_URL como broker.
• ASGIEl comando de inicio por defecto usa WSGI. Para Channels o vistas asíncronas, define tu propia línea web:, por ejemplo con workers de Uvicorn, y haz que escuche en 0.0.0.0:$PORT.
• Archivos de dependenciasrequirements.txt, poetry.lock y Pipfile.lock se instalan tal cual. Un Pipfile sin su lockfile no instala nada.

Lo que Nodion gestiona por ti

• Despliegues sin downtime Haz push a tu rama y Nodion construye una nueva release. El tráfico pasa a las nuevas instancias cuando superan el health check; si una release falla, la que está en marcha sigue activa. En cambio, las apps con un volumen local se reinician porque el disco pertenece a una sola instancia.
• Bases de datos junto a la app PostgreSQL, pgvector, MySQL, Valkey y ClickHouse gestionados en la misma región. Al vincular una base de datos, sus datos de conexión llegan como DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Previews por pull request Activa las previews: cada pull request de tu repositorio tendrá su propia app, con URL y bases de datos nuevas y vacías. Puedes crearla automáticamente o a mano. Se omiten las pull requests de forks y bots.
• Workers, cron jobs y escalado Ejecuta workers como procesos adicionales de la misma app, programa tareas en la pestaña Cron y escala cada proceso hasta 16 instancias.
• Paso de release Con buildpacks, una línea release: del Procfile se ejecuta con cada nueva build. Las apps con Dockerfile, así como los redeploys o rollbacks a una imagen anterior, usan un comando de release definido en la propia app, que además tiene prioridad sobre la línea del Procfile. En los sitios estáticos, el paso de release se ejecuta en una imagen que solo contiene los archivos generados por la build.
• Logs y métricas Logs de build, release y runtime, además de métricas de CPU, memoria, disco y red de cada instancia, en el dashboard.
• Dominios y HTTPS Un nombre de host predeterminado con HTTPS desde el primer despliegue; tus propios dominios reciben certificados automáticamente.

Para seguir leyendo

• Alternativas a Heroku con hosting en la UE: 5 opciones Una plataforma alemana y clouds estadounidenses con regiones en la UE, comparados por sede, regiones y bases de datos gestionadas.
• Entornos de preview: una app para cada pull request Una copia en ejecución de tu app para cada pull request: para qué sirven los entornos de preview, dónde se complican y cómo los gestiona Nodion.

Django en Nodion: preguntas y respuestas