Ansible Automation

Ansible is an open-source automation tool that enables businesses to automate a range of IT processes, including orchestration, application deployment, and configuration management. It automates the processes necessary to get the system to the desired condition by using YAML, a basic yet effective syntax.

The simplicity of Ansible is one of its main advantages. Ansible does not require any agents or specialized software to be installed on the controlled systems, in contrast to other automation solutions. Instead, it communicates with the controlled systems via the widely used Secure Shell (SSH) protocol. This decreases the effort required to set up and manage the automation infrastructure and makes it simple to get started with Ansible.

The modular structure of Ansible is another advantage. Using reusable components known as modules, Ansible may be used to carry out certain tasks like managing packages, users, or services. Even the most complicated IT processes can be automated with ease thanks to the ability of these modules to be coupled to create increasingly sophisticated automation scenarios.

Automation with Ansible

Additionally, Ansible supports a variety of operating systems, including Linux, Windows, and macOS, as well as a number of cloud computing services, including Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). It may therefore be used to automate operations in a number of situations, making it a flexible tool.

Roles, playbooks, and inventories are just a few of the numerous management and organization capabilities offered by Ansible. You can share and reuse automation tasks more easily across your business by using roles to group your automation activities into reusable components. Inventories are used to maintain the list of systems that Ansible should manage, while playbooks are YAML files that specify the automation activities that Ansible should carry out.

Ansible uses YAML (Yet Another Markup Language), a human-readable data serialization language, to specify the ideal state of a system. Indentation and white space are used in YAML to denote the data structure, which makes it simple to read and write.

Here is an illustration of a fundamental Ansible YAML structure.

---
# This is a comment in YAML
# A YAML document starts with '---'

# A key-value pair in YAML
key: value

# An array in YAML
array:
  - item1
  - item2
  - item3

# A dictionary in YAML
dictionary:
  key1: value1
  key2: value2
  key3: value3

Tasks, playbooks, and variables are defined in YAML while using Ansible. For instance, a playbook is a YAML file that lists the actions that Ansible should carry out and defines each job as a dictionary in YAML. It's critical to remember that YAML is sensitive to indentation and white space.

As an illustration, the following YAML code might result in a mistake:

# Incorrect YAML structure array: - item1 - item2 - item3

This error can be fixed by correctly indenting the items in the array.

# Correct YAML structure
array:
  - item1
  - item2
  - item3

In conclusion, YAML is a popular data serialization format in Ansible for defining the intended state of a system. It is straightforward yet incredibly effective. For Ansible to be used properly, it is crucial to comprehend the fundamental YAML structure.

In Ansible, either .yaml or .yml can be used to define playbooks, tasks, and variables. For example, you could have a playbook with the name example.yaml or example.yml, and both would work the same way in Ansible.

It's a common convention to use the .yml extension for YAML files, as it is shorter and easier to type. However, some organizations prefer to use .yaml for consistency with other YAML-based tools or to make it clear that the file contains YAML data.

Regardless of the extension used, it's important to remember that the structure and format of the YAML file are what matter, not the file extension.

Prerequisites to Ansible

There are a few prerequisites that you must have in place before using Ansible:

A control machine is the computer on which Ansible is set up and from which you execute playbooks and instructions. Any computer running Windows, Mac OS X, or Linux can serve as the control machine. The computers that you wish to use Ansible to control are known as target machines. They might be cloud instances, virtual computers, or real servers. SSH daemons should be operating on the target computers, and the control computer should be able to connect to them. Python: Python 2.7 or above must be installed on both the control system and the target machines in order for Ansible to function. SSH Access: Since Ansible utilises SSH to connect to the target computers, you must set up passwordless SSH access between the control machine and the targets. Inventory: Ansible records information about the target computers, including their IP addresses and SSH credentials, in an inventory file.

Ansible may be installed on the control computer and used to automate your infrastructure once you've completed these requirements. The fact that Ansible is designed to be a straightforward and user-friendly tool means that there isn't much of a learning curve when getting started with it, which is another crucial thing to keep in mind.

Ansible terms include

Control Node/Machine

The computer on which Ansible is installed and from which all tasks and playbooks will be executed is known as the Ansible server.

Module

A module is essentially a command or group of related instructions intended to be performed on the client-side.

Task

A task is a part with only one operation that has to be finished.

Roles

Organizing tasks and related files in a way that may be used later in a playbook.

Facts

Information obtained by the gather-facts method from the global variables on the client system.

Inventory

File holding information about the Ansible client/worker node server details.

Handler

Task that is only called if a notifier is present is a handler.

Notify

If the output is altered, the section associated with the job that called the handler will notify you.

Playbook

It is made up of YAML-formatted code that lists the actions to be taken.

Worker Nodes: Nodes that an Ansible server automates.

Control Node

The Control Machine in Ansible is the machine where Ansible is installed and where you run your playbooks and commands from. It acts as the central management point for Ansible, and it communicates with the target machines to execute tasks and deploy configurations.

The Control Machine is responsible for executing Ansible playbooks and sending commands to the target machines. It also stores the Ansible configuration files, playbooks, and inventory, and it acts as the central repository for all your Ansible-related data.

The Control Machine can be any system that runs Linux, macOS, or Windows, as long as it has Python 2.7 or higher installed. Once you have installed Ansible on the Control Machine, you can use it to manage and automate your infrastructure, whether it consists of physical servers, virtual machines, or cloud instances.

Worker Nodes

Worker nodes, also known as target machines, are the systems that Ansible manages and automates. These are the systems that you want to configure, deploy, and manage with Ansible. Worker nodes can be physical servers, virtual machines, or cloud instances.

In Ansible, the worker nodes are specified in an inventory file, which is a list of target machines and their associated information, such as IP addresses and SSH credentials. The Control Machine communicates with the worker nodes through SSH to execute tasks and deploy configurations.

Worker nodes are the systems that actually perform the tasks defined in the Ansible playbooks. For example, if you have a playbook that installs and configures a web server, the worker nodes are the systems where the web server will be installed and configured.

In a large infrastructure, there may be hundreds or even thousands of worker nodes, and Ansible provides a way to manage them all from a single control machine. This makes it easier to automate and manage your infrastructure, as you can perform tasks and deployments across your entire infrastructure from a single location.

In summary, worker nodes are the systems that Ansible manages and automates, and they play a key role in Ansible's infrastructure automation. By specifying the worker nodes in the inventory file, you can use Ansible to perform tasks and deployments across your entire infrastructure, making it easier to manage and automate your systems.

Inventory

In Ansible, the inventory is a file that lists the target machines (also known as worker nodes) and their associated information, such as IP addresses and SSH credentials. The inventory is used by Ansible to keep track of the systems that it manages and automates.

Ansible uses the inventory to determine which target machines to connect to, and it also uses the information in the inventory to configure and deploy software to the target machines. The inventory is an essential component of Ansible, as it acts as the centralized repository of information about the target machines.

The inventory can be in the form of a simple text file, or it can be a more complex data structure, such as a dynamic inventory that is generated using a script. In either case, the inventory file must be in a specific format that Ansible can understand.

The default location of the Ansible inventory file is typically /etc/ansible/hosts on Linux systems. However, you can specify a different location for the inventory file by using the -i or --inventory option when running Ansible commands or playbooks.

Two categories of inventory files exist:

1. Static inventory entails adding hosts by hand. 2. Scripts are used in dynamic inventory to add hosts to an inventory.

For example, to specify a different location for the inventory file, you could run a command like this:

ansible-playbook -i /path/to/inventory playbook.yml

This would run the playbook playbook.yml using the inventory file located at /path/to/inventory.

$ vi hosts
[groupname]
<alias-name> <IP/FQDN> <USER> <PASSWD>

[demo] node1 ansible_host=172.31.35.52 ansible_user=ubuntu ansible_ssh_private_key_file=/etc/ansible/master.pem

[local] master ansible_host=172.31.42.167 ansible_user=ubuntu ansible_ssh_private_key_file=/etc/ansible/master.pem

Using inventory, the master node communicates with multiple worker nodes through SSH.

Installation

Installing Ansible is relatively straightforward and can be done on a variety of operating systems, including Linux, macOS, and Windows. In this section, I will provide an overview of the installation process for Linux systems.

To install Ansible on a Linux system, you first need to install the necessary dependencies, such as Python and pip.

Ansible Master-Node Setup

Master Machine: (Debian Based Machines)
$ apt update
$ apt install -y ansible

Master Machine: (RHEL Based Machines)
$ yum update
$ yum install -y python3 ansible

Node Machine: (Debian Based Machines)
$ apt update
$ apt install -y python3

Node Machine: (RHEL Based Machines)
$ yum update
$ yum install -y python3

Configuration File

The filename must be ansible.cfg.

Ansible checks the configuration file's location in the following order, with the first one given top consideration: 1. The directory from which you are currently performing the playbook or ad-hoc command. 2. The user's home directory. 3. /etc/ansible/ansible.cfg is the default location.

host_key_checking = false

The host_key_checking configuration setting controls whether Ansible should check the host key of target machines before connecting to them. By default, Ansible will check the host key of the target machines and reject the connection if the host key is not recognized.

Setting host_key_checking to false disables this host key checking, allowing Ansible to connect to target machines without checking their host key. This can be useful in certain scenarios, such as when you are setting up a new environment and you have not yet established the host keys for the target machines.

However, disabling host key checking can also be a security risk, as it allows Ansible to connect to target machines without verifying their identity. This can result in man-in-the-middle attacks, where an attacker intercepts and redirects the connection to a different machine, allowing them to steal sensitive information or inject malicious code.

For this reason, it is generally recommended to only disable host key checking in trusted environments and to re-enable host key checking as soon as possible.

You can configure the host_key_checking setting by adding the following line to your Ansible configuration file (ansible.cfg):

host_key_checking = false

To disable strict host key checking for an individual SSH connection, you can pass extra arguments:

ansible-playbook -i inventory -o StrictHostKeyChecking=no playbook.yml

You can also specify the StrictHostKeyChecking=no option in the inventory file by adding the following line:

ansible_connection=ssh
ansible_user=<username>
ansible_ssh_common_args='-o StrictHostKeyChecking=no'

This tells Ansible to use the SSH connection and to pass the -o StrictHostKeyChecking=no option to the SSH command for all hosts in the inventory file.