What does Ansible Do? From Beginner to Expert in 10 Minutes!

We love Ansible at OSO. The learning curve is very gradual, and you can get value from it after just spending a few minutes working with it. But what does Ansible do and, and how do you get started with learning Ansible? In this blog we’ll cover all of that, and more.

What does Ansible do and What is Ansible used for in DevOps?

Ansible is an open-source tool that allows your whole infrastructure to be defined as code so that it can be version controlled, easily replicated and tested. DevOps team use Ansible to automate and orchestrate deployment of applications.

Basic Ansible Terminology and Concepts

• Ansible and its module are written in Python, but you don’t need to know Python to use it
• Ansible is Agentless
• Ansible connects to remote servers and nodes using SSH

Some words you’ll come across in the Ansible world.

Ansible Playbooks

The entry point for configuration management in Ansible. A playbook is a YAML file that instructs Ansible on what to do. Below is an example of what a playbook looks like:

---
 - name: ansible playground
   hosts: all
   connection: local
   tasks:
     - debug: msg="Hello World!"

Task

Tasks define an operation to be performed on the destination host. From installing a package to staring a service and much more.

Ansible Inventory

Is an INI file that lists and groups our hosts, which Ansible uses to know the destination hosts to apply the configuration to. Hosts entries usually include the hostname and few variables you can pass to Playbooks.

Roles

Simply put, Roles are a collection of Tasks. For example, getting Apache up and running usually involves various tasks. To improve efficiency and reduce code duplication, we can group this task into an Apache Role that we can then reuse in multiple Playbooks.

Setting up Ansible

Ansible can be set up in multiple ways, but by far the easiest is by using the Python package manager PIP.

• Install PIP

# Debian/Ubuntu:
apt-get install python-pip

# RedHat/CentOS/Fedora:
yum install python-pip

# MacOSX (more info):
sudo easy_install pip

• Install Ansible

pip install ansible

• Confirm installation

ansible --help

Se up the Ansible Inventory

By default, Ansible on Linux will look for the file /etc/ansible/hosts. A simple way to startup is to create this file with the below contents;

[localhost]
127.0.0.1

Configuration

To define a different location for your inventory file or where are Roles are located, we update the ansible.cfg file.

Ansible will look this file in the current directory, or in your home directory (named .ansible.cfg) and finally in /etc/ansible/ansible.cfg.

[defaults]
inventory = hosts
remote_user = ubuntu
host_key_checking = False

Run an Ansible Playbook

We’re now set up and ready to run our first Playbook. Using the example Playbook above, save it as hello.yml

We have set our hosts to all which means Ansible will target all hosts in our inventory file which at the moment is just 127.0.0.1. We also specified connection is local to tell Ansible to run without SSH

This should be the structure of our ansible101 folder;

+-- ansible101
    +-- hosts.ini
    +-- ansible.cfg
    +-- hello.yml

Time to run our playbook;

ansible-playbook hello.yml

Anatomy of a Playbook run

• PLAY [ ansible playground ] : The start of the Playbook run
• TASK [ setup ] : Ansible is collecting information from the host and setting up to run the Task
• TASK [ debug ] : Ansible is running the Task
• PLAY RECAP : For each host, the number of tasks resulting in ok, changed, unreachable and failed

Advanced Ansible Terminology and Concepts

So far we have run an Ansible playbook on our localhost, but not much can be done with localhost. It’s now time to connect to and manage external hosts and perform some configuration management there.

Control Machine

The machine is running Ansible and connecting to remote/external hosts to perform configuration management.

Remote Host

The machine Ansible accesses via SSH to configure. It does not need to have Ansible installed. The only requirements are SSH and Python.

For the rest of the post, the remote host is an Ubuntu 14.04 EC2 host launched on AWS.

Let’s go ahead and update our inventory.

[webservers]

52.36.50.107


The updated inventory file tells Ansible we now have a group of remote hosts called webservers with one host.

Accessing Remote Hosts

As mentioned, Ansible connects to remote hosts via SSH. To access the external remote hosts, we need to setup password-less SSH access, i.e. the control host have to be able to access the remote host without it asking for a password.

There’re plenty of tutorials online on how to do this and below are some links;

• https://www.linuxproblem.org/art_9.html

SSH Keys

By default, SSH will look for a private key in ˜/.ssh/id_rsa. However, we want to be able to tell Ansible where to look for the private key of each host, so we have flexibility later when different hosts use different keys.

Route 1: One key for all hosts

Add an option to ansible.cfg file under [defaults] section:

private_key_file=/etc/ansible/keys/access.pem


Route 2: One key per host

In your inventory file, add a variable to the host:

[webservers]

52.36.50.107 ansible_ssh_private_key_file=/etc/ansible/keys/web.pem


Route 3: One key per group of hosts

Also in your inventory file, but using group variables:


[webservers:vars]

ansible_ssh_private_key_file=/etc/ansible/keys/web.pem


Route 4: Use SSH config

Since Ansible uses SSH, you can let the SSH service to decide which key to use in each host. This is the least prefered option.

Host 55.44.33.22 *.awesomecompany.ly

IdentityFile /etc/ansible/keys/access.pem


We will go with Route 3. Our inventory file now looks like this;

[webservers]
52.212.184.18


[webservers:vars]

ansible_ssh_private_key_file=/etc/ansible/keys/web.pem


Configure Remote Hosts

Let’s update our playbook to target the webservers and install Apache on the remote hosts. Save the updated file as webservers.yml

---

- name: ansible playground

  hosts: webservers

  sudo: yes

  tasks:

  - apt: name=apache2 state=present

• hosts: webservers : We’re targeting the webservers group
• sudo: yes : Ansible will perform tasks as root
• apt : This is the Ansible module and takes the name and state parameters

We can now run the playbook.

ansible-playbook webservers.yml

Let’s rerun our playbook.

As you can see from the second run, the result is different, but nothing happens.

Tasks should always be idempotent which means that once our desired state has been reached, nothing should change when we repeat the same task.

Looking at the language we used, we say state=present instead of install. This way the Ansible apt module is going to make sure it is present and install only if it must.

Conclusion

Now that you can create and run playbooks, they need to do something useful. Ansible has 100s of modules to perform actions in the operational system.

And that’s it for this introduction, hopefully you now know what Ansible does and some basic concepts.

At OSO, our experts can maintain your DevOps platform and be responsible for day-to-day operational issues, allowing you to develop and ship your product without the need for internal DevOps hires. Get in touch to talk about how we can help.