Throughout this book, we’ve mentioned a number of goals that drive the development of Django. Ease of use, friendliness to new programmers, abstraction of repetitive tasks — these all drive Django’s developers. However, since Django’s inception, there’s always been another important goal: Django should be easy to deploy, and it should make serving large amounts of traffic possible with limited resources.
The motivations for this goal are apparent when you look at Django’s background: a small, family-owned newspaper in Kansas can hardly afford top-of-the-line server hardware, so Django’s original developers were concerned with squeezing the best possible performance out of limited resources. Indeed, for years Django’s developers acted as their own system administrators — there simply wasn’t enough hardware to need dedicated sysadmins — even as their sites handled tens of millions of hits a day.
As Django became an open source project, this focus on performance and ease of deployment became important for a different reason: hobbyist developers have the same requirements. Individuals who want to use Django are pleased to learn they can host a small- to medium-traffic site for as little as $10 a month.
But being able to scale down is only half the battle. Django also needs to be capable of scaling up to meet the needs of large companies and corporations. Here, Django adopts a philosophy common among LAMP-like Web stacks often called shared nothing.
What’s LAMP? -The acronym LAMP was originally coined to describe a popular set of open source software used to drive many Web sites:
- Linux (operating system)
- Apache (Web server)
- MySQL (database)
- PHP (programming language)
Over time, though, the acronym has come to refer more to the philosophy of these types of open source software stacks than to any one particular stack. So while Django uses Python and is database-agnostic, the philosophies proven by the LAMP stack permeate Django’s deployment mentality. There have been a few (mostly humorous) attempts at coining a similar acronym to describe Django’s technology stack. The authors of this book are fond of LAPD (Linux, Apache, PostgreSQL, and Django) or PAID (PostgreSQL, Apache, Internet, and Django). Use Django and get PAID!
To deploy your Django application, you’ll need to hook it into an industrial-strength Web server such as Apache.
Deployment checklist
The Internet is a hostile environment. Before deploying your Django project, you should take some time to review your settings, with security, performance, and operations in mind.
Django includes many security features. Some are built-in and always enabled. Others are optional because they aren’t always appropriate, or because they’re inconvenient for development. For example, forcing HTTPS may not be suitable for all websites, and it’s impractical for local development.
Performance optimizations are another category of trade-offs with convenience. For instance, caching is useful in production, less so for local development. Error reporting needs are also widely different. The following checklist includes settings that:
- must be set properly for Django to provide the expected level of security,
- are expected to be different in each environment,
- enable optional security features,
- enable performance optimizations; and
- provide error reporting.
Many of these settings are sensitive and should be treated as confidential. If you’re releasing the source code for your project, a common practice is to publish suitable settings for development, and to use a private settings module for production. Some of the checks described below can be automated using the
–deploy option of the check command. Be sure to run it against your production settings file as described in the option’s documentation.
