Let’s talk about Ansible — Why, What & How
Over the past few weeks, I’ve been reading, learning and trying my hand at working with Ansible as a part of my internship with Red Hat as a Software Engineering Intern for the GEDI team. I feel, it’s time I document my learning and let the world know!
So back to Ansible,
It is an easy to use configuration management system that can assist you in configuring large numbers of servers from a single machine. You can automate complex tasks and easily add machines to your infrastructure without a lot of trouble.
Server systems are the underlying foundation of our applications and thus, like our applications, they should be version controlled, tested and automated. Hence, we looked for a configuration management tool that could solve our automation needs. We needed to find something that worked well, didn’t take a lot of time to learn, could easily be version controlled, and didn’t require any additional infrastructure to deal with. Here is where we come face to face with Ansible!
Configuration Management tools are not new, they have been around for some time, but their complexity always made their adoption a difficult process. This is where Ansible truly shines, it has lowered the learning curve so that it is easier to use Ansible than doing manual stuff or shell scripting, even for local install and configuration.
- It is a free and open source application
- Agent-less — No need for an agent installation and management.
- Python/yaml based.
- Highly flexible and configuration management of systems.
- Large number of modules for system management.
- Custom modules can be built, if needed.
- Configuration roll-back in case of error.
- Simple and human readable.
Ansible works by configuring client machines with Ansible components installed and configured. Unlike Puppet or Chef, it is an agent-less on the remote host(s). Ansible uses SSH channels in order to retrieve information from remote machines, issue commands and copy files, which is assumed to be installed on all the systems you want to manage. There are no servers, daemons, or databases required.
This means that you don’t have to setup a client server environment before using Ansible, you can run it from one of your machines and from the clients point of view, there is no knowledge of an Ansible server (you can run Puppet in standalone mode, but Puppet still needs to be installed). This is one way that Ansible simplifies the administration of servers. Also, as it’s written in Python. So, Python version specifically 2.4 and higher must be installed on the remote host(s).
Configuration files are mainly written in the YAML data serialization format due to its expressive nature and its similarity to popular markup languages. Ansible can interact with clients through either command line tools or through its configuration scripts called Playbooks.
Step wise —
- We need to set up the architecture
- SSH keys to remote hosts- password-less SSH connection to remote hosts
- Managing the inventory file- It has host entries, IP addresses or host names. A static host inventory is defined in an INI-like text file, in which each section defines one group of hosts (a host group)
- Using Ansible by writing playbooks and modules and executing them
As mentioned above in point #3, inventory files have host entries i.e., IP addresses and host names of managed hosts.
Normally, however, you organize managed hosts into host groups. Host groups allow you to more effectively run Ansible against a collection of systems. In this case, each section starts with a host group name enclosed in square brackets (). This is followed by the host name or an IP address for each managed host in the group, each on a single line.
In the following example, the host inventory defines two host groups, Karnataka and Maharashtra.
Also, Ansible host inventories can include groups of host groups. This is accomplished with the :children suffix. The following example creates a new group called India, which includes all of the hosts from the Karnataka and Maharashtra groups.
The behavior of an Ansible installation can be customized by modifying settings in the Ansible configuration file. Ansible chooses its configuration file from one of several possible locations on the control node.
The ansible package provides a base configuration file located at /etc/ansible/ansible.cfg. This file is used if no other configuration file is found.
Configuration file precedence
The search order for a configuration file is the reverse of the preceding list. The first file located in the search order is the one from which Ansible will use configuration settings from. Ansible will only use settings from this configuration file. Even if other files with lower precedence exist, their settings will be ignored and not combined with those in the selected configuration file.
Highest precedence- Any file specified by the $ANSIBLE_CONFIG environment variable will override all other configuration files.
If this variable is not set,
second highest precedence- The directory in which the ansible command was run is checked for an ansible.cfg file.
If that file is not present,
third highest precedence- the user’s home directory is checked for a .ansible.cfg file. These files are called hidden files.
Lowest precedence- The global /etc/ansible/ansible.cfg file is only used if no other configuration file is found.
When you install Ansible, your directory will have an ansible.cfg file. We will build on that if you choose to create your own configuration file in favour of the global /etc/ansible/ansible.cfg configuration file, you need to duplicate all desired settings from that file to your own user-level configuration file.
Next blog, Introduction to Playbooks along with how to use inventory files and config files with playbooks.
Watch this space for more on Ops tools like Ansible :)