Fai il deploy di Django su Nodion

Deploy di Django passo dopo passo

1. Aggiungi Gunicorn, WhiteNoise e un driver per il database Nodion avvia Gunicorn ma non lo installa, quindi deve stare tra le tue dipendenze. Gunicorn non serve file statici: ci pensa WhiteNoise a servire ciò che scrive collectstatic. Fissa la versione di Python in .python-version, perché un intervallo come requires-python = ">=3.10" sceglie la release più recente. requirements.txt

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

2. Leggi le impostazioni dall'ambiente collectstatic viene eseguito durante la build, dove esistono solo le variabili contrassegnate con Build, quindi le impostazioni devono poter essere importate senza le variabili segrete di runtime. Django controlla SECRET_KEY solo quando la usa. Aggiungi WhiteNoise subito dopo 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. Rispondi all'health check prima del controllo dell'host L'health check di Nodion chiama ogni istanza tramite il suo indirizzo interno, che non è in ALLOWED_HOSTS: Django risponderebbe con 400 e la release non andrebbe mai online. Metti un piccolo middleware al primo posto in MIDDLEWARE e imposta /healthz come percorso dell'health check nelle impostazioni dell'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. Esegui le migrazioni a ogni deploy Una riga release: in un Procfile viene eseguita una volta per ogni build, dopo la build e prima che parta la nuova versione. Se fallisce, il deploy si ferma e la versione in esecuzione resta online. Procfile

   release: python manage.py migrate --noinput

5. Crea l'app e il database Crea un'applicazione dal tuo repository nella regione EU Central, poi un database PostgreSQL nella stessa regione e collegalo nella scheda Environment: al deploy successivo arriva come DATABASE_URL. Imposta DJANGO_SECRET_KEY come variabile segreta e DJANGO_ALLOWED_HOSTS con l'hostname della tua app e i tuoi domini, poi fai push.

Da sapere

• Celery e altri workerAggiungi al Procfile worker: celery -A myproject worker insieme a una riga esplicita web: gunicorn myproject.wsgi --bind 0.0.0.0:$PORT; senza una riga web:, la prima voce del Procfile diversa da release: diventa il comando predefinito. Poi, nella scheda Processes, aggiungi un processo chiamato worker senza porta. Valkey nella stessa regione ti fornisce REDIS_URL come broker.
• ASGIIl comando di avvio predefinito usa WSGI. Per Channels o per le view asincrone, imposta una riga web:, per esempio con worker Uvicorn, e metti il server in ascolto su 0.0.0.0:$PORT.
• File delle dipendenzerequirements.txt, poetry.lock e Pipfile.lock vengono installati così come sono. Un Pipfile senza il suo lock file non installa nulla.

Cosa gestisce Nodion per te

• Deploy senza downtime Fai push sul tuo branch e Nodion crea una nuova release. Il traffico passa alle nuove istanze solo quando superano l'health check; una release fallita lascia attiva quella in esecuzione. Le app con un volume locale invece si riavviano, perché il disco appartiene a una sola istanza.
• Database accanto all'app PostgreSQL, pgvector, MySQL, Valkey e ClickHouse gestiti, nella stessa regione. I database collegati arrivano come DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Anteprime per ogni pull request Attiva le anteprime: ogni pull request del tuo repository riceve un'app dedicata, con un proprio URL e database nuovi e vuoti, creata automaticamente o manualmente. Le pull request dai fork e quelle dei bot vengono ignorate.
• Worker, cron job e scalabilità Esegui i worker come processi aggiuntivi della stessa app, pianifica i job nella scheda Cron e scala ogni processo fino a 16 istanze.
• Fase di release Con i buildpack, la riga release: del Procfile viene eseguita a ogni nuova build. Le app con Dockerfile, così come i redeploy e i rollback a un'immagine precedente, usano un comando di release impostato sull'app stessa, che ha anche la precedenza sulla riga del Procfile. Nei siti statici, la fase di release gira in un'immagine che contiene solo i file generati dalla build.
• Log e metriche Nella dashboard trovi log di build, release e runtime, oltre alle metriche di CPU, memoria, disco e rete per ogni istanza.
• Domini e HTTPS Un hostname predefinito con HTTPS dal primo deploy; i tuoi domini ricevono i certificati in automatico.

Per approfondire

• Alternative a Heroku con hosting UE: 5 opzioni a confronto Una piattaforma tedesca e cloud statunitensi con regioni nell'UE, a confronto per sede, regioni e database gestiti.
• Ambienti di anteprima spiegati: un'app per ogni pull request Una copia in esecuzione della tua app per ogni pull request: a cosa servono gli ambienti di anteprima, dove diventano complicati e come li gestisce Nodion.

Django su Nodion: domande e risposte