Live data from Hacker News

Ask HN: Django Deploy Recommendations

news.ycombinator.com

1–10 of 39 posts

Ask HN: Django Deploy Recommendations

#1
I have an app that uses Django Python and Postgresql.

Right now is running under Linux/Apache/mod_wsgi, how ever have read about Nginx and Gunicorn (also uwsgi and others) as a better option...

I would like to read your recommendations (advantages and disadvantages) about deploying django.

PS: I am mainly developer so I lack a lot of knowledge about sysadmin.

Re: Ask HN: Django Deploy Recommendations

#2
Here's what I've found that helps tremendously:

-Keep your software in a DVCS of some sort. I find Git and Mercurial to be great.

-Use virtualenv to abstract away from your current environment's Python distribution. Start clean and download the packages you need.

-Create a requirements file listing the packages that you need for you program. Put it in the same format that the 'pip freeze' command outputs, so that installing a new environment is quick and easy.

-Set up a local configuration file (not managed by version control) and a base configuration file with all the settings that are immutable. Import the local config file within settings.py so as to avoid local setting conflicts.

-In production, set up an nginx frontend to serve static files, and route all the Django urls to an Apache backend (or Tornado, or whichever App server you may want to use).

-I haven't tried anything else, but WSGI is super intuitive and easy to use.

-If you need it, try using Django-South for versioning database schemas. Do take into account that it has a bit of a learning curve.

-You don't need to put your python files in /var/www, any directory will do.

Re: Ask HN: Django Deploy Recommendations

#4
I run nginx as a static file server and reverse proxy to uwsgi (via a local socket). I find the setup to be simpler than Apache/mod_wsgi, though both approaches meet my performance needs without any trouble. I run PostgreSQL as my database. (This is on a reasonably low traffic, but fairly data heavy site. It all runs comfortable on a Linode 512)

I'll just reiterate what Daishiman said regarding DVCS (like git or mercurial), virtualenv, and South. Use them! All three will make your life much easier 6 months from now.

Re: Ask HN: Django Deploy Recommendations

#5
post #3

You really should use nginx to serve static files and route everything else to apache. The setup is dead simple.

Know of any tutorials appropriate for a Linux server noob (I'm comfortable with the Linux command line but haven't done much web deployment other than basic one-click xampp stuff)?

Re: Ask HN: Django Deploy Recommendations

#6

Here's what I've found that helps tremendously: -Keep your software in a DVCS of some sort. I find Git and Mercurial to be great. -Use virtualenv to abstract away from your current environment's Python distribution. Start clean and download the packages you need. -Create a requirements file listing the packages that you need for you program. Put it in the same format that the 'pip freeze' command outputs, so that ins…

These are some excellent points, the only things we do differently are:

- We keep a local settings file for each environment, and those /are/ versioned. We have a /settings_local directory which contains each of the variants (localdev/dev/staging/df/live). The appropriate one is sym linked to /settings_local.py, which in turn is imported into settings.py.

- We bypass Apache entirely and just plug Nginx FCGI into Django directly.

- We have a separate pip requirements file for each environment (also kept in source control)

- We use a Puppet to configure our systems. Perosonally though, I have found Puppet to have an exceptionally steep learning curve, so you may want to shop around.

I hope that helps!

Re: Ask HN: Django Deploy Recommendations

#7
nginx in front of gunicorn is fast, simple, efficient with resources, and reasonably scalable. Today, there's nothing else I would recommend.

Of course, use [d]vcs, setup.py, virtualenv, pip, and south (and a reasonable test suite!). Using these along with gunicorn as mentioned above has streamlined my deployment to a "one-click" process that leverages all of these packages to create an isolated, repeatable, rock-solid [re-]deployment with nothing more than a generic Makefile.

I've been doing Django development and deployment for over four years now and it is the closest thing to a "silver bullet" I've found.

Re: Ask HN: Django Deploy Recommendations

#8
Another great tool that hasn't been mentioned yet is Fabric. Combined with a VCS it makes pushing changes to the server an absolute breeze. With the simple fabfile shown below I only need to do "fab update" to push all of the latest code to the server:

  #!/usr/bin/env python
  from fabric.api import *

  env.hosts = ['example.com']

  def update():
	  local("./manage.py validate")
	  local("./manage.py test core")
	  with cd("/var/www/example"):
  		  sudo("git pull origin master", user="www-data")
		  sudo("./manage.py migrate --all", user="www-data")
  		  sudo("touch apache/django.wsgi", user="www-data")

Re: Ask HN: Django Deploy Recommendations

#9

Here's what I've found that helps tremendously: -Keep your software in a DVCS of some sort. I find Git and Mercurial to be great. -Use virtualenv to abstract away from your current environment's Python distribution. Start clean and download the packages you need. -Create a requirements file listing the packages that you need for you program. Put it in the same format that the 'pip freeze' command outputs, so that ins…

These are some excellent points, the only things we do differently are: - We keep a local settings file for each environment, and those /are/ versioned. We have a /settings_local directory which contains each of the variants (localdev/dev/staging/df/live). The appropriate one is sym linked to /settings_local.py, which in turn is imported into settings.py. - We bypass Apache entirely and just plug Nginx FCGI into Djan…

I use fabric for deployment, testing, log maintenance, database backups. For almost everything on remote machines.

Learning curve is rather not steep.

Post reply on HN