Related terminology

The following is a brief primer on Ansible concepts to help you understand Ansible and its role in Automation Gateway.

Playbooks

Playbooks are expressed in YAML format, a simple syntax for Ansible’s configuration, deployment, and orchestration infrastructure.
They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process.
A playbook can be composed of one or more plays in a list. A play is provisioning executed from start to finish. In simple words, execution of a playbook is called a play.
The goal of a play is to map a group of hosts to some well-defined roles, represented by tasks.

Inventory files are text files that describe the connectivity details and other variables related to your servers, IP addresses, or DNS names.
The inventory file can list individual hosts or user-defined groups of hosts, and it can be specified in multiple formats (ini, json, yaml, etc.).
Dynamic inventories can get data from dynamic sources, including cloud sources such as OpenStack, AWS, DigitalOcean, Google, and OpenShift.

Roles are units of organization in Ansible that serve as the primary mechanism for breaking a playbook into multiple files, which makes them easier to reuse.
Roles are ways of automatically loading certain vars_files, tasks, and handlers based on a known file structure. Grouping content by roles also allows easy sharing of roles with other users.
Roles can be shared and pulled from Ansible Galaxy, GitHub, and similar platforms.

A collection is a bundle of Ansible content that acts as an extension to the product.
In general, a collection consists of roles, modules, and other plugins that extend Ansible’s functionality.
Collections can be as large as enabling connectivity to new, unsupported devices, or as small as a forked bugfix of a problematic module.
You can consume or share collections by interacting with Ansible Galaxy, GitHub, and similar platforms.

At a basic level, a task is the way a user creates Ansible functions, such as supplying parameters to an Ansible module.
Tasks are generally used to execute a module with specific arguments, though there are other more advanced cases for using tasks related to plugins and importing other content.
Each play contains a list of tasks. Tasks are executed in order, one at a time, against all machines matched by the host pattern, before moving on to the next task.

Handlers usually contain targets for notify directives and are almost always associated with services (for example, restart or stop).
In Ansible, a handler is similar to a task, but it runs only if notified by a task. A task fires the notification if Ansible recognizes that the task has changed the state of the system. Handlers will not run if not triggered by a task.
Several tasks may trigger the same handler, and it will run only once. Even if several tasks modify a configuration file and trigger the same handler, the service runs only once and applies all configuration changes.

Ansible variables (vars) are standard key-value pairs that can be simple scalar values (integers, booleans, strings) or complex values (dictionaries/hashes, lists) declared or used across multiple forms of content (for example, modules and playbooks).
Vars are declared values, not values that are gathered or inferred from the remote system’s current state.

Ansible modules are roughly equivalent to code functions that do one thing well, such as collecting or setting something on a remote device.
Many Ansible modules strive to be idempotent, meaning that running the module any number of times should result in the same singular outcome. However, depending on the equipment, module, and your inputs, this is not always the case.

For more detailed Ansible® information, see the official Red Hat documentation at the following links.

Red Hat® is a registered trademark of Red Hat, Inc. in the United States and other countries.

Ansible® is a registered trademark of Ansible, Inc. in the United States and other countries.

For more detailed Python 3.9 information, see the links below.

For more OpenTofu information:

The IAG open source repository is an available demo repository that shows how to use the Itential Automation Gateway docker images.