Imagine you are a system admin and have 8 servers where 4 servers are web servers and the remaining 4 are database servers. You intend to install Tomcat to the web servers and MySQL to the database servers. The installation of such servers is not easy as installing media players as it involves a lot of intricate steps. There is every possibility that you might mess up in installing or you might install one server one way and the other server in another way. This is definitely not conducive to the optimal functioning of the servers. So there has to be a solution to rectify this dilemma.
Watch this video on DevOps Tutorial for Beginners
Also, developers were agile and were building and deploying code very frequently. The system administrators on the other hand simply lagged behind. They seemed to be ever involved in configuring the systems. There were many configuration management tools like Puppet, Chef, Saltstack, Juju, CFEngine. Ansible came along in 2012 created by DeHaan. The latest Ansible version is 2.4.3.
In Ansible, you can communicate the configurations you want in a single system and have it do the installation for all the servers. Ansible does a lot more than just provisioning. It is an IT automation engine that can greatly enhance the scalability, consistency and reliability of a particular IT environment.
What is Ansible?
Ansible is an open-source software developed by Michael DeHaan and its ownership is on RedHat. Ansible affects the automation of various IT tasks like configuration management, deploying and updating applications on-premises or in the cloud and creating development environments.
In this what is Ansible blog, we’ll elucidate on 3 types of tasks that the tool 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 they are highly efficient to automate IT environments. This Ansible config is also possible across various storage devices, firewalls, databases etc. The surprising part here would be that you needn’t know any commands to effect a particular task. You just need to specify what state you want the system to attain and Ansible will do the rest.
The playbooks in Ansible contain task(s) and are expressed either with core modules or custom modules that one can write for special situations. Where all the playbooks will be implemented in the target machines will be decided by the host inventory file. As Ansible runs on Python the remote servers should have the language installed. The plays(tasks) are done from top to bottom. Playbooks are written in YAML (Yet Another Markup Language) and are declarative in nature. YAML is a human-readable data serialization language.
Learn more about Ansible in our blog on Ansible Tutorial!
How playbooks come into play in Ansible?
Playbooks is the language for Ansible’s configuration, deployment, and orchestration. They describe a policy as to how remote systems should be enforced, or a set of steps in a general IT process. If Ansible modules are the tools in the admin’s workshop, playbooks are his instruction manuals, and his inventory of hosts are simply his raw material.
Basically, playbooks are used to manage configurations of remote machines and their deployments. At a more advanced level, they can sequence multi-tier rollouts involving rolling updates. They can also delegate actions to other hosts, interact with monitoring servers and load balancers.
Comparing Ansible with Puppet
Let’s look into how these robust configuration management (CM) tools differ from one another in this tutorial on Ansible.
|Push vs pull
||Follows push workflow
||The client software in Puppet nodes periodically check Puppet master server to pull resource definitions
||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
||Built on Python
||Built on Ruby and Ruby ecosystem is used to test Puppet applications
||Ansible playbooks are YAML files
||Puppet’s domain specific language is a subset of Ruby.
||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
Comparing Ansible with Chef
In this Ansible tutorial let’s look into how the tool compares with yet another CM tool called Chef.
||Seamless. What one sees on disk is what one deploys.
||Known for least maintenance
||Server and client component have to be periodically upgraded
||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
||Simplest CM tool
||Relatively sophisticated CM tool
Various concepts of Ansible
Let’s get a good grounding on various key concepts of Ansible.
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.
Ansible comes with a number of modules that can be executed directly on remote hosts or through playbooks. Modules can be written by users. 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. 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. The difference here is that here the command is run on the shell on the remote node. The setup module in Ansible is called automatically by playbooks to gather variables about remote hosts which can be used in playbooks. 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.
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.
There areplethora of commands in Ansible but we’ll just give you a sample of a generic command.
$ ansible <group> -m <module> -a <arguments>
The above command is the syntax of complete command. In place of<group> we can either use a single host or all. <arguments> are optional to provide.
When you want to omit a step on a host then this command is used. While installing certain packages can be skipped as per certain conditions or cleanup processes can be coded when the filesystem is getting full. It is easy to accomplish in Ansible with its when clause
Ansible code example
Name: “close down Debian flavoured systems”
command: /sbin/shutdown -t now
when: ansible_os_family == "Debian"
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 yum command which follows is enough to install Ansible.
$ sudo yum install Ansible
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.
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.
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.
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.
Script name along with a list of space-delimited arguments is taken by the script module. In path whatever local script is there, it will get transferred to the remote node and get executed.
Read the difference between Terraform and Ansible in our comparison blog on Terraform vs Ansible.
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!
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.
You can be among the elite DevOps workforce. You need only take Intellipaat’s DevOps Training!