Do you dread the moment when your shiny new application is “ready for production”; except it isn’t because deploying is hard? How about moving existing apps or deploying one app to many servers? I’ll take you on a trip of dos and don’ts of deploying Python apps on UNIXy systems. Afterwards, you will be able to find the best way to deploy your code without repeating the mistakes of many before you.
There is an abundance of material about developing (web) applications. But when it comes to the actual deployment, I find the information rather scarce. Everybody figures it out for themselves. Somehow. Then there are still people running mission critical apps in “screen” sessions and there’s still lots of people fighting the seven hells of dependency conflicts. Every day, dozens of people pop up on various IRC channels and mailing lists, having problems to deploy their applications.
I would like to change that and tell you how we – a German web hosting company and domain registrar – deploy our numerous Python applications on UNIX-based systems. We need our deployments to be fast, reliable and predictable. And that’s what we achieved. Due to the limited size of our tech staff, I’m a true DevOp: I develop applications but also have to make sure they deploy and that they don’t make the life of the operation guys miserable. My knowledge and experiences are fresh from the trenches as an infrastructure engineer, not just some theoretical, read-up stuff.
There will be Python code, there will be funny anecdotes and I will cater both to beginning and seasoned ops. While the most common applications that are being deployed are probably web apps, I won’t limit myself to them. I’d like to lead you through the pitfalls of various approaches – explaining why they are a bad idea – and describe ours including variations and simplifications.
This talk will not be about tuning nginx for maximum performance or making Django TrueScale. It’s about solid, repeatable and proven ways to deploy your Python applications, no matter which technology you use. At the end of my talk, you should know what not to do and where to look for things you should do.