Gunicorn come server WSGI

Il runserver di Django è ottimo per programmare, ma usa un solo thread e non è sicuro per il web pubblico. In produzione serve un vero server applicativo. 🚀

WSGI è il contratto standard tra un'app web Python e un server. Permette a qualsiasi server di comunicare con Django senza conoscerne i dettagli interni.

Gunicorn è un server WSGI per la produzione che carica l'app Django ed elabora rapidamente, stabilmente e in concorrenza numerose richieste.

Aggiunga Gunicorn al suo ambiente con pip, poi lo fissi in requirements.txt affinché ogni deploy utilizzi la stessa versione.

Ogni progetto include un wsgi.py che espone un oggetto chiamato application. Gunicorn importa esattamente quell'oggetto per servire il sito.

Indichi a gunicorn il modulo wsgi del progetto. Il percorso puntato rispecchia il modo in cui Python lo importa e termina con application.

Utilizzi --bind per scegliere host e porta. L'associazione a 0.0.0.0 permette al mondo esterno di raggiungere il server, non solo localhost.

Ogni worker è un processo che serve le richieste in parallelo. Un punto di partenza comune è 2 volte il numero di core della CPU più 1; poi adatti il valore al traffico reale.

Gunicorn esegue il codice Python, non serve i file. La distribuzione di CSS e immagini spetta invece a Nginx o WhiteNoise.

Un server attivo deve sopravvivere a riavvii e arresti anomali. Un gestore dei processi come systemd riavvia automaticamente Gunicorn, mantenendo il sito online.

L'opzione --timeout termina i worker bloccati su richieste lente. Il valore predefinito è di 30 secondi: protegge dal rischio che una view bloccata congeli tutto.

Ha imparato che Gunicorn è il server WSGI di produzione che esegue Django tramite wsgi:application, si adatta al carico con i worker e lascia i file statici ad altri componenti. 🎯