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
Application code is kept up to date using
git.latest, which is
python manage.py migrate and
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.