Getting Started with Ansible

Ansible
Table of contents
Reading Time: 4 minutes

What is Configuration Management?

Before starting with Ansible let’s discuss what configuration management is. Configuration Management (CM) is the process of handling changes in any system systematically, and it maintains the consistency of the product. It retains its consistency because it is applied over the entire lifecycle of the system. Configuration Management provides the capability of controlling and monitoring the performance of the system. Using this capability of monitoring we can prevent errors by notifying and controlling the capability to change anything in the system. If any of node in cluster gets failed we can reconfigure it. Also, configuration management keeps the snapshot of all the version of infrastructure.

Why Configuration Management?

The reason why we should use configuration management is to overcome the difficult situation that we face while setting up the cluster. Few of these are:

  • Managing multiple servers
  • Scale Up and Scale down
  • Sync up with development team and infrastructure team

What is Ansible?

Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs. It can be used for advanced tasks such as continuous deployments or zero downtime rolling updates. Ansible is a push-based configuration management tool; it means we can push configuration onto the node machine directly without having any central node. It communicates with remote machines over SSH.The main goals of Ansible are ease-of-use and simplicity.  

Feature of Ansible

  • Simple and Ease-of-use
  • Agentless
  • YAML Based Playbook

Installation

Ansible communicates with other node using SSH protocol. It does not require any database installation or any running process. You only need to install it on one machine it can even be your local machine. You just need Python installed on your system. However, Windows is not supported for control machine.

Ubuntu:

 

 

CentOS/Fedora :

 

 

Arch Linux-based :

 

 

FreeBSD :

 

 

PIP :

 

 

Ansible Inventory

Ansible can work for multiple systems at a time. It achieves this by selecting portions of systems listed in Ansible’s inventory which is by default saved in the location /etc/ansible/hosts. You can specify a different inventory file using thei <path> option on command line.

The inventory file can be in one of many formats, depending on the inventory plugins you have. For this example, the format for /etc/ansible/hosts is an INI-like and looks like this:



This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters


[mailservers]
mail.example.com
[webservers]
foo.example.com
bar.example.com
[dbservers]
one.example.com
two.example.com
three.example.com
view raw

hosts.ini

hosted with ❤ by GitHub

A YAML version would look like:

 



This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters


all:
hosts:
mail.example.com
children:
webservers:
hosts:
foo.example.com:
bar.example.com:
dbservers:
hosts:
one.example.com:
two.example.com:
three.example.com:
view raw

hosts.yml

hosted with ❤ by GitHub

It is easy to assign variable to hosts that will be used in playbooks:

We can also define variable that can be applied for an entire group

In Ansible inventory we can create groups of groups and can set a variable for those group of groups.



This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters


[india]
host1
host2
[japan]
host3
host4
[asia:children]
India
Japan
[asia:vars]
ansible _user=value
[world:children]
asia
europe
view raw

group_host.ini

hosted with ❤ by GitHub

There are two default groups: all and ungrouped. all contain every host and ungrouped contains all the host that does not have group aside from all.

Ansible Ad-hoc Commands

An ad-hoc command is something that you might type in to do something rapid, but don’t want to save for later. Just like executing a command in shell instead of creating shell script for that. An ad-hoc command contains two different parameters; the host group on which task is going to run and the module to run. If you want to ping each host with a single command you can do it using the following,

Similarly, you can perform many other operations using ansible like copying a file, managing packages, gathering facts, etc.

Ad-hoc commands are a powerful yet straightforward feature of Ansible.

Ansible Playbook and Modules

Playbooks are a completely different way to use ansible than in ad-hoc task execution mode and are particularly powerful. There is a way to send commands to the remote node using the script. Like a shell script that contains the set of command. Ansible Playbooks are written in the YAML format. YAML is a data serialization language.

In every Playbook there are one or more ‘plays’ in a list. The goal of play is to map hosts with a certain function. Ansible does it through the task which is nothing more than a call to an ansible module.

Example of the playbook:



This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters


– hosts: webservers
vars:
http_port: 80
max_clients: 200
remote_user: root
tasks:
– name: ensure apache is at the latest version
yum: name=httpd state=latest
– name: write the apache config file
template: src=/srv/httpd.j2 dest=/etc/httpd.conf
notify:
– restart apache
– name: ensure apache is running (and enable it at boot)
service: name=httpd state=started enabled=yes
handlers:
– name: restart apache
service: name=httpd state=restarted
view raw

playbook.yml

hosted with ❤ by GitHub

Every playbook starts with three dashes (—) followed by host list then there is a variable list then task list, and at the end there are handlers.

host list contains the list of hosts where we want to run the task.

Variable list is to set the properties for the current play.

task list contains the number of tasks which are going to execute.

Handlers are also tasks; the only difference is that in order to execute handler we need some trigger in the list of task. For example, notify. These ‘notify’ actions are triggered at the end of each block of tasks in a play, and will only be triggered once even if notified by multiple different tasks.

To run a playbook we can use the following command:

Ansible ships with many modules (called the ‘module library’) that can be executed directly on remote hosts or through Playbooks.

Users can also write their own modules. These modules can control system resources, like services, packages, or files (anything really), or handle executing system commands.

Resources:

Ansible Documentation: http://docs.ansible.com/

Written by 

I am from India and developing Scala Microservices :)

Discover more from Knoldus Blogs

Subscribe now to keep reading and get access to the full archive.

Continue reading