Come si distribuisce un'applicazione Django in produzione?

Question

Accepted Answer

La distribuzione di Django in produzione comporta l'esecuzione dietro un appropriato **server WSGI/ASGI** e un **web server**, la corretta gestione dei file statici, la protezione delle impostazioni e la gestione del database — molto diverso dal server di sviluppo integrato (che **non** è adatto per la produzione).

## Lo stack di produzione

```text
Client → NGINX (web server) → GUNICORN (WSGI app server) → DJANGO
           │                      (runs your Python app, multiple workers)
           └─ serves static/media files directly (efficient)

❌ NEVER use `python manage.py runserver` in production — it's single-threaded,
   insecure, and not built for load. Use Gunicorn (WSGI) or Uvicorn (ASGI for async).
```

Il server di sviluppo non è adatto per la produzione. Lo stack standard: un **application server** (Gunicorn/uWSGI per WSGI, Uvicorn per ASGI/async) esegue Django con più worker, dietro a un **web server** (nginx) che gestisce le connessioni in ingresso, TLS e i file statici.

## Impostazioni di produzione (critiche per la sicurezza)

```python
DEBUG = False                            # ❗ MUST be False — DEBUG=True leaks sensitive info
ALLOWED_HOSTS = ["example.com"]          # required when DEBUG=False
SECRET_KEY = os.environ["SECRET_KEY"]    # from the environment, NOT committed
SECURE_SSL_REDIRECT = True               # force HTTPS
SESSION_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 31536000
```

## File statici

```bash
python manage.py collectstatic           # gather static files into STATIC_ROOT
# then serve them via nginx or a CDN — or use WhiteNoise to serve them from the app
# (Django does NOT serve static files itself in production)
```

## Database e migrazioni

```bash
python manage.py migrate                  # apply migrations to the production DB
# use a real database (PostgreSQL), connection pooling, regular backups
```

## Una tipica checklist per la distribuzione

```text
1. Set production environment variables (SECRET_KEY, DB credentials, DEBUG=False)
2. Run migrations (manage.py migrate)
3. Collect static files (collectstatic) → serve via nginx/CDN/WhiteNoise
4. Run the app with Gunicorn/Uvicorn (multiple workers, behind nginx)
5. Enable HTTPS (TLS certificates, e.g. Let's Encrypt)
6. Set up logging, error monitoring (Sentry), health checks
7. Add a process manager (systemd/supervisor) or use containers (Docker) + orchestration
8. Run `manage.py check --deploy` to audit security settings
```

## Approcci di distribuzione moderni

```text
✓ Containers (Docker) + orchestration (Kubernetes) or platforms (Heroku, Railway, Render)
✓ Managed databases, separate static/media storage (S3 + CDN)
✓ Background workers (Celery) + a broker (Redis) as separate services
✓ Horizontal scaling: multiple app instances behind a load balancer (keep app STATELESS)
```

## Perché è importante

La corretta distribuzione di Django in produzione è una conoscenza essenziale per portare le applicazioni dallo sviluppo all'uso nel mondo reale, e comporta considerazioni importanti che differiscono fondamentalmente dallo sviluppo locale — un'implementazione scorretta porta a vulnerabilità di sicurezza, scarso rendimento o applicazioni non funzionanti.

Comprendere lo **stack di produzione** è fondamentale: il server di sviluppo integrato (`runserver`) è esplicitamente non adatto per la produzione (è a thread singolo, insicuro e non può gestire il carico), quindi devi eseguire Django dietro un appropriato **application server** (Gunicorn/uWSGI per WSGI, o Uvicorn per ASGI/async) con più worker, davanti a un **web server** (nginx) che gestisce le connessioni, TLS e la distribuzione dei file statici.

Vari aspetti sono critici per la sicurezza e la correttezza: le **impostazioni di produzione** (soprattutto `DEBUG=False`, che è obbligatorio poiché `DEBUG=True` espone traceback sensibili e configurazione agli attaccanti, più `ALLOWED_HOSTS`, una `SECRET_KEY` segreta proveniente dall'ambiente, e l'applicazione di HTTPS), la **gestione dei file statici** (esecuzione di `collectstatic` e distribuzione dei file tramite nginx/CDN/WhiteNoise, poiché Django non li distribuisce stesso in produzione — un errore di distribuzione comune), e la **gestione del database** (un database reale come PostgreSQL, applicazione delle migrazioni, backup).

Conoscere la checklist di distribuzione, gli approcci moderni (Docker/container, piattaforme gestite, storage cloud per i media, worker Celery come servizi separati, scaling orizzontale con app senza stato), e le considerazioni operative (logging, monitoraggio con Sentry, health check, gestione dei processi) è ciò che distingue una distribuzione di produzione funzionante da una fragile o insicura.

Poiché ogni applicazione Django reale deve alla fine essere distribuita, e poiché gli errori di distribuzione (lasciare `DEBUG=True`, gestire male i file statici, esporre i segreti, usare il server di sviluppo) causano veri problemi di sicurezza e affidabilità, comprendere come distribuire Django correttamente — lo stack, le impostazioni critiche per la sicurezza, la gestione dei file statici/media e le pratiche di distribuzione moderna — è una conoscenza importante e ad alto rischio che riflette la capacità di spedire applicazioni pronte per la produzione, un argomento frequentemente rilevante e professionalmente essenziale per qualsiasi sviluppatore Django responsabile di sistemi live.