[Virtualenv] Use virtualenv in the production environment and virtualenv in the environment

[Virtualenv] Use virtualenv in the production environment and virtualenv in the environment

Virtualenv is a good tool for python development and deployment. It can isolate versions of multiple python versions and third-party libraries. Here, the author summarizes how to deploy the original article link in conjunction with virtual

One of my favorite things in Python is the use of virtualenv to create an isolated environment. You can easily deploy different python class libraries in different projects.

One of the most difficult problems is to use virtualenv in the production environment to deploy several different services with different configurations. So I collected several different configuration methods for different services from my project. They are certainly different, but they can work normally in my case. I hope they can be used by more people. If you encounter any problems or where I am not clear enough, please let me know and I will update this article in time.

• NginxAnd Gunicorn under Supervisor.
  Nginx-this configuration is basically the same as the normal configuration. You have to specify some special static paths in your virtualevn. (Because the third-party library installation location has changed)

The static file must point to the virtualenv directory.

location /static/admin {  autoindex on;  root   /home/ubuntu/app/venv/lib/python2.7/site-packages/django/contrib/admin/;}

• Gunicorn-I used a shell script to configure Gunicorn PATH variables and options.

#!/bin/bashset -eDJANGODIR=/home/ubuntu/appDJANGO_SETTINGS_MODULE=app.settings.prodLOGFILE=/var/log/gunicorn/guni-app.logLOGDIR=$(dirname $LOGFILE)NUM_WORKERS=2# user/group to run asUSER=ubuntuGROUP=ubuntucd /home/ubuntu/appsource /home/ubuntu/app/venv/bin/activateexport DJANGO_SETTINGS_MODULE=$DJANGO_SETTINGS_MODULEexport PYTHONPATH=$DJANGODIR:$PYTHONPATHtest -d $LOGDIR || mkdir -p $LOGDIRexec /home/ubuntu/app/venv/bin/gunicorn_django -w $NUM_WORKERS \  --user=$USER --group=$GROUP --log-level=debug \  --log-file=$LOGFILE -b 0.0.0.0:8000 2>>$LOGFILE

• Supevisor-Direct the Gunicorn configuration file to the shell script.

[program:gunicorn-myapp]directory = /home/ubuntu/myappuser = ubuntucommand = /home/ubuntu/myapp/scripts/start.shstdout_logfile = /var/log/gunicorn/myapp-std.logstderr_logfile = /var/log/gunicorn/myapp-err.log

• CeleryUnder the Supervisor
  In this case, we configure the Supervisor to start celery in the virtualenv path. A cool feature is that environment variables can be specified-here the settings module of Django is used

[program:celery]; Set full path to celery program if using virtualenvcommand=/home/ubuntu/myapp/venv/bin/celery worker -A myapp --loglevel=INFOdirectory=/home/ubuntu/myappuser=nobodynumprocs=1stdout_logfile=/var/log/celery/worker.logstderr_logfile=/var/log/celery/worker.logautostart=trueautorestart=truestartsecs=10environment =  DJANGO_SETTINGS_MODULE=myapp.settings.prod

• Fabric.
  The idea is to ensure that all remote commands work in the activated virtualenv environment.

from __future__ import with_statementfrom fabric.api import *from contextlib import contextmanager as _contextmanagerenv.activate = 'source /home/ubuntu/myapp/venv/bin/activate'env.directory = '/home/ubuntu/myapp'@_contextmanagerdef virtualenv():    with cd(env.directory):        with prefix(env.activate):            yield@hosts(env.roledefs['db'])def rebuild_index():    with virtualenv():        run("python manage.py rebuild_index")

Statement:
This article from the "orangleliu notebook" blog, reprint please be sure to keep this source http://blog.csdn.net/orangleliu/article/details/45066157
Author orangleliu adopts signature-non-commercial use-share protocol in the same way