Description:
A Simple but Powerful framework for IT Automation
In the previous blog, Eshan Sarpotdar, had stressed on the need to synchronize the development with IT operations (DevOps). It’s a broad term and there are different models of DevOps on People, Processes and Technologies. As an engineer, my focus remains on the Technology aspects of DevOps.
At Harbinger, we have been experimenting with Puppet and Ansible. Both of these are open source frameworks for IT automation. In our research, we found Ansible to be easy to install and learn, than other frameworks. In this series, we would also share our experiences, starting from scratch for the framework.
Why not Puppet but Ansible?
Puppet has been around since 2005, while Ansible is the new kid on the block. Obviously the largest mind share is still held by Puppet, however it has become too bulky. There is a master and there are nodes listening to the master through an agent installed on each node. To pamper the developers, Puppet provides a GUI. Point to be noted, this interface is used only for monitoring purposes. For all advanced task orchestration, you will use the command line interface, and there, the learning curve for teams appeared not so simple.
Ansible on the other hand is an agentless SSH based system and though it has got a custom scripting language for automation, it is also very simple to learn. Further offering numerous opportunities for engineers at the beginning level to take up DevOps with ease.
Installing Ansible
Installing Ansible on a Linux based server is very simple. On CentOS based computers you can install the latest Ansible via Yum as:
Installing Ansible via yum
For Ubuntu servers you may want to add Ansible in your ppa repository. These are described in details here.
System Architecture
Ansible is written in Python, but the control code is done through a yml file called playbook. The yml file requires only data to be set as a configuration parameter, thus you don’t have to write code but just provide data in playbook and Ansible modules will do the rest. The architecture of Ansible is shown in the following figure:-
Ansible Architecture
The user interacts with Ansible through Playbooks and Host inventory file. A Host inventory file lists all the server nodes involved in an application deployment or monitoring. The user can group them in several logical names in an INI like format. Here is an example of host inventory file located at: /etc/Ansible/hosts
Ansible Host Inventory
Here, webservers and appservers mentioned in brackets are group names and a node can appear in multiple group names. For example, one web server can also host a chat module of your application exposing a web socket. You may then want to create a separate group called [chat] and list this instance there as well.
Getting Hands on Ansible
Now let’s say you want to check the server health in your deployment cluster. You can do that by providing a single command:
Checking Server Health
And if all is good then you may get an output as:
Server Health Output
Here, all keywords are server nodes, -m is a module identifier and, in this case it has invoked ping module of Ansible. In another instance, if you wanted to check the ping status of let’s say Appservers, you would do it as:
Appserver Ping Status
Ansible also provides ability to set configuration parameters in the host file. Next, we want to see how to write Playbooks. In Ansible, a Playbook describes a series of tasks for orchestration over the ensemble of server nodes.
The playbooks are simple yml files where we describe and configure the tasks to be performed on the given group of nodes. Everything is ordered sequentially from top to bottom, for an example- play to install Apache web server on the server nodes is listed in webservers group in host inventory file could be:
/etc/ansible/install_httpd.yml
Install Apache Web server in Ansible
In this playbook, we have mentioned yum and service as the modules of Ansible, however there are over 250 modules listed on the Ansible portal. Using modules instead of custom shell script renders Ansible play in a maintainable and human readable format. For example, there are modules for Amazon AWS cloud, now if you want to store objects, say machine images in S3 then the s3 module will perform this task witout any effort.
Before executing the task, the Ansible module gathers facts from the server node. These Facts provide access to environment variables of the remote server. Some of the important modules in different tasks of DevOps are listed here:
Devops Modules in Ansible
Ansible is just not limited to installation and configuration management. It is powerful enough to manage continuous integration for rolling out builds constantly. For now, I would conclude this article saying that Ansible is easy to learn and is a very powerful framework in managing and orchestrating remote server tasks.
http://blog.harbinger-systems.com/2015/03/know-why-devops-at-harbinger-loves-ansible/
blog directory 
