What is Ansible?
Ansible is a tool developed by our beloved Red Hat to automate lots of stuff around infrastructure. There’s lot of magic that has been put into in the form of code which enables ansible do stuff quite seamlessly.
However, mostly Ansible is being used for configuration management of devices in cloud and network infrastructure. So it’s in a neck to neck competition with Terraform. Both tools has similar properties like being agentless, which means you don’t need to install a piece of software called an agent on the devices you want to manage using Ansible/Terraform.
There’s a lot of debate going on whether Ansible is declarative like Terraform or not. In my opinion, it’s more of a mixture of declarative and procedural method. Declarative because you tell ansible what to do not how to do it, the “how” part, it’ll figure out itself, Procedural because it uses a procedural way to reach the desired outcome.
it’s coded in Python and only can be run on a Linux OS distribution. Although, Windows users can use WSL and WSL2 to run Ansible pretty smoothly and of course it’s Open Source!!!
Concepts of Ansible
There are multiple concepts associated with Ansible which acts as the foundation of this config management tool.
Playbooks represents the lists of tasks which are declared by the user for Ansible to execute. These tasks consist of different modules which signifies the actual change that Ansible will be implementing on the target infrastructure. YAML is the language in which you can write your playbooks and the syntax is pretty cool and easy to understand.
Tasks in a playbook represents the operations Ansible will perform. It can be gathering some information from a set of servers in the cloud or creating a VLAN in a network switch or configuring a rule in the firewall.
Modules in my opinion are different set of codes created to do different kinds of tasks. For example, if you want to create/remove/update a VLAN in a Cisco IOS device, then you would use the module “cisco.ios.ios_vlans” in your playbook.
Inventory gives Ansible the list of nodes to be managed. It’s the file where you define the IP Address or FQDN of the devices you want Ansible to talk to and executes the defined tasks. It can be of several formats, most commonly used are YAML and INI. As it contains information on the hosts, it sometimes also called the hostfile. You can define the hosts in a group as well for example, you want a set of Routers at one DC to be in one group or a set of webservers in one group and set of DB servers in other.
This would help you segregate the hosts and associate them with relevant tasks in the playbook. Another use of Inventory file is to define variables.
Variables and reusability goes hand in hand in Ansible. You can use same playbooks on several different systems with the help of variables. These variables can be defined in the Inventory file, roles, in command line or even can use an external excel file to input variables to different parameters defined in a module. For example, you can define multiple values to a variable called VLAN and then call it in a relevant module where VLAN input is required.
Ansible reads the variable and apply it according to the variable precedence rules.
Roles is another important concept of ansible which enables the users to reuse the playbooks. With a defined directory structure, Ansible loads the specified variables, tasks, handlers and values from the YAML files. Each directory must have the “main.yml” file which has the relevant details as per the directory it resides in.
Defaults: This directory is for defining the default value of the variables to be used in the playbooks. This comes into play when there is no value of variable explicitly defined, so default value will be used.
Files: This directory can contain the files required for executing the desired task to get to target state. For example, if you want to install a particular software on your webservers using Ansible, then that installer file can be stored here, So Ansible can look for it.
Handlers: Handlers are a form of tasks that can be invoked during the playbook execution. The directory can have limitless number of handlers as per the requirement.
Meta: This directory stores the metadata for the role. This helps when you want to publish your role on Ansible Galaxy. So you would need to define the ownership, dependencies and supported platforms.
Tasks: As the name suggests, it stores the list of tasks to be executed by the role.
Templates: Template directory is use to store templates which supports modification and mostly Jinja2 is being used as a templating language.
Tests: This directory can used if you have defined a testing process in accordance with the role. This directory further has an inventory and a test.yml file. For example, you want to execute some “show” commands on a Cisco IOS router after deploying some configuration on it using the role, then you can include those commands in the test.yml and execute it.
Vars: It contains the variables to be used by the role. The variables defined in this directory overrides the one’s defined in “defaults” directory. In simple terms: If x has a default value as 10 in “defaults” directory and same “x” is then defined in “Vars” directory with the value of 20, then the value 20 overrides the value 10 in the Role.
Lastly, Ansible Galaxy is a collection of defined roles and playbooks where you can just go in and use any roles with respect to your requirement. Saves lots of time and effort! I would encourage you to visit it.
