Salt/Django deployment

January 24, 2016

I really like Salt. I think it’s a very civil way of specifying what you want from your machines. A few days back I started working on a side project written in Django. At the end I wanted to deploy it to a server but didn’t want to go through the tedious route of logging in and setting everything up manually. So I decided to write down how this might be done using Salt. By the time I had everything working, I noticed that it looked fairly generic and I could easily abstract it out into a template such that it could be reused in future.

The source is all on Github - salt-django-cookiecutter.

It’s mainly written for applications using Django and deployed using virtualenv. The application is “owned” by a user with the same name as the application. Assuming we’re calling our application “app42”, the states include calling user.present with the name app42. This also requires having the public/private keys inside pillars. The application itself lives inside /home/app42/app, with the virtualenv in /home/app42/app-env. It connects to a PostgreSQL database called app42, connecting as user app42.

Application code is kept up to date using git.latest, which is watched by commands including python migrate and python collectstatic, such that on every pull that changes something, the migrations are run automatically and the static resources are re-generated.

Regarding deployment, I chose to go with the nginx/gunicorn/systemd route. Meaning that nginx relays user requests to a gnuicorn process which manages our application process workers. Systemd runs gunicorn as a service. I found a nice example on the gunicorn documentation for writing a corresponding unit file.

Most of the config files are included within the template. Overall, I’m happy with the result. The source code is all on Github, and I’m open to receiving feedback and/or pull requests if something is wrong or doesn’t work as intended.