What is Ansible? Where should I use this tool?

Ansible is an open source automation tool that was written and released by Michael DeHaan on February 20, 2012. In 2013, Ansible, Inc. (originally AnsibleWorks, Inc.) was founded by Michael DeHaan, Timothy Gerla, and Saïd Ziouani, and their intention was to commercially support and sponsor Ansible. In 2015, Ansible was acquired by Red Hat, and Red Hat supports and promotes Ansible as per the expectations of the open source community.

As of today, the Ansible control node is only available for Linux/Unix based platforms (most of the general-purpose OSs, such as Red Hat Enterprise Linux, CentOS, Fedora, Debian, or Ubuntu) and you cannot install it on Windows natively (it is possible to use Windows Subsystem for Linux or virtual machines for the same). This does not mean that you cannot use Ansible to automate your Windows operations. It is possible to use the Ansible control node on Linux and manage your Windows machines together, with other devices and platforms such as network devices, firewall devices, cloud platforms, and container platforms. There are more than 3,200 Ansible modules (as of today) available to use and, for Windows alone, there are more than 100 Ansible modules to automate Windows OS-based operations.

Ansible-Supported Windows OSs

Ansible can manage desktop OSs including Windows 7, 8.1, and 10, and server OSs including Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016, and 2019. Refer to https://docs.ansible.com/ansible/latest/user_guide/windows_setup.html#host-requirements for more details.

The community version of Ansible is free to use like other open source software, but there is also a product offering from Red Hat based on Ansible called Red Hat Ansible Automation Platform, which is available with a paid subscription. Use either the community version of Ansible or the Red Hat-supported version with a subscription. Ansible Automation Platform is for enterprise use with functionalities such as role-based access control (RBAC), graphical user interface (GUI), Application Programming Interface (API), redundancy, and scalability. Consider these options when you expand your automation use cases with a bigger team with many engineers working on automation and when you need auditing, tracing, and other integrations. Read more about Ansible Automation Platform at https://www.ansible.com/products/automation-platform.

Red Hat Ansible Automation Platform

The enterprise automation product from Red Hat was known as Ansible Tower until the announcement of the Red Hat Ansible Automation Platform in September 2019 (https://www.ansible.com/blog/introducing-red-hat-ansible-automation-platform). The components inside Ansible Automation Platform were renamed with more meaningful names, such as automation controller and execution environment. Read more about Ansible Automation Platform at https://www.redhat.com/en/technologies/management/ansible.

Ansible documentation is available at https://docs.ansible.com.

Prerequisites

We will write automation steps in a YAML file called an Ansible playbook. Ansible will parse the playbook file and execute the tasks on target machines:

• You should know the basics of Linux; as I mentioned earlier, it is possible to install Ansible on a Linux or Unix machine only at the current time. That does not mean that you should be a Linux subject matter expert, but you need to be able to handle basic operations in Linux, such as file management and file editing.
• You need to understand the YAML syntax, which is easy, as YAML is one of the easiest human-readable file formats.

Ansible is based on the Python programming language, but you don't need to learn Python or any kind of programming language to develop Ansible automation playbooks.

What is YAML?

YAML Ain't Markup Language (YAML) is a human-readable language format used for most modern tools and software, including Ansible, Kubernetes, and OpenShift. YAML is often used as a file format for application data and configuration, for example.

Ansible control node requirements

There are no specific hardware requirements for the Ansible control node machine. It is possible to use a machine with 512 MB memory and one virtual central processing unit (vCPU). Follow some standard virtual machine (VM) specifications, such as 4 GB or higher, as you may need more memory when you have more managed nodes and more tasks to run in parallel. For the disk, you may follow standard VM specifications, as Ansible is a small program and does not require much disk space. Use any Linux/Unix machine with Python 3.8 or newer installed.

Ansible Control Node Requirements

Find the Ansible control node requirements at https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#control-node-requirements.

Ansible managed node requirements

The target nodes (managed nodes) should be installed with Python 2.6 or later (3.x is recommended) to execute the task. For Windows machines, you need to install PowerShell and .NET.

Ansible is also supported for the following:

• Network devices
• VMware
• Public clouds such as AWS, Azure, and GCP
• Security devices

Python 2.x EOL

Install Ansible on a machine with Python 2.x, but Python 2.x is already end-of-life (EOL) by January 1, 2020, and it is best practice to use the latest Python version. For more detailsabout Python 2 end of life, visit https://www.python.org/doc/sunset-python-2/.

Ansible is agentless

There are two types of machines involved in Ansible automation. The machine in which you install the Ansible program is known as the Ansible control node. The control node can be any machine, a dedicated server, or even your workstation, and it will have your Ansible playbook and other configurations. Then, the machines or devices that you want to automate are known as managed hosts. You will run the Ansible jobs and playbooks from the control node and the jobs will be executed on the target nodes or managed nodes.

The following diagram shows the basic components of Ansible:

Figure 1.1 – Ansible and components

Ansible is agentless and you do not need to install any kind of agents on the managed nodes. Ansible uses default connection methods to communicate with managed nodes, such as ssh, WinRM, http, or other appropriate protocols. During the onboarding, you need to configure the credentials for the managed nodes, such as an SSH credential, with SSH keys, or an SSL certificate for WinRM connection. This is a one-time setup, and it is possible to configure or change this anytime. It is possible to use the same or different credentials for different managed nodes, and configure this for individual nodes or a group of managed nodes. You will learn about managed nodes and inventory in the next sections of this chapter.

Ansible architecture

The following diagram shows the Ansible internals and its components' structure:

Figure 1.2 – Ansible and components

Ansible inventory

The Ansible inventory is a file or script that will provide the details about the managed nodes, including the hostname, connection methods, credential to use, and many other details. It is possible to pass the inventory to Ansible using static inventory files, dynamic inventory scripts, or using the configuration management database (CMDB). The CMDB is the same CMDB that can provide the managed nodes information. It is best practice to integrate CMDB with Ansible in an environment to avoid frequent updates on the static inventory files, but this is not a mandatory component.

It is possible to add any number of managed nodes inside the inventory file, as follows:

Figure 1.3 – Ansible inventory with managed nodes

It is best practice to separate the managed nodes information in multiple inventory files based on the criticality, server types, and environment. You will learn more about inventory best practices in Chapter 16, Storing Remote Host Information – Inventory Best Practices.

Dynamic inventory plugins will collect the details of managed nodes from your virtualization platforms such as VMware, OpenStack, AWS, Azure, and GCP, or from other container platforms such as Kubernetes. There are more than 40 dynamic inventory plugins available to use in the Ansible GitHub repository. Use them if needed or create your own dynamic inventory scripts if those are not suitable for your requirements.

Ansible Dynamic Inventory

For more details about the Ansible dynamic inventory, look it up at https://docs.ansible.com/ansible/latest/user_guide/intro_dynamic_inventory.html and https://github.com/ansible/ansible/tree/stable-2.9/contrib/inventory.

Ansible plugins

Ansible plugins are small pieces of code that help to enable a flexible and expandable architecture. You have Ansible executable, and add plugins as needed for other features and capabilities like any other software. There are different types of plugins in Ansible such as connection plugins, action plugins, become plugins, and inventory plugins. For example, the default connection plugin you will be using is called ssh, and it is possible to use connection plugins called docker or buildah for connecting to containers. If you need to, install and use these plugins.

Ansible Plugins

Read more about Ansible plugins at https://docs.ansible.com/ansible/latest/plugins/plugins.html.

Ansible modules

An Ansible module is a piece of reusable and standalone script that can be used to achieve some specific tasks. Modules provide a defined interface with options to accept arguments and return information to Ansible in JSON format. When you execute a task using a module, the module script will be executed on the target machine using Python or using PowerShell for Windows machines.

For example, the following Ansible content is using a ping module to verify the connectivity to the target machine and another task with the yum module for installing httpd package on a managed node using the yum package manager:

Figure 1.4 – Ansible ping module and yum module

I said earlier that we can automate network devices and firewall devices using Ansible, but, we all know that we cannot install Python or PowerShell on those devices. Unlike most of the Ansible modules, network modules do not run on network devices. Instead, these modules will be executed from the Ansible control node itself and run the appropriate commands on target network devices to achieve the task. From the user's point of view, there is no difference in the execution of network modules as you still use them like any other modules. It is possible to manage the network devices like other Linux machines and Windows machines but with different connection methods, such as network_cli, netconf, and httpapi.

Read: How Network Automation Is Different

Go to https://docs.ansible.com/ansible/latest/network/getting_started/network_differences.html to learn more about network device automation.

Ansible content collections

Before version 2.10, Ansible was a big package with all modules and libraries inside, but the community grew very fast and thousands of new modules were contributed to Ansible. Whenever there is a new module or new version of a module available from the community or vendors, then users need to wait for the next release of Ansible to get the updated module. To resolve this dependency, a new way of distribution has started in which Ansible modules are separated from the Ansible base and distributed as Ansible content collections, or simply Ansible collections. You have the choice of installing Ansible alone or installing the Ansible package including Ansible collections. If you need to manage some different set of nodes or systems (for example, managing the VMware private cloud or automating Fortigate firewall devices), then install the required Ansible collection and use it. This modularity allows you to install only the required modules and plugins rather than all available modules.

The following diagram shows the transition of the Ansible collection from old Ansible:

Figure 1.5 – Ansible to Ansible core and Ansible collection transformation

Also, note some of the changes in the Ansible base and Ansible collection restructuring:

• Before version 2.9.x: The package included ansible and all the Ansible modules and other plugins.
• From version 2.10++: Ansible was renamed to ansible-base and modules were moved to Ansible collections (vendors and communities).
• From version 2.11++: ansible-base was renamed to ansible-core.
• When you install Ansible 3.x or Ansible 4.x, then you are installing the Ansible community package, which includes ansible-core and all the Ansible collections (vendor and community).

Restructuring the Ansible Project 

Read the blog post ansible.com/blog/thoughts-on-restructuring-the-ansible-project and ansible.com/blog/the-future-of-ansible-content-delivery to know more about Ansible collection transition. 

Ansible playbook

The Ansible playbook is a simple file written in YAML format with the instruction list of automation tasks. The following diagram explains the components, syntax, and structure of an Ansible playbook:

Figure 1.6 – Ansible playbook basic components

Each task in the play runs a module to do some specific job on the target node. You can have multiple tasks in a play and multiple plays inside a single playbook, as shown in the diagram. The plays, tasks, and module arguments are identified by the indentation in YAML format. In this example, we have a playbook with two plays.

In the first play, Enable Intranet Services, we are running the tasks against node1 – see the hosts: node1 line.

Under the tasks, see two tasks:

• The first task is using the yum module and installing the httpd package.
• The second task is using the service module to start the httpd service.

Then, we have a second play, Test intranet web server, in the playbook, in which you have only one task:

• Using the uri module to test the intranet web server

Ansible will parse this playbook and execute the tasks one by one on the target nodes.

Ansible use cases

It is possible to build, manage, or maintain almost all components in IT infrastructure using Ansible:

• Servers and storages
• Network devices, firewalls, software-defined networks (SDNs), and load balancers
• Application components
• Containers and container platforms
• Database applications
• Public cloud and private cloud

You need to find the use cases from your day-to-day work and find the highest number of tasks you are repeating every day and consider those tasks as automation candidates. The following is a sample list of such use cases:

• OS patching
• Application and package deployment
• Orchestration of application
• Configuration management
• Infrastructure provisioning
• Continuous delivery
• Security and compliance auditing and remediation
• Database provisioning and management

In the following section, we will learn how to install and configure Ansible.