Virtualenv is a good tool for Python development and deployment, and can isolate multiple versions of Python and third-party libraries, where the author summarizes how several common Python services combine with virtual deployment source links
One of my favorite things in Python is the ability to use VIRTUALENV to create an isolated environment. It is very simple to deploy different Python class libraries in different projects.
One tricky issue is that deploying several different services using virtualenv in a production environment has some configuration differences. So I've collected several different configurations of various services from my project. Can be sure that they are different, but in my this can be normal work, I hope can be more people use. If you encounter any problems, or where I have not written clearly enough, please tell me that I will update this article in a timely manner.
- Nginx and Gunicorn under Supervisor.
nginx-this configuration and normal configuration basically no difference, out you want to specify some special static path in your VIRTUALEVN. (Because the location of the third-party library installation has changed)
Static files to point to the Virtualenv directory
location /static/admin { 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/activateExportdjango_settings_module=$DJANGO _settings_moduleExportPythonpath=$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-B0.0.0.0:8000 2>>$LOGFILE
- supevisor -The Gunicorn configuration file is directed 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
- celery under the supervisor.
In this case we configure Supervisor to start the celery under the virtualenv path. A cool feature is the ability to specify environment variables-here is the Django settings module
[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 make sure that all remote commands work in an activated virtualenv environment.
from__future__ImportWith_statement fromFabric.apiImport* fromContextlibImportContextManager as_contextmanagerenv.activate =' Source/home/ubuntu/myapp/venv/bin/activate 'Env.directory ='/home/ubuntu/myapp '@_contextmanager def virtualenv(): withCD (env.directory): withPrefix (env.activate):yield@hosts (env.roledefs[' db ') def rebuild_index(): withVirtualenv (): Run ("python manage.py rebuild_index")
Statement:
This article is from the "Orangleliu Notebook" blog, reproduced please be sure to keep this source http://blog.csdn.net/orangleliu/article/details/45066157
Author Orangleliu using Attribution-NonCommercial-sharing protocol in the same way
[virtualenv] using virtualenv in a production environment