Ansible / DevOps

The Ansible cookbook cookbook

Instead of going through endless long guides, here is a short, yet effective to the point Ansible guide:


I’m assuming Linux, cause.. cause. simple

pip3 install ansible
Code language: Bash (bash)

Will do the trick. no need to be root.

ansible --version
Code language: Bash (bash)

Will make sure you have it installed and ready.

Target machines

Target machines need not only ssh access, but they must have python installed as well.

Ansible files


This is the main configuration file. You could and should have multiple configuration files for multiple projects. It’s not a must! There is (at least) a default one, depends on the installation. However, having it in the root of every project make things more nit. In this file you’ll note general fact about running ansible, like whether to change the running user to the root user (this is called user escalation), where will ansible get its servers list and other things ansible might need to know for your project. Technically, it is possible not to use a configuration file, but it will require a lot of typing. Some value can be set as environment variables, some can be used in the command line, but unless it’s a security issue, you definitely want to have a configuration file. Anything that is not really host dependent, should go in the configuration file. One great example is ansible_python_interpreter. Without setting that variable, Ubuntu will default to using python2. This is suppose to be changed in the future, but it didn’t yet. Here is an example file:

[privileges_escalation] become=True ansible_become_method=sudo [defaults] interpreter_python=/usr/bin/python3 inventory=./inventory.txt
Code language: JavaScript (javascript)

There are a lot of saving for us when running with this file – we do not need to set the remote interpreter by hand, nor the inventory file. Some things, that are dimmed more host specific, will go on the hosts inventory file, which is coming right up.

Inventory file

Usually – inventory.txt. But, you can select any name that you want. You will need this file to state the hosts you’re contacting. This is the bug deal here – this is where ansible will go to make your changes. Here is a sample of a single host, that is using ssh keys: ansible_ssh_private_key_file=/home/tal/.vagrant.d/insecure_private_key ansible_ssh_user=vagrant
Code language: JavaScript (javascript)

This configuration is for a virtual machine I’ve created with vagrant, and includes the important facts needed to access the host: the address either an IP or a dns based, username, key (or password). The configuration file includes more general details.

Let’s Run it!

With just these two files (and a virtual vagrant machine) we can now run a tiny test:

ansible all -m ping | SUCCESS => { "changed": false, "ping": "pong" }
Code language: JavaScript (javascript)

Yes, this is not much, but it actually means a lot: we can contact our host, authenticate and run ansible scripts on it! Any other module should (and in this case will) work just as fine. So what is the -m tag? This tag means module, in this case a very simple one. And no, we do not need to use this tag when running “real script” – we have cookbooks for that.

Dynamic inventory

The first question that anyone would ask, is, can we do dynamic inventory. We can. There are certain rules, but, you can use ANY programming language, as ansible uses simple io. Don’t write off the so called static inventory! If you’re using dns, the actual machines that you’re connecting will change. However, with cloud computing, you might want to do you own inventory. For most cloud providers there is a module that will do that for you, but you might want something extra, and then yes, you need to write your own code. Me? I love writing my own code, so this is what I’ll do…

Ansible modules

There soooo many different ansible modules, there is basically a module for everything you’ll think of. And for the rare case you won’t, it’s Python code, and it’s pretty simple.

What’s next?

Running a simple module is fine, be we want to run multiple complex ones, and we don’t wont to type commands. We want to push it to a CVS, and update it. While the ansible command is nice, we’ll be using the ansible-playbook command that will do most of the work.

Leave a Reply

Your email address will not be published. Required fields are marked *