web-dev-qa-db-fra.com

Virtualenv est-il recommandé pour Django serveur de production?

J'ai toujours utilisé virtualenv pour tester mon application dans localhost depuis que j'ai un environnement isolé et que je peux tester en toute sécurité de nouvelles versions de packages.

Maintenant, c'est le moment où je dois déployer mon application sur un serveur de production. Je me demande si je devrais également utiliser virtualenv pour le serveur de production ou si une installation normale devrait le faire. Comme c'est un serveur de production, je peux toujours utiliser la bonne version que j'ai testée sur le serveur de développement (sous virtual-env)

pythondjangodeployment
75
w00d

Je le ferais de cette façon si vous pensez que vous exécuterez plus d'un projet sur le serveur Web. Dès que vous avez deux projets, vous courez le risque d'une future mise à niveau de tout paquet python cassant l'autre site).

47
Kurt

Virtualenv est-il recommandé pour Django serveur de production?

Oui, cela ne dépend pas de certains aspects de l'environnement système et vous permet également de rendre le processus de déploiement plus clair et configurable.

J'utilise fabric, pip et virtualenv pour déployer tous mes projets Django.

15
Gregory Petukhov

Oui, je pense que vous devriez utiliser virtualenv pour le déployer en production. Cela rend les choses beaucoup plus faciles et plus propres pour vous, surtout si vous prévoyez de déployer plusieurs services, par exemple Django sites Web ou autres projets python. Vous ne voulez pas que chacun d'eux pollue l'environnement global python) avec leurs packages.

Je pense que virtualenv vous aidera à gérer proprement toutes vos dépendances.

Pour mettre à jour votre environnement de production, il vous suffit de:

pip -r name_of_your_requirements_file.txt

J'utilise virtualenvs en production, et vous pouvez utiliser uWSGI pour servir les applications, avec Cherokee comme serveur web.

Pour utiliser votre virtualenv en production, vous devrez ajouter son chemin à votre PYTHONPATH.

Par exemple, si votre env a le chemin "/ home/www/mon_projet/env /", le chemin à ajouter serait:

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

Vous pouvez configurer cela de différentes manières, mais si vous générez votre interface FCGI ou uWSGI via manage.py, ajoutez simplement ce qui suit tout en haut de votre manage.py (avant le reste):

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)

Vous pouvez l'adapter à votre configuration, au cas où vous pourriez également effectuer les opérations suivantes dans le shell:

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

Vous devrez également ajouter le répertoire contenant votre fichier settings.py au PYTHONPATH, donc Django pourra le découvrir. Procédez de la même manière pour le faire.

9
AaronO

Dans la plupart des cas, je conviens qu'il est préférable d'avoir un virtualenv même s'il ne semble pas que vous en ayez besoin lors de la première configuration du serveur. Cela dit, si vous utilisez une sorte de service cloud et que vous faites tourner des serveurs pour une tâche spécifique pendant une courte période, je ne vois pas l'intérêt d'utiliser un virtualenv.

3
Max Peterson

Je pense que c'est une bonne indication que c'est une solution de production entièrement prise en charge lorsque uwsgi le prend directement en charge avec le drapeau vhost: http://projects.unbit.it/uwsgi/wiki/VirtualHosting

2
jdi

L'utilisation de conteneurs Docker à la fois pour le développement et le déploiement en production est maintenant très populaire, donc si vous envisagez de suivre cette tendance, vous n'aurez plus besoin de virtualenv.

0
Dmitrii Mikhailov