In this blog, we’ll introduce you to Ansible, a versatile automation tool that finds extensive use in IT operations and software development. Ansible simplifies tasks with its user-friendly code, allowing you to manage servers, configure software, and automate workflows easily. It’s highly valued by DevOps and system administrators for its ability to enhance productivity while reducing manual labor.
To learn more about Ansible, watch this Youtube video by Intellipaat!
What is Ansible in DevOps?
To understand Ansible meaning in an easy way, let us look at its past and see how it has helped system administrators to be more agile at work.
On one hand, the developers were agile and were building and deploying code very frequently. The system administrators, on the other hand, were often lagged behind due to the constantly configuring systems. Although there were many configuration management tools like Puppet, Chef, Saltstack, Juju, CFEngine, none did the heavy lifting.
If the system administrator needed to install 8 servers out of which 4 servers were web servers and the remaining were database servers then they had to install Tomcat to web servers and MySQL to database servers. The installation of multiple types of servers to perform different operations was an exhaustive task. The entire installation process also consisted of installing media players and involved a lot of intricate steps.
This is where the prowess of Ansible comes into the picture and solves one of the major problems of multiple installations of servers. Using Ansible, it was easy to communicate the configurations in a single system and the server.
Here is a brief about the 3 types of tasks that Ansible automates:
Provisioning – This tool can be used to set up servers in the target infrastructure.
Application deployment – By automating the deployment to your production systems of internally developed applications DevOps is made way easier.
Configuration management – Alter configuration of an application, device, install or update applications, implement a security policy, OS, device, start and stop services. These is only some of the configuration tasks that can be done.
Irrespective of whether Ansible is hosted on the traditional servers, cloud, or virtualization platforms, it is highly efficient to automate IT environments. This Ansible config is also possible across various storage devices, firewalls, databases, etc. One of the interesting features that Ansible offers is that the user does not have to know the commands to perform a particular task. Only specifying what state a user needs to attain is enough!
Preparing for job interviews? Have a look at our blog on Ansible Interview Questions and excel your job interview!
Ansible architecture
In the world of Ansible, the architecture is gracefully simple yet powerful. At its basis, there are two key elements, the control node and the managed node. The control node is where you organize your Ansible tasks. It contains the inventory, which is a list of managed nodes, and the playbook, a file where you define the tasks and configurations to be executed on these nodes.
When you run an Ansible playbook, it sends these tasks to the managed nodes, which then execute the instructions and send back the results. Ansible doesn’t require any agent software on the managed nodes, making it efficient and easy to set up.
To learn more about Ansible, check out this Ansible Tutorial!
Get 100% Hike!
Master Most in Demand Skills Now !
What are the playbooks in Ansible?
Playbooks in Ansible are like a choreographer’s script for your automation tasks. They are the backbone of Ansible, designed to make automation accessible and efficient. Imagine playbooks as a set of instructions written in a language you can easily understand, telling Ansible what to do and how to do it. These instructions are structured in a step-by-step format, making it simple to follow along. A playbook typically consists of ‘plays,’ each representing a particular action that Ansible will perform on your target systems. These plays can be as diverse as configuring software, managing user accounts, or coordinating complex tasks across multiple servers. By using playbooks, you can ensure that your automation tasks are repeatable, consistent, and maintainable, saving you time and effort in the long run.
Ansible vs Puppet
Let’s look into how these robust configuration management (CM) tools differ from one another in this tutorial on Ansible.
| |
Ansible |
Puppet |
| Push vs pull |
Follows push workflow |
The client software in Puppet nodes periodically check Puppet master server to pull resource definitions |
| Server nodes |
No special master agent of special agent executables to install |
There are more than 1 puppetmaster servers along with special agent packages installed on each client node |
| Language extensibility |
Built on Python |
Built on Ruby and Ruby ecosystem is used to test Puppet applications |
| Syntax |
Ansible playbooks are YAML files |
Puppet’s domain specific language is a subset of Ruby. |
| Template language |
Based on Jinja2 which is a subset of Django’s templating language |
Based on ruby’s ERB |
| Resources and ordering |
Playbooks are applied top-to-bottom as they appear in file |
Resources defined in Puppet are usually not applied in order of their appearance |
Also check our blog on Ansible vs. Jenkins to find out the best performing tool.
Chef vs Ansible
In this Ansible tutorial let’s look into how the tool compares with yet another CM tool called Chef.
| |
Ansible |
Chef |
| Workflow management |
Seamless. What one sees on disk is what one deploys. |
Relatively difficult. |
| Maintenance |
Known for least maintenance |
Server and client component have to be periodically upgraded |
| Inventory |
Uses inventory scripts against EC2, rackspace to put out a list of hosts and groups |
Nodes are registered with the server and will be part of the search |
| Simplicity |
Simplest CM tool |
Relatively sophisticated CM tool |
Various concepts of Ansible
Let’s get a good grounding on various key concepts of Ansible.
Templates
A template file in Ansible is nothing but a text file with a .j2 extension. They are those files that are used to make the configuration files more dynamic.
Modules
The understanding of how Ansible works can be gained by connecting many nodes and pushing out small programs called ansible modules. Ansible comes with a number of such modules that can be executed directly on remote hosts or through playbooks. System resources like packages, services, or even files can be controlled by modules. They are also instrumental in handling system commands.
Ansible service module controls services on remote hosts. Ansible command module takes as input the command name and also a list of space-delimited arguments and the given command will be executed on all nodes but not on the shell.
Ansible modules can be written by users. The user module of Ansible manages user accounts and user attributes. The shell module in Ansible also works by taking as input the command name followed by a list of space-delimited arguments just like the command module.
There are various file modules in Ansible like Acl, archive, copy, fetch, file, find, iso_extract, lineinfile, patch, replace, stat, synchronize, tempfile, template, unarchive, xattr, xml.
Copy file
To copy a file from the local or remote machine to a location on the remote machine copy module is used. The fetch module copies files from remote locations to the local box.
Shell
The command name is taken by the shell module followed by some space-delimited arguments. It is quite similar to the command module but it runs the commands through the command module through a shell on the remote node. Win_shell module is used for windows targets.
Handlers
They are those lists of tasks that are referenced by a globally unique name and are notified by notifiers. The handler will not run if nothing notifies it. Irrespective of how many tasks notify the handler it runs only once and that too after all tasks complete in a particular play.
Inventory
This CM tool can be made to run in one’s infrastructure against multiple systems at the same time. To accomplish this, portions of systems listed in Ansible’s inventory are selected which by default gets saved in location /etc/ansible/hosts. A different inventory file can be specified using the -I <path> on the command line.
Playbook
In the fascinating world of Ansible, a ‘playbook’ corresponds to your roadmap for automation. It serves as the central element that organizes the magic of Ansible. So, what exactly is a playbook? Think of it as a collection of instructions written in plain language, much like a recipe book. These instructions outline the steps for Ansible to follow in order to carry out tasks. Playbooks are designed for humans, making them easy to understand, even if you’re not a coding expert.
Tasks
In the context of Ansible, ‘tasks’ are the foundational building blocks of automation. Imagine them as the individual steps in a recipe, each designed to accomplish a specific action within your automation process. Ansible tasks are written in a straightforward and understandable manner, making them accessible to both beginners and experts. You can think of them as the actions you want Ansible to take, such as installing a software package, creating a user account, or modifying a configuration file.
Roles
Roles consist of directories containing predefined tasks, variables, and handlers, neatly packaged together. These directories follow a consistent structure, making it easy to understand and reuse roles across different projects. For instance, if you often need to set up web servers, you can create a ‘web-server’ role with tasks for software installation, configuration, and service management. Then, you can use this role across various playbooks, ensuring consistency and efficiency in your automation.
Roles not only enhance the modularity and reusability of your automation code but also encourage collaboration, as they can be easily shared with the Ansible community. They’re a powerful tool that simplifies complex tasks and makes your automation journey a whole lot smoother.
Variables
In the world of Ansible, ‘variables’ are your toolkit for customizing and fine-tuning automation processes. Think of them as dynamic placeholders that allow you to store and manipulate data within your playbooks and roles. Variables are what give your automation flexibility and adaptability, enabling you to run the same playbooks on different systems with varying configurations.
These variables can hold a wide range of information, from simple values like numbers and strings to complex data structures. For example, you can use variables to define the version of a software package you want to install or to set different configurations for various servers. They can be set globally, making them accessible to all your playbooks, or locally within specific playbooks and roles for more control.
Want to gain an in-depth understanding of DevOps? Avail this Certification in Cloud & Devops course offered by Intellipaat.
Installation in Linux
Compared to other configuration management tools the installation and setup of Ansible are really easy. Quite a number of distributions have a package in their 3rd party repositories that can be easily installed. Creating a user and all notifying needs of Ansible can all be achieved with ease.
The apt command which follows is enough to install Ansible.
$ sudo apt update
$ sudo apt install software-properties-common
$ sudo add-apt-repository --yes --update ppa:ansible/ansible
$ sudo apt install ansible
APT expanded is an Advanced packaging tool which is the preferred Ansible package management toolset in Ubuntu. Packages can be installed, updated and also removed through this management toolset.
Read the difference between Terraform and Ansible in our comparison blog on Terraform vs Ansible.
Commands
There are a plethora of commands in Ansible but we’ll just give you a sample of a generic command.
- ansible-playbook playbook.yml: Execute an Ansible playbook defined in playbook.yml.
- ansible -m ping all: Check if all target hosts are responsive.
- ansible -i hosts.ini -m shell -a “uptime”: Run a shell command (uptime) on hosts defined in hosts.ini.
- ansible-vault encrypt secrets.yml: Encrypt a file with sensitive data using Ansible Vault.
- ansible-galaxy install author.role: Download and install Ansible roles from the Ansible Galaxy community.
Ansible advantages
In the CM world, there are alternatives for Ansible like Puppet, Chef, Saltstack and many others. But let’s see what benefits Ansible deployment really gives out.
- Ansible has fewer dependencies and therefore it is more stable and also very fast to implement. The user of Ansible who intends to host a very large infrastructure can do so without worry due to the efficiency of this tool.
- Ansible is agentless. An agent is a program that has to be installed on the remote system in order to work with it. It is also due to this virtue that you can quickly carry out your tasks with this tool.
- There is no database because of which it is highly portable. You can move it from system to system and not have to worry about having to set up a database. Consequently, you don’t require a DBA (Database administrator) to manage performance or backups or dealing with software upgrades when you’re upgrading the infrastructure.
- After you run your playbooks on your remote systems the software needed to run the playbooks is gone. After a piece of software accomplishes its task it is then gone. Hence there is no residual software.
- As there are no dependencies on other systems upgrading Ansible is very easy. There are no schema updates on a database server or deployment of agent upgrades. You just change the upgrade to the Ansible code on your control system and the upgrade is done.
Learn about the important terminologies in our blog on Ansible Cheat Sheet!
Conclusion
The Ansible tool as specified came in 2012 and became known for its simplicity. It is one of the defining points of this tool. Of all the documentations on Puppet, Chef and Ansible, the last tool is the easiest to follow. Puppet and Chef require Ruby which is relatively hard to learn as compared to YAML used by Ansible. This is the reason why it is a great favourite among systems admins which you have known from this tutorial on Ansible. When DevOps roles become more and more specialized in the IT industryAnsible for DevOps trends will only increase. System administrators familiar with this tool will greatly be in demand.
If you wish to be among the elite DevOps workforce, enroll in Intellipaat’s DevOps Training and gain your certificate.