Lessons Learned From The Dash: Easy Django Deployment

Aug 16

Lessons Learned From The Dash: Easy Django Deployment

This is going to be a series of posts that talk about what I learned from the Django Dash. I think it's a really fun competetion that is also a great learning experience. I hope that this series catch on, and other people write about some of the things that they learned in the Django Dash.

What I learned

The thing that I learned about during my dash project was the awesomeness that is Gunicorn. It is an awesome HTTP server that I think has really solved the "how do I deploy Django" problem.

Here are the steps involved in deploying a site using the gunicorn:

pip install gunicorn
Add 'gunicorn' to your installed apps
./manage.py run_gunicorn -b 127.0.0.1:1337 --daemon

It really is that simple. Gunicorn is the fastest way to having a production ready web server serving your site that I've found in the Django realm. However, Gunicorn by itself isn't production ready. It is recommended to deploy something in front of it. We used Nginx, which is another super simple web server.

Here is basically the simplest possible configuration of nginx that will work for your gunicorn backend server.

server {
        listen 80;
        server_name  example.com;
        access_log  /var/log/nginx/example.log;

        location / {
                proxy_pass   http://127.0.0.1:1337;
        }
}

After you restart Nginx, you should be able to hit your server at port 80 and have it be serving your Django web app. This allowed us to get our application into production during the dash in about 10 minutes, which was a great time saver.

I'd be curious if people have had any trouble with Gunicorn in deployment, because as far as I've seen its production ready. As a "first Django deployment" set up I think it's hard to beat. I've also noticed that is uses significantly less RAM than an Apache/mod_wsgi set up (I know this can be configured away, but by default it's much better). This is great for the memory constrained deployment platforms a lot of us are running on.

Comments

1 Tero says...

I have used Gunicorn from May on my blog and haven't had any issues with it. I don't know how it behave under heavy load, but for small blog on small VPS it works really well. As you said it is really memory efficient.

Posted at 3:39 a.m. on August 17, 2010

2 pablo says...

What about init script for unbuntu and redhat? Without it it's useless

Posted at 8:30 a.m. on August 17, 2010

3 Bruno says...

Indeed, Gunicorn is absolutely awesome... I have a VPS with 256MB of ram that runs about a dozen of Django sites with Gunicorn...

Pablo: I don't know about init scripts but the docs mention runit or supervisord for production. I'm using supervisord and it just works (although gunicorn has never crashed AFAIK).

Posted at 8:43 a.m. on August 17, 2010

4 Thomas says...

Hmmm ... maybe Im just stupid, but I dont understand what is nginx serving and what is gunicorn servering using the configuration above?

Posted at 9:13 a.m. on August 17, 2010

5 Jamie Curle says...

gunicorn is serving the django project but doing so on localhost, which isn't accessible to the world.

Nginx is proxying external requests to gunicorn.

Posted at 10:47 a.m. on August 17, 2010

6 Aaron says...

What are the advantages of using gunicorn over fastcgi?

Posted at 2:34 p.m. on August 17, 2010

7 Paul J. Davis says...

Thanks for the writeup. I'd be curious to hear what sorts of issues people are having in production. The only issue I've seen people have is when they find out that they're actually doing things that require async workers. The issue usually manifests in workers timing out repeatedly. The solution is as easy as installing Gevent or Eventlet and using one of the async worker types.

@pablo - We recommend using supervisord or runit to monitor applications in case something breaks. There is an Ubuntu package that's being maintained but AFAICT it doesn't include anything for upstart/init.d

@Thomas, @Jamie - The reason to use Nginx is so Gunicorn doesn't have to worry about slow clients by default. There's more background at [1] describing the reasons.

@Aaron - Most of the time I hear that someone enjoys Gunicorn its because of the simplicity in deployment.

[1] http://gunicorn.org/design.html

Posted at 3:35 p.m. on August 17, 2010

8 Stef says...

Nice writeup. Thanks. I took part this year - wasn't able to finish though. Nevertheless I am going to post a blog on "What I have learned during the dash", too!

Gunicorn + Nginx sounds like a big time saver.

Posted at 1:07 p.m. on August 18, 2010

9 Mauricio Quiros says...

Hi Eric, thanks for sharing this information, quick question, Would you prefer gunicorn instead of the recommended (FastCGI) configuration in the Django Advent? any advice?

http://djangoadvent.com/1.2/deploying-django-site-using-f...

Posted at 3:02 a.m. on August 20, 2010

10 django says...

I am confused about Linux. Your deployment seems fine, but god I wish there was a Linux 3 day workshop to learn about Linux. BTW, what do you think about UWSGI, instead of GUnicorn?

Posted at 6:26 p.m. on September 10, 2010

11 Treatmentc says...

pcqfitdartnngovk; nail fungus treatment, FKCTzBT?

Posted at 8:31 p.m. on October 12, 2010

Surfing in Kansas