Overview Of Ansible Automation

You may have searched the Internet and still not understand what Ansible is and what it is used for, or how it can benefit your organization and fit into your DevOps workflow. Then you are in the right place!

Let’s start with a real-life example in which you have been asked to provision 3 servers either on a public cloud provider such as Microsoft Azure or AWS or on-premises data center, configure each server’s environment for the application, and put a load-balancer over them.

Now probably the most tedious and time-consuming tasks for you while configuring these servers could be,

• SSH into the server
• Add runtime’s PPA
• Install the latest version of the runtime
• Configure any other server settings such as changing host in Apache\Nginx

You have to repeat those steps for each server and suppose if those were 10 or more servers instead of 3, how painful it could be. This is where we use a Software Configuration Management (SCM) tool and one of the most popular is Red Hat’s Ansible which we’re going to see next.

Ansible Automation & Architecture

Ansible is an SCM tool and is used to automate repetitive tasks that are usually done on a server. Ansible SCM tool consists of 3 core subsystems: ACS (Ansible Control Server), Ansible Inventory and Ansible Playbooks. Before seeing a live example, it would be better to understand these Ansible terms and architecture a bit so can go with it.

At first, ACS or Ansible Control Server is the component which does the main configuration tasks on one or more servers. ACS server can be located on your own local machine or somewhere else on the Internet. Ansible Inventory (As the name suggests) is the inventory of Servers where ACS will perform the configuration steps and finally Ansible Playbooks are those required steps that ACS will perform on that inventory of servers. Ansible interacts with servers via SSH protocol which is a secure way of managing and configuring servers; i.e., all the operations and file transfers are encrypted in every session.


As illustrated in the above image the servers are in one of the Azure regions (see next), ACS interacts with the server through the Inventory file (as those servers are defined in the inventory file) and apply the configurations defined in the Playbooks. It is important to note that ACS does not use any database which makes it super light-weight to download, install and configure. Let’s see an example to see Ansible in action.

It is expected that you have installed Ansible on your machine. If you didn’t, take a look at this documentation to see how to install Ansible. It’s easy!

Using Ansible

Suppose you provisioned 3 raw web servers (Virtual machines) in a cloud provider such as AWS or Microsoft Azure (In our case). While provisioning virtual machines, a public IP address will be assigned to each VM so we can access them via the Internet. First we need to add these IP addresses to Ansible Inventory file.

Adding Servers to Ansible Inventory

Ansible Inventory is a file where you describe your targeted servers. In Linux (Debian-based systems), the default location of inventory file is /etc/ansible/hosts directory but you can create this file somewhere else and use the -i flag in the Ansible CLI to specify the inventory file.

For now, we would like to use the default file location. So open-up this file in an editor and at first, you will see a lot of comments in the inventory file but try to configure your servers at the bottom of the file by creating a group of servers named webservers like:

[webservers]

xx.xx.xx.xx

xx.xx.xx.xx

xx.xx.xx.xx

You can use groups to target a specified number of servers for configuration in Ansible. Groups are defined in []. You can even create groups of groups and divide your inventory file with one or more files.

Make sure that your system’s public SSH key is added to each Azure VMs as the identity mechanism as Ansible works well with SSH. If you used SSH password-based authentication, use the -k flag with the Ansible CLI which will ask for a SSH password while running Playbooks. Now our inventory is ready, lets create a Playbook to configure our servers.

Creating Ansible Playbooks

Ansible Playbooks are used to configure servers to your desired-states. Playbooks are YAML files and are composed of Playbook Modules. Ansible Playbook Modules are abstractions for configuring servers. For example, for installing a Debian package via apt, there is a built-in module to do the same task in an abstracted way as we will see in a bit. There are hundreds of Ansible Modules out there for various types of configurations. Click here to learn more about Ansible Modules.

So, what we want from Ansible now is to,

• Install the latest Node.js LTS version on each server via PPA
• Install webpack NPM module globally

This is a super simple illustration of the how Ansible Playbooks works. The Playbook YAML file for this is given below,

---
- hosts: all
  gather_facts: yes
  become: yes
  tasks:
    - name: Install the gpg key for nodejs LTS
      apt_key:
        url: "https://deb.nodesource.com/gpgkey/nodesource.gpg.key"
        state: present

    - name: Install the nodejs LTS repos
      apt_repository:
        repo: "deb https://deb.nodesource.com/node_6.x  main"
        state: present
        update_cache: yes

    - name: Install the nodejs
      apt:
        name: nodejs
        state: present

    - name: Install "webpack" node.js package globally
      npm:
        name: webpack
        global: yes

Copy and save this file with a name (such as node.yml) and that’s it. Now our Ansible Inventory and Playbook are ready. Next, we need to tell ACS Server to start configuring the server.

Running ACS Server

Finally, open up the terminal at the directory containing your Playbook and run the command: ansible-playbook node.yml. This command will install NodeJS LTS and webpack package on each Azure VM. You don’t have to manually SSH into each server, add PPA, run apt command etc and everything will be done for you by the ACS server. It's a  true Automation Tool.

Conclusions

Well, there is a lot to cover regarding Ansible to master it such as managing Ansible Playbooks with Ansible Roles, sharing to Galaxy, creating your own Ansible Modules, and more. We may look at this in some future post. This is a super basic example of getting up and running with Ansible. There are other SCM tools available. Some popular ones are Chef, Puppet, SaltStack, PowerShell DSC and others. But in the last couple of months, Ansible got a huge amount of attention due to its simplicity, speed and huge online community.