So, you wanna learn Ansible?

For that you’d need a control node, i.e. a system on which the ansible binary is installed on.

Local vs Containers vs VMs

You don’t want to install Ansible locally. Even if you think you do, don’t1.

You could use Docker and its official image. That’s what the cool kids use these days, eh?

But for this use-case, a Docker container might not be the most clever choice as quite a few Ansible modules (i.e. functions in Ansible lingo) can rely on python modules (i.e. libraries) and external tools not installed by default on this container.

To have more liberty of installing whatever dependency we want alongside Ansible, a VM might be a wiser choice.2

The VM pain point

VMs are generally slow to create, as you basically install the OS yourself.

Luckily, once a type of instance as been created once, it can be saved as a template for quicker spawning of new instances. This is pretty analogous to container images.

Vagrant is a wrapper tool around popular virtualization technologies3 that provide a unified syntax for declaring and spawning VMs from templates.

Those templates are called vagrant boxes and a hefty amount of community-driven boxes are readily available. You can think of it as Docker Hub for whatever virtualization technology you’re using.

Setting up an Ansible VM

As of writing, there is no decent Ansible control node Vagrant box available.

But that’s not an issue as we could just simply start with a generic box such as those provided officially by Debian, Ubuntu or the Roboxes project.

Vagrant support running scripts to provision a VM as it gets created. Most people use shell scripts but more provisioners (i.e. methods) are supported.

Namely, Ansible can be used if installed on the host (i.e. alongside Vagrant).

More relevant to our use case, a little-known feature is Vagrant can install Ansible for us on the guest (i.e. the VM) and use it for the VM to provision itself!

This is provided by the Ansible Local Provisioner. We can then use this Ansible instance installed on the guest to tweak it’s own configuration just after it gets installed.

That’s basically an Ansible control node provisioning itself 🤯.

The end result

The end result is available on GitHub:

Eigenbahn/vagrant-ansible-control-node - GitHub

It uses VirtualBox as a provider but could be easily adapted to whatever floats your boat.

You’d just have to:

$ git clone
$ cd vagrant-ansible-control-node
$ vagrant up
# [...]
$ vagrant ssh

And bam! You’re in.

Depending on your download speed, you’d end up with your control node in seconds to minutes.

Also, if you’re an Emacs user, you might want to check out package magrant for a tighter integration with Vagrant cli commands.


  1. Use whatever strategy (virtualenv/container/VM) to keep your base system as pure as possible. Trust me. 

  2. Likewise it’s ok to install yarn/composer/leiningen/whatever to bundle stuff on your control node in a first time instead of struggling to setup a bundling server or even propper CI/CD. 

  3. Even Docker is supported as a provider (i.e. virtualization technology), even though you’ll struggle to find anybody using vagrant for this use-case. 

Tagged #ansible, #vagrant.