Related Terminology

Concepts and Terminology

Below is a brief primer on Ansible concepts which will 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

• Inventory files are text files which 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, OpenShift.

Roles

• 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, etc.

Collections

• A collection is a bundle of Ansible content which 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.
• A user may consume or share collections by interacting with Ansible Galaxy, GitHub, etc.

Tasks

• At a basic level, a task is a 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, however there are other more advanced cases for using tasks which are 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

• Handlers usually contain targets for notify directives, and are almost always associated with services (i.e., restart or stop).
• In Ansible, a handler is similar to a task, but it runs only if it was notified by a task. A task will fire 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. Logically, even if several tasks modify a configuration file and trigger the same handler, the service will only run once and apply all configuration changes.

Variables

• Ansible Variables (vars) are standard key-value pairs which can be simple scalar values (integers, booleans, strings) or complex values (dictionaries/hashes, lists) that can be declared or used across multiple forms of content (eg. modules, playbooks, etc).
• In this sense, vars are declared values, not values that are gathered or inferred from the remote system’s current state.

Modules

• Ansible Modules are roughly equivalent to code functions that intend to do one thing well, such as collecting or setting something on a remote device.
• Many Ansible modules strive to be "idempotent" which means 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 by no means always true.