On a Django project, I have been using Chef for configuration management. I am totally happy with Chef. It gets the job done. The community cookbooks are great.
But there’s a new (relatively) kid in the block, by the name of Ansible, and I wanted to try it out for three main reasons:
1) It’s way simpler than existing solutions like Chef and Puppet. From reading the docs, and seeing its yaml based playbooks, it does seem simple to write. My experience with it, enough to write this blog post, does show that it simple, flexible and well thought out.
2) It is written in Python and can be
pip installed. That means no more dependency on Ruby when you are working on a Python project. Also, it provides some Python / Django stack specific modules like the
supervisorctl modules already.
3) It doesn’t need any client software on the machines we intend to bootstrap. All that it would require is Python 2.4 or later ( not Python 3). It gets its job done through ssh. That is great news! Since many distributions have, and need, a relatively recent version of Python 2.X, this means that you don’t need to install ANYTHING on the box being configured to use Ansible.
I decided to install it through
pip on Mac OS X. Other installation methods include using the package manager of your OS, or running from source.
1 2 3 4
I use pythonbrew for managing my pythons and my virtualenvs, as mentioned in one of my previous blog posts - Why use virtualenv when there is pythonbrew
Of course, the next step is to get your Vagrant box up, and test your Ansible provisioning on it. The amazing authors of Vagrant have also provided a provisioner for Ansible, so using Ansible with Vagrant is simpler than it already is.
vagrant init and configure it to provision with
Vagrantfile may look something like below:
1 2 3 4 5 6 7 8 9 10 11
If you have done Chef/Puppet provisioning with Vagrant before, this should be familiar. All that the above does is to enable ansible provisioning and specifies the main playbook -
site.yml. While Vagrant can automatically handle your inventory, I like to explicitly specify the hosts. For now, the
hosts file would look like:
1 2 3 4 5
dbservers are host groups.
I decided to follow the directory layout and structure as prescribed in the Ansible best practises
I have setup a top level playbook
site.yml, as mentioned in the VagrantFile, which just includes playbooks for different server roles. It looks something like:
1 2 3 4
dbservers.yml look similar to what’s described in the best practises link above.
Common tasks like updating the apt cache, installing
build-essentials and installing packages like git can be placed in the
common role’s tasks. The playbook for this would look something like:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
We are now ready to provision:
Change ansbile verbosity by setting the
ansible.verbose property appropriately in your VagrantFile.
That’s all for this blog post. I will add more posts as I continue to configure the entire stack with Ansible. I am loving Ansible already. It takes the best of Puppet / Chef and comes with a very simplified way of doing configuration management. As I proceed, there will be some roadblocks, but I am looking forward to them as well.
I have setup a repo on Github - django-ansible.