Understanding the Fundamentals of Ansible

At its heart, Ansible is a simple framework that pushes a small program called an Ansible module to target nodes. Modules are at the heart of Ansible and are responsible for performing all of the automation’s hard work. The Ansible framework goes beyond this, however, and also includes plugins and dynamic inventory management, as well as tying all of this together with playbooks to automate infrastructure provisioning, configuration management, application deployment, network automation, and much more, as shown:

Figure 2.1 – The typical flow and usage of Ansible’s automation engine

Even with the addition of Ansible collections since the previous release of this book, this architecture remains unchanged – now, the modules, plugins, and dynamic inventory scripts are simply distributed through collections whereas before everything was distributed as part of the Ansible release itself.

...

Technical requirements

This chapter assumes that you have successfully installed the latest version of Ansible (8.0 with ansible-core 2.15, at the time of writing) on a Linux node, as discussed in Chapter 1, Getting Started with Ansible. It also assumes that you have at least one other Linux host to test the automation code on. The more hosts you have available, the more you will be able to develop the examples in this chapter and learn about Ansible. SSH communication between the Linux hosts is assumed, as is a working knowledge of them.

The code bundle for this chapter is available at https://github.com/PacktPublishing/Practical-Ansible-Second-Edition/tree/main/Chapter%202.

Getting familiar with the Ansible framework

In this section, you will learn how the Ansible framework fits into IT operations. We will explain how to run Ansible for the first time. Once you understand this framework, you will be ready to start learning about more advanced concepts, such as creating and running playbooks with your own inventory.

In order to run Ansible’s ad hoc commands via an SSH connection from your Ansible control machine to multiple remote hosts, you need to ensure you have the latest Ansible version installed on the control host. Use the following command to confirm the latest Ansible version:

$ ansible --version
ansible [core 2.15.0] (2.15 82b47c8d5c) last updated 2023/05/19 15:21:43 (GMT +000)
  config file = None
  configured module search path = ['/home/james/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/james/ansible-2.15/ansible/lib...

Exploring the configuration file

Ansible’s behavior is, in part, defined by its configuration file. The central configuration file (which impacts the behavior of Ansible for all users on the system) can be found at /etc/ansible/ansible.cfg. However, this is not the only place Ansible will look for its configuration; in fact, it will look in the following locations, from the top to the bottom.

The first instance of the file is the configuration it will use; all of the others are ignored, even if they are present:

• ANSIBLE_CONFIG: The file location specified by the value of this environment variable, if set
• ansible.cfg: In the current working directory
• ~/.ansible.cfg: In the home directory of the user
• /etc/ansible/ansible.cfg: The central configuration that we previously mentioned

If you installed Ansible through a package manager, such as dnf, yum, or apt, you will almost always find a default configuration file called ansible.cfg in /etc/ansible...

Command-line arguments

In this section, you will learn about the use of command-line arguments for playbook execution and how to employ some of the more commonly used ones to your advantage. We are already very familiar with one of these arguments, the --version switch, which we use to confirm that Ansible is installed (and which version is installed).

Just as we were able to learn about the various configuration parameters directly through Ansible, we can also learn about the command-line arguments. Almost all of the Ansible executables have a --help option that you can run to display the valid command-line parameters. Let’s try this out now:

1. You can view all the options and arguments when you execute the ansible command line. Use the following command:

   $ ansible --help

You will see a great deal of helpful output when you run the preceding command; a snippet of this is shown in the following code block (you might want to pipe this into a pager, such as less...

Understanding ad hoc commands

We have already seen a handful of ad hoc commands so far in this book, but to recap, they are single tasks you can run with Ansible, making use of Ansible modules without the need to create or save playbooks. They are very useful for performing quick, one-off tasks on a number of remote machines or for testing and understanding the behavior of the Ansible modules that you intend to use in your playbooks. They are both a great learning tool and a quick and dirty (because you never document your work with a playbook) automation solution.

As with every Ansible example, we need an inventory to run against. Let’s reuse our production-inventory file from before:

[frontends_na_zone]
frontend1-na.example.com
frontend2-na.example.com
[frontends_emea_zone]
frontend1-emea.example.com
frontend2-emea.example.com
[appservers_na_zone]
appserver1-na.example.com
appserver2-na.example.com
[appservers_emea_zone]
appserver1-emea.example.com
appserver2-emea.example...

Understanding Jinja2 filters

As Ansible is written in Python, it inherits an incredibly useful and powerful templating engine called Jinja2. We will look at the concept of templating later in this book, so for now, we will focus on one particular aspect of Jinja2 known as filtering. Jinja2 filters provide an incredibly powerful framework that you can use to manipulate and transform your data. Perhaps you have a string that you need to convert into lowercase, for example—you could apply a Jinja2 filter to achieve this. You can also use it to perform pattern matching, search and replace operations, and much more. There are many hundreds of filters for you to work with, and in this section, we hope to empower you with a basic understanding of Jinja2 filters and some practical knowledge about how to apply them, as well as showing you where to get more information about them if you wish to explore the subject further.

It is worth noting that Jinja2 operations are performed on...

Summary

Ansible is a very powerful and versatile automation engine that can be used for a wide variety of tasks. Understanding the basics of how to work with it is of paramount importance, before addressing the more complex challenges of playbook creation and large-scale automation. Ansible relies on a language called YAML, a simple-to-read (and write) syntax that supports the rapid development of easy-to-read and easy-to-maintain code and inherits a number of valuable features from the Python language that it is written in, including Jinja2 filtering.

In this chapter, you learned the fundamentals of working with various Ansible programs. You then learned about the YAML syntax and the ways that you can break down your code into manageable chunks to make it easier to read and maintain. We explored the use of ad hoc commands in Ansible, variable definition and structure, and how to make use of Jinja2 filters to manipulate the data in your playbooks.

In the next chapter, we will...

Questions

1. Which component of Ansible allows you to define a block to execute task groups as a play?
   1. handler
   2. service
   3. hosts
   4. tasks
   5. name
2. Which basic syntax from the YAML format do you use to start a file?
   1. ###
   2. ---
   3. %%%
   4. ===
   5. ***
3. True or false – in order to interpret and transform output data in Ansible, you need to use Jinja2 templates.
   1. True
   2. False

Further reading

To find out about more configuration variables, go to https://docs.ansible.com/ansible/latest/reference_appendices/config.html#ansible-configuration-settings.