This is the third part in a series about Django in Production. If you haven’t already, read part 1 and part 2 first.

In the first two posts of this series, I described the core stack which powers a Django application in production, and the Celery task queue which can be used to execute code asynchronously. In this third post, I’ll describe how a production Django application can be monitored, and how common tasks such as deployment can be automated.

This is the second part in a series about Django in Production. If you haven’t already, read part 1 here.

In my last post, I described in detail the core stack which powers a Django application in production. In this second part, I’ll talk about something which has become commonplace in modern web applications - background tasks.

Often websites perform complex tasks which take a long time to finish. These tasks don’t always need to be done before the response is sent to the browser, so can be executed elsewhere. In cases like this, tasks can be performed asynchronously, by one or more “workers” which consume a task queue.

Everyone has their preferred way of doing things, and this is more and more true when there are many options available. In the Django world, this translates to everyone having their favourite web server, database, proxy, and so on.

In spite of this, I’m going to spend some time over the next few posts describing how I deploy Django applications in production from a high-level perspective. In the first part of this series, I’ll talk about the core stack which serves as the basis of the application.

I’ve been working on a little Django app for a while now, which solves a problem I often come across in Django projects. django-radius allows a developer to use a 3rd party RADIUS server to provide authentication in their Django application. Not only this, though, it also allows the use of multiple RADIUS servers, which can be specified in whichever way makes sense.

This might sound a little contrived, so I’ll give an example. Imagine a web service, such as a helpdesk management system, whose users are organised into groups. Each user belongs to an organisation, which buys into the service on their behalf. Basecamp and Zendesk operate this model, to name just two. To login, a user must visit a particular URL - so that the system may determine which organisation that user belongs to (http://yourcompany.zendesk.com for example).

Now imagine that this service wishes to provide external authentication to its customer’s systems, using RADIUS. This means that there’s no need for users to have yet another password on yet another system, and is generally a Good Thing™.

In this scenario, the developers would have to find some way of validating the user’s credentials using the correct RADIUS server, based on the URL they used to access the site with. For this type of problem, django-radius is the perfect solution.

This is my first real attempt at doing things properly in a Django app, and quite some effort has gone into documenting both the usage and the code. I’ll leave it to those that are interested enough to read the README and find out how it works.

Hopefully this app will save a little time in someone else’s project, and I’d love to hear from anyone with comments or suggestions on how it can be improved.

Well, here we are. Three years at The University of Nottingham, and what do I have to show for it? Well, this is what:

That’s right! I have a recommendation for a first in Computer Science. It turns out both my supervisor and second marker were fond of my dissertation - Backtrac Backup System - and would like to see it used in a commercial setting. I also had my work sponsored by Servat Ltd., which went down very well with the powers that be.

I’ve enjoyed my time at university, but I’m ready to move on now. Or at least, I’d better be, after turning down a couple of very good offers for PhD studentships.

So what’s next?

Why, I’m glad you asked! I’m currently working on a (secret) project with Marcus Whybrow, which will hopefully shape up to be something quite special. It is, of course, a Django project, and it’s teaching us both about the finer details of developing and deploying a production system. There’s a few posts in the pipeline about the things we’ve discovered this far, and we’ve hardly got going yet!

This time around, we’ve decided to go with a brand new web server all the cool kids are using: gunicorn. It’s sitting behind an nginx reverse proxy, which also serves up the static media. Also, Fabric is shaping up to be a super time-saving tool, well worth writing about at some point in the near future.

So, well done to all those who have completed their degrees this year. I look forward to working with you in what people can’t seem to stop calling the “real world”.

My last few posts have generally been about my final year project - Backtrac Backup System. One of the recent challenges I faced was getting the Django-based web interface to run under the Twisted WSGI server. In this post, I’ll describe a major issue with this process, and how I worked around it.

For my third year project, I have hooked Twisted’s Perspective Broker authentication into Django, so that a networked application can authenticate itself against Django’s central user database (django.contrib.auth). The process is pretty quick and easy, thanks to Twisted’s pluggable nature, and Django’s pure simplicity.

I’ve been battling with this issue for a couple of months now, ever since I upgraded to Ubuntu 10.04 on my main desktop machine. Google Chrome would constantly max out one core, with no indication of what it was doing, or why.

Today, I finally solved the issue. It turns out that something to do with the m4 package was causing the error, with the following output:

MozPlugger: Error: Failed to execute m4.
Mozplugger: M4 parsing of config generated error

So, I checked out the package in question, and found that it wasn’t installed. To my great relief (and some frustration), a simple sudo apt-get install m4 fixed the problem instantly.

I only hope that this post solves this extremely annoying issue for someone else.

Thinking a lot about my 3rd year project, I’ve been considering how to implement a backup system based around a Django server. So far, I have reached the conclusion that the system will consist of three main parts:

• The Django server (yet to be named)
• The client daemon (backtracd)
• The backup library itself (backuplib)

After contacting the university regarding my 3rd year project/dissertation, my ideal choice has been confirmed. I’ll be making a distributed backup system, based around a Django web interface and AMQP.