Diversi metodi per distribuire il progetto Django e i loro pro e contro?

Question

Sono abbastanza un noob quando si tratta di distribuire un progetto Django. Mi piacerebbe sapere quali sono i vari metodi per distribuire il progetto Django e quale è il più preferito.

Answer 1

Utilizzare Nginx/Apache/mod-wsgi e non si può sbagliare.

Se si preferisce un'alternativa semplice, è sufficiente utilizzare Apache.

C'è un buon documento di distribuzione: http://lethain.com/entry/2009/feb/13/the-django-and-ubuntu-intrepid-almanac/

Answer 2

La documentazione Django elenca Apache/mod_wsgi, Apache/mod_python e FastCGI ecc

mod_python è deprecato ora, si dovrebbe utilizzare mod_wsgi invece.

Django con mod_wsgi è facile da installare, ma:

• è possibile utilizzare solo una versione di Python alla volta [edit: si può anche utilizzare solo la mod_wsgi versione di Python è stato compilato per]
• [edit: sembra se sbaglio su mod_wsgi che non supportano virtualenv: lo fa]

Così per più siti (target differenti versioni Django/Python) su un server non è mod_wsgi i bes t soluzione.

FastCGI può essere utilizzato con virtualenv, anche con diverse versioni di Python, come si esegue con

 
./manage.py runfcgi … 

e quindi configurare il server web per utilizzare questa interfaccia fcgi.

Il nuovo, roba calda sulla distribuzione di django sembra essere gunicorn. È un server web che implementa wsgi e viene in genere utilizzato come back-end con un server web "grande" come proxy.

La distribuzione con gunicorn sembra molto simile a fcgi: si esegue un processo che esegue il processo di elaborazione django con manage.py e un server web come frontend per il mondo.

Ma gunicorn distribuzione ha alcuni vantaggi rispetto fcgi:

• velocità - non ho trovato le fonti, ma benchmark dicono fcgi non è veloce come la f suggerisce
• file di configurazione, per fcgi voi deve eseguire tutte le configurazioni sulla riga di comando durante l'esecuzione del comando manage.py. Ciò risulta non pertinente quando si eseguono più istanze di django tramite un init.d (avvio del servizio di sistema del sistema operativo unix-like). È sempre la stessa cmdline, con solo file di configurazione diversi
• gunicorn può rilasciare i privilegi: non è necessario farlo nello script init.d ed è facile passare a un utente per istanza di django
• gunicorn si comporta più come un daemon: scrivendo file pid e file di log, biforcandosi sullo sfondo, ecc. lo rende più facile usarlo in uno script init.d.

Pertanto, suggerirei di utilizzare la soluzione gunicorn, a meno che non si disponga di un singolo sito su un singolo server con poco traffico, di quanto si possa utilizzare la soluzione wsgi. Ma penso che a lungo termine sei più felice con Gunicorn.

Se si dispone di un server Web solo per Django, suggerirei di usare nginx come frontendproxy, poiché è il migliore (di nuovo basato su benchmark che ho letto in alcuni post sul blog - non ho più l'url). Personalmente uso Apache come frontendproxy, poiché ne ho bisogno per altri siti ospitati sul server.

una semplice istruzione di installazione per la distribuzione di Django potrebbe essere trovato qui: http://ericholscher.com/blog/2010/aug/16/lessons-learned-dash-easy-django-deployment/

Il mio script init.d per gunicorn si trova a github: https://gist.github.com/753053

Purtroppo non ho ancora blog su di esso, ma un sysadmin esperto dovrebbe essere in grado di eseguire l'installazione richiesta.

Answer 3

Io stesso ho affrontato un sacco di problemi nell'implementazione di Django Projects e nell'automatizzazione del processo di implementazione. Apache e mod_wsgi erano come una maledizione per Django Deployment. Ci sono diversi strumenti come Nginx, Gunicorn, SupervisorD e Fabric che sono di tendenza per la distribuzione di Django. Inizialmente li ho usati/configurati singolarmente senza l'automazione di deployment che impiegava molto tempo (dovevo mantenere i test e i server di produzione per il mio cliente e dovevo aggiornarli non appena una nuova funzionalità veniva testata e approvata). Mi sono imbattuto in django-fagungis, che automatizza totalmente la mia distribuzione Django dalla clonazione del mio progetto da bitbucket alla distribuzione sul mio server remoto (utilizza Nginx, Gunicorn, SupervisorD, Fabtic e virtualenv e installa anche tutte le dipendenze al volo), tutte con solo tre comandi :) Puoi trovare ulteriori informazioni nel mio post sul blog here. Ora non ho nemmeno bisogno di essere coinvolto in questo processo (che mi prendeva molto del mio tempo) e uno dei miei sviluppatori più giovani esegue questi tre comandi di django-fagungis mentioned here sul suo computer locale e otteniamo una nuova copia nitida del nostro progetto distribuito in pochi minuti senza alcun problema :)