As we have always witnessed the ever-increasing dependency on technology, we have seen the need of organizations grow from a couple of servers to datacenter’s running operating systems and hundreds of software on thousands of servers. There are storage, network, and whatnot. There is complexity, confusion and even a small mistake can lead to a massive disaster and outage of business-critical applications. System Operations had become a challenge and admins had to manage all the responsibilities such as install OS and applications, configure them and even maintain them. Applications often required updates and patching. Sometimes a new update also required the admins to install new version of the respective environments. Imagine all this being done manually on a large scale. Operations team ranging from a dozen to a few hundred engineers had to work around the clock to make everything run smoothly.
There was a demand for a tool that could ease some burden from the shoulders of the engineers. There were a few solutions, some of them were proprietary and expensive while others that were free had a limited scope.
Ansible is open source and very powerful software that helps system engineers to automate, patch, install and orchestrate various applications and tasks irrespective to the size of the infrastructure. It works with everything from Windows to Linux and Mac, it can be used with VMware or Docker, be database or storage and even networking appliance, IoT, machine learning, artificial intelligence, deep learning and you name it. It’s very flexible, simple and compact yet it’s extremely efficient. It provides consistency, scalability, and reliability to any given infrastructure. It’s everything the industry needed.
Ansible was developed by Michael DeHaan and was released on 20th Feb 2012 and the first commercial release of Ansible in the same year. Ansible comes with pre-loaded multiple built-in modules also known as core modules.
Let’s dive in and explore the components of Ansible. By first installing Ansible.
Some important features of Ansible:
Setup – as in the above video we have seen Ansible as a very lite weight application, it’s installation is very simple. The only thing we should care for is that Python is pre-installed on the system before installing Ansible.
Python – Ansible is built on top of Python, which is one of the most robust, simple and demanded programming languages of the day.
Agent-less – Ansible is not dependent on any agent that’s supposed to be installed on the destination nodes. Other solutions depend on agents which include popular tools such as Chef and Puppet.
SSH – Ansible uses SSH to perform automated tasks on the destination nodes. It supports passwords base and passwordless authentication to initiate SSH connectivity. In most cases password less authentication is implemented, in such implementations, the keys have to be exported to the respective nodes and a special user account is to be created for performing administrative tasks that will be used by Ansible.
Push architecture – Ansible has a “Push Architecture”, which means that an Ansible Admin has to write a playbook in YAML and push the task at once to the nodes. The playbook contains a list of tasks. Task can be a configuration change, software installation activity, patching, backup, etc.
The Ansible Architecture
Ansible Inventory File
Ansible can handle multiple nodes of your infrastructure simultaneously. To find the nodes of a particular group or properties such as user credentials or the keys used for authentication for a specific node, Ansible depends on its inventory file. Ansible inventory is an organized collection of connection information for Ansible nodes which are managed by Ansible Master Server. Some of the most common Ansible Variables are listed below and you would see them being used in most scenarios.
ansible_host it is either hostname or IP address of the nodes managed by Ansible.
ansible_port it is the port used by a node for SSH connections.
ansible_user it is the user on the remote node that should be used by Ansible for SSH connection
Ansible_ssh_pass it is the user password that Ansible should use for SSH authentication
ansible_ssh_private_key_file it is used to describe the specific key used to initiate SSH connection with the Ansible node.
The default location of the Ansible Inventory file is /etc/ansible/hosts. Sometimes, the inventory file is also known as Ansible hosts file. We also have the option for creating custom multiple inventory files. These custom inventory files can be stored in any directory.
Ansible Configuration File
Some settings, that define the behavior of Ansible, can be changed. Ansible’s configuration file is a collection of such setting. These settings are saved in a key-value pair in the configuration file. The file is default located in /etc/ansible is named as ansible.cfg
Ansible can have multiple configuration files. Since, Ansible is used by all departments such as database, networking, system admins, storage, etc. they all need their own individual configuration files.
A playbook is an organized list of scripts that define the configuration changes for the Ansible nodes. Playbooks are the core components for the Ansible’s configuration management. An Ansible playbook may contain one or multiple tasks, and every task performs a defined specific action. This list of tasks is sequential and every single task is also known as ‘Play’. Plays in Ansible’s playbook are defined in YAML. Ansible does not provide any default or sample playbooks. Playbooks are written manually by admins and engineers according to their needs.
Ansible Modules are very small programs that are sent through SSH to Ansible Nodes and then executed on the destination nodes. Hence, Ansible has a push architecture, where modules carry configuration management parameters to the destination nodes. Due to this property, admins can send new configurations and updates on destination nodes whenever they need to. Other configuration management products in the market are not based on this principle of push architecture. For example, tools such as Chef and Puppet are based on Pull architecture, where the node pulls the configuration changes from the server and to do so an agent software is needed on the destination nodes. Ansible is thus agentless.
In Ansible, we have custom and core modules.
Core Modules are the ones which are provided by default with Ansible. These are maintained by the Ansible Team and will always be shipped with Ansible. The core modules also receive slightly higher priority than the ones listed in ‘extras’ repo.
Custom Modules are the ones that we can develop as per our requirements. Developing custom modules for Ansible is easy. But if we need to develop a required module, we should always first check if a core module with similar or same functionality already exists in any core module provided by Ansible. Ansible has thousands of core modules
Like most other tools, Ansible also provides a Command Line Interface to interact with it. The simplest way to use Ansible is with the Ad-Hoc Commands. There is one more way to use Ansible and that is with the help of Playbooks. Anyways, both the ways of using Ansible are easy for anyone to learn.
Ad-Hoc commands are the simplest way to use Ansible. It can be used if you want to make Ansible execute a command on a remote server or a bunch of them. Ad-Hoc commands are not stored on Ansible master for future use. They simply provide a faster way to use Ansible.
The playbook is a sequential collection of play. Every play is a task that we want Ansible to perform on the destination nodes. A play can be any task, such as taking a backup, creation of exceptions in the firewall or creating users and groups and many more things you can think of. Playbooks are written in YAML. Hence, there is the very little syntax, but we need to care for indentation. Playbooks offer increased flexibility, simplicity and are intended for use in extremely complex scenarios. Ansible Playbooks are stored on Ansible master and an administrator does not need to write a Playbook every time he needs to use one.
Ansible’s Python API
Ansible can be used in many different ways from API perspective. Ansible’s Python API can be used for many different things such as we can write new plugins, add information to inventory dynamically from external sources, respond automatically to various Python events, control and configure nodes, etc.
Ansible is one damn small configuration management tool available out there that eases the huge burden which pressed down the administrators, developers and other engineers with the never-ending counts of repeating tasks that increased with time and machines. Ansible automated everything from storage to servers, networking and virtualization, and everything else you think off.
I hope my blog provided an insight to the fundamental architecture of Ansible and it let you explore some of the important components of Ansible. If you found this blog informative and useful, please comment in the comments area below. I will present a new subject in a new blog shortly. Thanks for your time and Goodluck in your Ansible Automation. Automate Everything…
Call the Trainer and Book your free demo Class for now!!!
© Copyright 2019 | Sevenmentor Pvt Ltd.