Ansible is a configuration management tool. It allows us to automate the deployment of our infrastructure. The tool is extremely popular. On the one hand, it allows us to scale up our infrastructure by breaking down complex tasks, and thereby, increasing functionality. On the other hand, it allows us to scale down our operations by making tasks simpler to perform.
Ansible uses codes called playbooks to achieve its results. Therefore, it is an Infrastructure as Code (IaC) solution to automate infrastructure deployment. These playbooks use a simple language – YAML – which is similar to English. Hence, they allow us to describe automation jobs easily. We can simplify playbooks further using roles. Roles break down playbooks into smaller, multiple files for smooth execution. They are shared regularly in the Ansible community – Galaxy.
As a configuration management tool, Ansible is adept at managing multiple systems at a time. It uses a “push-based” approach to execute changes, unlike Puppet and Chef, which are “pull-based”. In the push-based approach, we can decide when to make changes. Furthermore, Ansible does require an agent or a custom security infrastructure. Therefore, it is easy to deploy. In the following article, we shall discuss Ansible architecture, how to connect to the configuration management tool, how to define inventories in simple text files, ad hoc task execution, and playbooks.
Ansible Architecture
Ansible can manage nodes via SSH. It pushes out small programs called “modules”. These programs are essentially models to achieve the state we desire in systems. Ansible executes and then discards these modules. Their libraries can reside on any machine. It doesn’t require a server, daemon or database. Typically, we use a terminal program (like bash or csh), a text editor (like vim, nano or gedit), and a version control system (like git or svn) to track the changes to our content, while executing the modules.
Connecting to Ansible
Although Ansible supports passwords, it works best with SSH keys and ssh-agent. It does not require root logins. Thus, you can login as any user. To make changes you can use “su” or “sudo” to run programs as a privileged account. Moreover, the network authenticating program Keberos is also compatible with Ansible. We can use it to authorize users. Or, we can use the “authorized_key” module for this purpose. Other identity management systems, which are compatible with Ansible, can also be used to authorize users.
Defining Inventory in Simple Text Files
Ansible identifies the machines it manages using a very simple INI file. The default location of the file is /etc/ansible/hosts. This host file records the inventory of machines. We can record machines under multiple groups. Unlike Puppet, again, Ansible requires no additional security handshake (like SSL signing server) to add a new machine. Hence, it is easy to troubleshoot the problems that we encounter while linking machines. We don’t have to worry about obscure NTP or DNS issues. Lastly, Ansible can also plugin to other sources of truth in any infrastructure like EC2, Rackspace, OpenStack, if they are available.
Example of plain text inventory file:
[webservers] www1.example.com www2.example.com [dbservers] db0.example.com db1.example.com
Ansible can assign variables to inventory hosts once they are listed in the subdirectory ‘group_vars/’ or ‘host_vars/’. Alternately, it can also assign the variables directly in the inventory file.
Ad Hoc Task Execution
Once we have an instance available in our inventory, we can talk to it right away without any additional setup.
ansible all -m ping ansible foo.example.com -m yum -a "name=httpd state=installed" ansible foo.example.com -a "/usr/sbin/reboot"
For example, with “ansible all -m ping”, Ansible will attempt to connect to the machines remotely using the current user name, like in SSH. To override the remote user name, we can use the ‘-u’ parameter.
Ansible can execute state-based resource modules as well as raw commands. The modules are easy to write. On top of that, Ansible provides many built-in modules (over 750 of them) as solutions to a wide range of common problems.
Playbooks
Playbooks offer a different way to use Ansible in addition to the ad hoc task execution mode. They are extremely powerful as they allow us to manage our configuration and our multi-machine deployment system easily. Moreover, Playbooks can implement multiple nodes in our infrastructure topology, with excellent control over the machines it manages. They can even launch tasks either synchronously or asynchronously.
Ansible’s approach towards infrastructure automation and code execution is simple and well-tuned. It requires little special syntax or features, and is easy to decipher because of its closeness to English.
Example of a playbook:
--- - hosts: webservers serial: 5 # update 5 machines at a time roles: - common - webapp - hosts: content_servers roles: - common - content
Example of a playbook to install httpd server:
--- - yum: name=httpd state=installed with_items: - httpd - service: name=httpd state=running enabled=yes - template: src=/opt/code/templates/foo.j2 dest=/etc/foo.conf notify: - restart httpd
In the above example, the playbook is defined in such a way that it:
- Installs https package from yum.
- Enables and starts httpd service.
- Modifies the foo.conf file in the destination node (by using the foo.j2 as a template).
- Restarts the service “httpd” whenever it is implemented.
Enroll for the DevOps Certification Training from ACADGILD. For the best work ethics.