本文提供了一个使用Nginx作为反向代理和Gunicorn作为Django服务的部署教程，介绍了如何在Linux(Ubuntu)系统上配置Django项目。
http://goodcode.io/blog/django-nginx-gunicorn/
This is a howto on setting up Django on a Linux (Ubuntu) system using Nginx as a reverse proxy and Gunicorn as a Django service.
The conventional way to run Django in production these days is using Apache2 and mod_wsgi. While there’s nothing wrong with that approach, I prefer Nginx. I also like to be able to control Django server separately from the web server.
There are several production-ready servers for Django. The best seem to be Gunicorn and uWSGI, and Gunicorn seems the best supported and most active project.
When running Django server separately from the web server, we need a way to start, stop and restart the Django server. A popular way for doing it in Django world is Supervisor, altough, for Ubuntu users, Upstart might be less hassle.
You probably already have a Django project you want to deploy, but for completenes’ sake, the steps here will use an empty toy “Hello World” Django project:
Preparation
First things first – you are using virtualenv, right? If not, you should.
virtualenv --no-site-packages test cd test source bin/activate pip install gunicorn django django-admin.py startproject hello cd hello # to test the base setup works python manage.py runserver 0.0.0.0:8000
Gunicorn
Testing Django with Gunicorn is as simple as:
gunicorn_django -b 0.0.0.0:8000
For production, we might want a bit more options, and we want to make sure the server is executing in the correct environment. The easiest way is to create a shell script to set it all up:
#!/bin/bash
set -e
LOGFILE=/var/log/gunicorn/hello.log
LOGDIR=$(dirname $LOGFILE)
NUM_WORKERS=3
# user/group to run as
USER=your_unix_user
GROUP=your_unix_group
cd /path/to/test/hello
source ../bin/activate
test -d $LOGDIR || mkdir -p $LOGDIR
exec ../bin/gunicorn_django -w $NUM_WORKERS
--user=$USER --group=$GROUP --log-level=debug
--log-file=$LOGFILE 2>>$LOGFILE
The number of workers is number of worker processes that will serve requests. You can set it as low as 1 if you’re on a small VPS. A popular formula is 1 + 2 * number_of_cpus on the machine (the logic being, half of the processess will be waiting for I/O, such as database). YMMV.
Don’t forget to mark the script as executable (chmod ug+x script.sh). You can run it from the command line for testing. Note that Gunicorn by default uses 127.0.0.1:8000 address (the same as Django debug server), which is fine if Nginx is on the same machine – you usually don’t want to have it wide open to anyone, and instead let Nginx handle incoming connections.
If you want to run several Django servers on the same machine, just make sure each uses a different port number.
Supervisor
Supervisor has extensive documentation, and this blog post is big already, so I’ll just point you to the official docs. The config file for running our server (/etc/supervisor/conf.d/hello.conf on Debian/Ubuntu) should look like this:
[program:hello] directory = /path/to/test/hello/ user = your_unix_user command = /path/to/test/hello/script.sh stdout_logfile = /path/to/logfile.log stderr_logfile = /path/to/logfile.log
Test it with supervisorctl {start,status,stop} hello (as root).
Upstart
Ubuntu alternative is Upstart, which has a similar config file (/etc/init/hello.conf). An example:
description "Test Django instance" start on runlevel [2345] stop on runlevel [06] respawn respawn limit 10 5 exec /path/to/test/hello/script.sh
Test it with service hello {start,status,stop} (as root).
Update 2011-11-14:For completeness of the Upstart setup configuration one has to add a soft link in /etc/init.d for a file named hello to /lib/init/upstart-job. So the following instruction should be executed after the .conf file has been created in /etc/init:
sudo ln -s /lib/init/upstart-job /etc/init.d/hello
Update 2011-11-14: Christophe Meessen found and fixed several errors in the procedures and config files, and also provided info about the extra Upstart configuration I missed. Thanks Christophe!
Nginx
If you don’t have it set up, you should also install Nginx. The install procedure varies from system to system. On Debian and Ubuntu systems, it’s as simple as apt-get install nginx, and other Linux distributions usually have equivalent commands.
Nginx is mostly a drop-in replacement for Apache for serving static files, though there are some things to set up if you need to run PHP code as well.
For our setup, we need Nginx to serve as the reverse proxy for the upstream server(s). To do so, we add a server section to the config file:
server {
listen 80;
server_name example.com;
# no security problem here, since / is alway passed to upstream
root /path/to/test/hello;
# serve directly - analogous for static/staticfiles
location /media/ {
# if asset versioning is used
if ($query_string) {
expires max;
}
}
location /admin/media/ {
# this changes depending on your python version
root /path/to/test/lib/python2.6/site-packages/django/contrib;
}
location / {
proxy_pass_header Server;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_connect_timeout 10;
proxy_read_timeout 10;
proxy_pass http://localhost:8000/;
}
# what to serve if upstream is not available or crashes
error_page 500 502 503 504 /media/50x.html;
}
Ubuntu and Debian systems keep Nginx config files in same layout as for Apache, so the above cold be added to /etc/nginx/sites-available/hello (and enabled by symlinking from sites-enabled directory). Use nginx -t for config test and nginx -s reload to reload the configuration.
That’s it
And that’s it. The services are really quite simple to set up once you know what goes where, the setup is flexible and performant, and the server environments are isolated so it’s possible to host many different services with varying requirements on the same machine.
Have improvements on the above or your own helpful tips, or found an error in the post? Share in the comments.
23 comments
扫一扫
6127
到【灌水乐园】发言
lamby
June 18, 2011 at 2:46 pm
gunicorn in Debian has a /etc/gunicorn.d feature (like sites-enabled) so you don’t need to mess about making your own scripts.
Senko
June 18, 2011 at 6:31 pm
That’s neat, thanks. Althought, that means you have to have gunicorn installed systemwide, whereas, in my example, I installed it in virtualenv. Not that installing it systemwide would neccessarily be a problem for most people, I just like having most of the stuff neatly tucked in virtualenv.
Mahdi Yusuf
June 18, 2011 at 2:51 pm
I have been meaning to learn this. Thanks.
Max Jaderberg
June 18, 2011 at 3:32 pm
Brilliant stuff…was really looking for a clear guide for setting up django
Jonas B.
June 18, 2011 at 4:26 pm
Why not run Django directly on uwsgi for nginx? I find it to be the far most common and well supported configuration. Performance is at least as good and there’s one less component to troubleshoot.
Senko
June 18, 2011 at 6:34 pm
I don’t have good arguments for whether gunicorn is better than the uwsgi combination. When I was looking for alternatives to mod_wsgi, I found both, but gunicorn did come up more often and I got the impression that more people are using it.
Tim
June 18, 2011 at 4:37 pm
you could do similar setup with Cherrypy + ngingx. In fact ngingx+apache2/wsgi would also give a decent performance boost to your python/django deployments (or any other non-python apache “mods”.
Viktor Petersson
June 18, 2011 at 4:51 pm
We’ve been running a very similar solution for some time on FreeBSD, and it works lika charm. If you’re running it across multiple servers, you probably want to move Nginx off of each node, and run it on a central load balancer and then have separate static servers (Nginx works great for this too).
If you want to scale it further, you can add Varnish to the equation to get some powerfull caching.
Dana Woodman
June 18, 2011 at 7:01 pm
First off, great overview. That’s basically the setup I use for most of my Django projects.
If you haven’t had the pleasure of using Fabric yet, you should definitely check it out. It’s an excellent way to manage/deploy you Django projects, including starting/restarting Gunicorn, updating you project code and doing database management; all remotely via ssh. It’s a great tool in the Django web development toolkit.
http://docs.fabfile.org/en/1.0.1/index.html
Simon Pantzare
June 18, 2011 at 11:26 pm
During development, it may be preferable to run supervisord inside the virtualenv as well. Here is a small project of mine intended to make this easy: https://github.com/pilt/pewatch
Elf M. Sternberg
June 19, 2011 at 5:22 am
Thanks for this. I’ve been shy about using Gunicorn, mostly because I’ve been using an Nginx + Apache/WSGI + Varnish trio for my django & media issues. I may look into it again for my next project. (Then again, my next project may be couchdb as my front-end server, and node.js as a back-end, so…)
Rich
June 19, 2011 at 7:42 am
Can you say a bit more about the benefits gained from using this setup over Apache? Numbers would be great, too..
Senko
June 20, 2011 at 1:34 am
I didn’t want to get into whys, as the choice of the server really depends on the specific use case, so YMMV. I prefer Nginx because it’s really good at what it does (serving static assets, proxying/load balancing slower upstreams for dynamic stuff).
I also host a bunch of apps written on various platforms (Django, Flask, Tornado, Node.js, PHP) on the same system, so I need to use some sort of a reverse proxy anyways. In such a setup, there’s no need to involve Apache too, if it’s just used for passing control on to the (Django, or PHP, …) app.
Server benchmarks are hard to do right, but here’s a relatively recent one: http://nichol.as/benchmark-of-python-web-servers