2012-02-18 11 views
70

Ho sempre utilizzato virtualenv per testare la mia app in localhost poiché ho un ambiente isolato e posso testare in sicurezza la nuova versione dei pacchetti.È consigliato virtualenv per server di produzione django?

Ora arriva il momento in cui devo distribuire la mia app su un server di produzione. Mi chiedo se dovrei usare virtualenv anche per il server di produzione o solo l'installazione normale dovrebbe fare. Dal momento che si tratta di server di produzione, posso sempre utilizzare la versione corretta che ho testato nel server di sviluppo (sotto virtual-env)

+3

Si noti che la documentazione ufficiale di Django menziona l'utilizzo di virtualenv in produzione: https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/modwsgi/#using-a-virtualenv –

+0

Mi raccomando il tutorial di @ Bartek [La bella semplicità di un nginx e uWSGI Deployment] (http://bartek.im/blog/2012/07/08/simplicity-nginx-uwsgi-deployment.html) –

+0

Heroku lo raccomanda: https: // DevCenter. heroku.com/articles/deploying-python –

risposta

42

Farei in questo modo se pensi di eseguire più di un progetto sul server web. Non appena si hanno due progetti si corre il rischio di un aggiornamento futuro di qualsiasi pacchetto Python che rompa l'altro sito.

+1

Ciò solleva la questione se virtualenv dovrebbe essere usato quando si sa che questo server esiste unicamente per servire una singola applicazione. –

+4

Non è possibile garantire che DevOps non esegua il roll out di qualcosa che richiede dipendenze Python. Dovrebbe essere separato in ogni momento. –

9

Sì, penso che si dovrebbe usare virtualenv per ricorrere ad esso in produzione. Rende le cose molto più semplici e più pulite per te, specialmente se prevedi di distribuire più servizi, ad es. siti web basati su Django o altri progetti Python. Non vuoi che ognuno di loro stia inquinando l'ambiente Python globale con i loro pacchetti.

Penso che virtualenv ti aiuterà a gestire in modo pulito tutte le tue dipendenze.

di aggiornare il tuo env produzione tutto quello che dovete fare è:

pip -r name_of_your_requirements_file.txt 

Io uso virtualenvs in produzione, e si può usare uWSGI per servire le applicazioni, con Cherokee come un server web.

Per utilizzare il virtualenv in produzione, è necessario aggiungerne il percorso al PYTHONPATH.

Ad esempio se il vostro ENV ha il percorso "/ home/www/my_project/ENV /", il percorso per aggiungere sarebbe:

/home/www/env/lib/python2.7/site-packages/ 

È possibile impostare questa funzione in molti modi diversi, ma se si sta generando il tuo fcgi o interfaccia uWSGI attraverso manage.py, è sufficiente aggiungere il seguente nella parte superiore del vostro manage.py (prima che il resto):

import os 
my_virtualenv_path = "/home/www/my_project/env/lib/python2.7/site-packages/" 
# Add it to your PYTHONPATH 
os.path.append(my_virtualenv_path) 

È possibile adattare questo al vostro setup, solo in caso si potrebbe anche fare quanto segue nella shell:

export PYTHONPATH:$PYTHONPATH:/home/www/my_project/env/lib/python2.7/site-packages/ 

Sarà inoltre necessario aggiungere la directory che contiene il file settings.py al PYTHONPATH, quindi Django sarà in grado di scoprirlo. Procedi in modo simile per farlo.

14

È consigliato virtualenv per server di produzione django?

Sì, fa il vostro progetto non dipende da alcuni aspetti dell'ambiente di sistema ed inoltre consente di effettuare il processo di distribuzione più chiaro e configurabile.

Uso fabric, pip e virtualenv per distribuire tutti i miei progetti Django.

+0

Non credo "inaffidabile" è la parola che si voleva (il sistema non può dipendere dal vostro progetto?). Linguaggio chiarito –

3

Nella maggior parte dei casi sono d'accordo che è meglio avere un virtualenv, anche se non sembra che tu abbia bisogno, quando la prima configurazione del server. Detto questo, se si utilizza un qualche tipo di servizio cloud e girare i server per un compito specifico per un breve periodo di tempo, allora non vedo il punto di usare un virtualenv.

0

Utilizzando contenitori Docker sia per lo sviluppo e la distribuzione di produzione è piuttosto popolare ora, quindi se state pensando seguendo questa tendenza, non sarà più bisogno di virtualenv.

Problemi correlati