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. A few of these are:
- Managing multiple servers
- Scaling up and scaling down
- Syncing 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.
Features of Ansible
- Simple and easy to 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 the control machine.
sudo apt install ansible
sudo dnf install ansible yum install ansible
Arch Linux-based :
sudo pacman -S ansible
sudo pkg install ansible
sudo pip install ansible
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:
[mailservers] mail.example.com [webservers] foo.example.com bar.example.com [dbservers] one.example.com two.example.com three.example.com
A YAML version would look like this:
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:
It is easy to assign variables to hosts that will be used in playbooks:
[testservers] host1 http_port=80 maxRequestsPerChild=808 host2 http_port=303 maxRequestsPerChild=909
We can also define variables that can be applied to an entire group:
[testservers] host1 host2 [testserver:vars] ntp_server=ntp.testservers.example.com proxy=proxy.atlanta.example.com
In Ansible inventory, we can create groups of groups and can set a variable for those groups of groups:
[india] host1 host2 [japan] host3 host4 [asia:children] India Japan [asia:vars] ansible _user=value [world:children] asia europe
There are two default groups: all and ungrouped. all contains every host and ungrouped contains all the hosts that do not have a group aside from all.
Ansible Ad-Hoc Commands
An ad-hoc command is something that you might type in to do something rapidly, but don’t want to save for later. Just like executing a command in the shell instead of creating the 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:
ansible host_group -m ping
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 the 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 a playbook:
--- - 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
Every playbook starts with three dashes (---) followed by host list, then a variable list, then a task list, and at the end there are handlers.
The host list contains the list of hosts where we want to run the task.
The variable list is to set the properties for the current play.
The task list contains the number of tasks which are going to execute.
The 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.