Automation in the Cloud – Part 1 – Learning Ansible
   Mar 4, 2019     12 min read

” Ansible is designed with a simple principle in mind: Automation shouldn’t become more complex than the tasks it’s replacing. You should be able to save time and effort through automation.” (RedHat + OpenSource)

Following the previous Introduction blog post on Automation in the Cloud , in this post you can learn how to start learning Ansible with hands-on exercises close enough to the future Cloud reality.

Warm up


Same audience as in the previous Introduction post, but it’s time to do some hands-on.


To learn Ansible you need a minimum setup that will simulate real life, let’s call it the Ansible LAB, see the image below describing the lab you are about to build. With this Ansible Lab ready and reproducible within seconds or a few minutes tops, everytime you would like to reset it from scratch, you will be in a very good position to start learning Ansible and play various scenarios from the most basic ones to medium and even complex ones. And all at zero costs.


Some Linux background will help.

Post Type

Hands on: build your Ansible LAB

🎧 Playlist 🎧
  1. Cassandra Wilson – Billie’s Blues ⭐️ ⭐️ ⭐️
  2. Fun Lovin Criminals – Passive Aggressive
  3. Cassandra Wilson – Death Letter
  4. Fun Lovin’ Criminals – I Can’t Get With That (Schmoove Version)
  5. Fun Lovin Criminals – Rewind
  6. Fun Lovin’ Criminals – A Whiter Shade of Pale ⭐️
  7. The Handsome Family – Far From Any Road

The Ansible LAB

There are 5 steps to build your Ansible LAB




To build the Ansible LAB you will need to have the following minimum requirements:

  • localhost can be any OS, but I will refer to localhost as a *nix machine. 16 GB RAM and 1 CPU with some storage (SSD will be yummy) will be more than enough to get this LAB up and running every time you need a total reset, within **less than 3 minutes**.
  • Vagrant must be installed on your localhost. If this will be your 1st time when you will be using Vagrant, you may take some time to read about the commands mentioned later one, but it should be easy reading and should be straight forward.
  • Oracle VirtualBox – Vagrant support many providers (VMware, Hyper-V), I will be using Oracle VirtualBox, it is just perfect for the goal.
  • Depending on your localhost OS, you may need to install other additional tools (like for example, if you will be using Windows, a putty and/or a puttygen will be needed). I will leave this part to you, as you’ll go through this Post and install them, accordingly.

Some Housekeeping

  • I will be using CentOS 7 for Control Host and to keep it simple, I am going to use the same also for the Managed Hosts. However you may use any OS you would like (including Windows).
  • In the Ansible LAB am suggesting 4 Managed Hosts, 4 is a “nice” number, it may be sufficient for most of the scenarios, you may increase/decrease the number of Managed Hosts as needed, also within the hardware boundaries of your “localhost”.
  • In order to perform Ansible, you will need to install Ansible on the Control Host and you will be needing a python module available on each Managed Host. Along with that Ansible Control Host will need to be able to login on each Managed Host, therefore a user will be needed.
  • To keep it extremely simple, generate a user ansible (call it whatever you like , I will refer to this user from now on as ansible) for all the Lab machines with which you will be able to connect from localhost (but also between the machines, if ever needed) using SSH. The ansible user will be able to ‘sudo to root‘ as you will see later on in the details of the setup. Now, this is somehow redundant, because Vagrant comes already with a user named vagrant that does pretty much the same, but this is just to make a point here: we will be using Vagrant strictly to build the Ansible LAB machines.
    • Generate the ansible SSH keys (public and private) by using ssh-keygen (if on a Windows you could use puttygen), name them whatever you like, I will name them so I can refer to them later on, as:
      • ansible_ssh_key (the private key)

Configure your localhost hosts file so it will recognize the Ansible LAB machines (use any DNS names you would like), as detailed in the Ansible LAB image I will be referring to the machines as follows :

  • Control Host = ansible =
  • Managed Host 1 = server1 =
  • Managed Host 2 = server2 =
  • Managed Host 3 = server3 =
  • Managed Host 4 = server4 =

Step 1 – Installing Vagrant

Nothing really special here, just follow the Vagrant installation steps and guidance and you will be good to go.

! Be sure you will install VirtualBox Guest Additions before moving to next step !!

vagrant plugin install vagrant-vbguest  

Step 2 – Customize Vagrant Boxes

Vagrant has a very nice repository of images from which you can start to build your own OS and save it as a Vagrant Box for future reference.

For the purpose of this Ansible LAB we need to build 2 Vagrant boxes:

    1. Ansible Control Host BOX
    2. Managed Host BOX

Because I chose to have the same OS (Cent OS 7) for both Ansible Control Host and Managed Host, I can use an intermediary step to build an Ansible Vagrant BOX (Ansible BOX). And based on this Vagrant BOX I will build the Control Host and the Managed Host for the Ansible LAB.

If you know nothing about Vagrant, in a nutshell: Vagrant launches VMs based on a Vagrantfile you will be editing. The syntax within this file is Ruby, but you don’t need to understand Ruby, nor to bother to learn this programming language in case you don’t know it, as the files will be intuitive to use and provisioned in the following, and very easy for you to alter as per your own needs later on.
So, to launch a Vagrant VM, from inside the folder where you created and edited your Vagrantfile, just type:

vagrant up  


  • based on Cent OS 7 here is the Ansible BOX Vagrantfile you will create in a folder of your choice:
Vagrant.configure(2) do |config| = centos/7  
 config.vm.provider virtualbox do |v| = AnsibleBox  
  • launch the VM
vagrant up  
  • validate the VM is up and running
vagrant ssh  
  • add user ansible to the VM
sudo su –  
useradd ansible  
passwd ansible  
  • allow user ansible to sudo to root by creating an ansible file
vi /etc/sudoers.d/ansible  
  • and inserting the following line into it
  • check your user ansible is configured properly by running successfully:
sudo su – ansible  
sudo su – root  
  • edit your hosts file /etc/hosts with the IPs and DNS names of your machines, here is a sample ansible server1 server2 server3 server4  
  • upload the ansible SSH keys; since you already installed VirtualBox Guest Additions, you can just copy the SSH keys in your local directory and vagrant upthe machine again. Vagrant will always rsync by default your current folder into a /vagrant folder on your VM
vagrant halt  
cp /ansible_ssh_key .  
cp / .  
vagrant up  
  • copy ansible SSH keys and make sure they are in correct mode and owner (it should be 0600 with ansible:ansible)
vagrant ssh  
sudo cp /vagrant/ansible_ssh_key /home/ansible  
sudo cp /vagrant/ /home/ansible/  
sudo su – ansible  
sudo chown ansible:ansible ansible_ssh_key  
  • inject ansible public SSH key ( to assure you can SSH into this Ansible LAB machine from anywhere
mkdir .ssh  
chmod 0700 .ssh  
mv .ssh/  
touch .ssh/authorized_keys  
chmod 0600 .ssh/authorized_keys  
cat .ssh/ .ssh/authorized_keys  
cat .ssh/authorized_keys  
  • make sure you install python (on CentOS 7 box image is already installed)
sudo yum list installed python  
  • should you consider other utils you would always like to have them up and ready on your empty Ansible LAB VM, that’s a good place to install them (not much to think of,but maybe an ifconfig , a vim, a git, if you are into vi editor maybe some default indentation for YAML, maybe a nano etc)
  • now that we’ve configured our Anible Generic BOX let’s save it and prepare it for future usage:
vagrant package –output  
vagrant box add AnsibleBox  
  • At this point you should have in your Vagrant Boxes on your localhost AnsibleBox ready for future usage
vagrant box list  

Build Ansible Control Host BOX

  • bring up a VM based on the previously built AnsibleBOX
Vagrant.configure(2) do |config| = AnsibleBox private_network, ip:  
 config.vm.hostname =  
 config.vm.provider virtualbox do |v| = Ansible  
  • SSH into the VM and switch to ansible user
vagrant up  
sudo su – ansible  
  • add ansible ssh private key to the authentication agent; default Ansible method of connection to Managed Hosts is SSH
eval $(ssh-agent)  
ssh-add ~/ansible_ssh_key  
  • to make it available for each reboot in a consistent way insert the below in let’s say the ~/.bashrc for example:
if [ -z$SSH_AUTH_SOCK] ; then  
 eval `ssh-agent -s`  
 ssh-add ~/ansible_ssh_key  
  • install Ansible for CentOS:
sudo yum search epel  
sudo yum install epel-release  
sudo yum install ansible  
sudo yum install python-pip  
  • test Ansible is installed
ansible –version  
  • at this point you have a fully Control Host Customized for your LAB, save it as a Vagrant BOX for future reference:
vagrant package –output  
vagrant box add AnsibleLabControlHostBox  
  • list the Vagrant Boxes, you should find the two Vagrant Boxes you built so far:
vagrant box list  

Build Ansible Managed Host BOX

As mentioned already a few times so far, only CentOS was used in this Ansible LAB, and as such for Managed Host, we can use as the Vagrant Box, the already created CentOS LAB Generic AnsibleBox.

Follow similar steps to build Vagrant BOXes for other OS you would like to use as Managed Host or just download them from repo in your Vagrant BOXes on your localhost for easy access ( see next step).

Step 3 – Generate the Ansible LAB VMs:

Vagrant is powerful enough and instead of generating the VMs individually, you can automate everything by simply creating the following Vagrantfile ( in a folder of your choice, call it Ansible-LAB ):

 :hostname =,  
 :ip =,  
 :box = AnsibleLabControlHostBox,  
 :name = AnsibleControlHost  
 :hostname =,  
 :ip =,  
 :box = AnsibleBox,  
 :name = Server1  
 :hostname =,  
 :ip =,  
 :box = AnsibleBox,  
 :name = Server2  
 :hostname =,  
 :ip =,  
 :box = AnsibleBox,  
 :name = Server3  
 :hostname =,  
 :ip =,  
 :box = AnsibleBox,  
 :name = Server4  
Vagrant.configure(2) do |config|  
 servers.each do |machine|  
 config.vm.define machine[:hostname] do |node| = machine[:box]  
 node.vm.hostname = machine[:hostname] private_network, ip: machine[:ip]  
 node.vm.provider virtualbox do |v| = machine[:name]  

Now, to build the Ansible LAB for the 1st time, all you have to do ( while in the Ansible-LAB folder ) is to run:

vagrant up  

Within a few minutes tops, you should have the Ansible LAB up and running and ready to use.
To stop (power off gracefully ) the Ansible LAB just
run ( while in the Ansible LAB folder ):

vagrant halt  

To bring the Ansible LAB back to its latest status, run again:

vagrant up  

To destroy everything:

vagrant destroy  

Step 4 – SSH into the Controller Host

From your localhost SSH with ansible user into the ansible Control Host ( aka )

ssh -i ~/ansible_ssh_key ansible@ansible  

STEP 5 – Start learning Ansible by using it

Create a working directory and a test one:

mkdir -p work/test-lab  
cd work/test-lab  

Create an ansible.cfg file:

inventory = inventory  

Create an inventory file:  

Run an Ansible ping test on your Ansible LAB Machine Hosts:

ansible all -m ping  

If all ok it should output | SUCCESS = {  
“changed”: false,  
“ping”: “pong”  
} | SUCCESS = {  
“changed”: false,  
“ping”: “pong”  
} | SUCCESS = {  
“changed”: false,  
“ping”: “pong”  
} | SUCCESS = {  
“changed”: false,  
“ping”: “pong”  

Good luck in Learning Ansible.

Check again soon: by the time you will get familiar with Ansible ( working with dynamic Inventories, Ansible roles and so on … ), I hope to have some other Blog Posts ready, in which you could start combining Ansible with some of the major Cloud vendors and maybe even integrating with some other flexible tools, all to achieve IaaC ( Infrastructure as a Code ), Automation in the Cloud so you can get one step closer to a Continuous Delivery pipeline and all the other mandatory steps mentioned in the Introduction Blog Part.

Happy Sailing !