Over the last year there's a been a whole new crop of specialized hosting platforms for Django applications. In this panel, we speak to a number of the people behind these new platforms to discuss what benefits they offer, what challenges they face, and what the Django project/community can do to encourage their growth.
This is a moderated discussion among a variety of new, specialized, Django hosting providers. Each participant will be given an opportunity to provide a brief overview of their offering and what benefits it provides over other solutions. After these introductions, the focus of the panel will be to discuss the common issues being faced by these new platforms, what they are doing to address the issues raised, and what the Django community can do to improve the available hosting options.
Chef, a popular configuration management tool, is gaining momentum in the Django community. Learn how to deploy Django sites using Chef, be they one server or a thousand.
Chef, a configuration management tool, is increasingly popular in the Django community. Many people have yet to take the plunge, and are still managing production systems exclusively through tools like Fabric or Buildout. In this talk I will quickly show the basics of building Chef recipes, both in general and a tour of the Django-and-Python-specific tools available. I will then walk through a suite of cookbooks built to deploy Packaginator as a production site in the cloud. If suitable wireless is available, I would like to do a live demonstration at the end, bringing up a new site from scratch.
- Chef basics
- Community site/cookbooks
- pip provider
- virtualenv provider
Django application recipe
Other misc cookbooks
- Application recipe
- Postgres master/slave
Demo (pending wireless)
This talk will go through the deployment system that we have built at Urban Airship. It will cover the process that allows us to automate our deployments, making it safe to deploy at any time. It's built on Fabric, Gunicorn, Virtualenv, Rsync, Supervisord, and Python. We end up with fully isolated environments for our services that are easy to manage.
This talk will cover how we do deployments. It is the first deployment system that I've been happy with, which says a lot. It is a system that we have been evolving over the last 6 months or so, and has made our developers lives a lot easier. There are a few different points that make it successful, as well as useful.
Interestingly, there is very little Django specific about this setup. It is how we deploy Django applications, but we also deploy flask and standard WSGI applications using the same framework. A slightly modified version of the code is also used to deploy our Java applications, so the tooling is genericly useful for more than just Django programmers
The talk will have 4 parts, that will cover the following:
- The process around Version Control that we use
- The tooling to deploy code
- The environment that the code gets deployed in to
- The process of deploying the code across all of our servers, a subset at a time
The first part is that we manage our source code in a specific fashion. It's a pretty standard git branching model, where we have a master branch that is the latest stable code. All on-going work is done on feature branches. Then we have a production branch that is what is currently in production. Each push to production is tagged with the date. Git allows us to keep a record of the history of development in one place.
Next, to actually handle the deployment of the code to the servers, we're using Fabric. To show the full power of the system, we might normally run a command like fab host:web-0 deploy:airship restart:airship monitor:airship. This is mostly abstracted out from people in the day to day use of the system. The deployment system has the following features:
The python environment that things are deployed into is a fully standardized setup using supervisord and gunicorn, along with a number of other helper utilities. It integrates into the init.d system on the host, so that normal management commands work. Each service that we deploy has it's own environment, which I'll go into more depth on.
Finally, We are also working on a system that will allow us to automatically health check deployments and automatically rollback the deployment if we are seeing elevated error rates. We handle deploying the code to a "canary" system first, then roll it out to half our servers, then the other half. This system is implemented currently at the prototype level, but should be in production use before the talk is given.
A tour through the systems that power ep.io, the Python hosting platform, from the array of daemons powering the system, to how redundancy is set up, and also covering general best practices for hosting Django sites yourself.
At ep.io, we spend all day finely tweaking and polishing our deployment systems, and this talk will go through some of the parts of our archtecture, show you some of our code, and also advise you on deploying Django sites on your own servers.
Topics covered include our use of ZeroMQ for redundant communication, the difficulties of running services with transatlantic latency, our extensive use of Eventlet for asynchronous, concurrent I/O, how we've used (and modified) pip and virtualenv, and how we've leveraged class-based views to make our API part of our normal URL structure.
In addition, there will also be some advice on how to run sites on your own servers, including what programs to use, how to lay things out, and sensible backup strategies.
5th–8th September 2011