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
- YAML Based Playbook
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.
Arch Linux-based :
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 the –i <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:
A YAML version would look like:
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.
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:
|– hosts: webservers|
|– 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|
|– restart apache|
|– name: ensure apache is running (and enable it at boot)|
|service: name=httpd state=started enabled=yes|
|– name: restart apache|
|service: name=httpd state=restarted|
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.
Ansible Documentation: http://docs.ansible.com/