The Itential Automation Gateway (previously known as Itential Ansible Manager) is a stand-alone user interface that "sits on top" of Ansible®, an open source platform from Red Hat® that manages machines over the SSH protocol. Red Hat Ansible is a popular choice for IT automation, configuration management and provisioning. Unfortunately, out of the box, Ansible lacks a programmable interface and has a very abstract concept of inventory. Automation Gateway aims to solve these constraints by providing a simple REST API and a standardized inventory concept.
This guide introduces the Automation Gateway along with installation and configuration, and provides information on how to enhance an existing schema for a Module, Role or Playbook. You will also discover how to interact with API definitions through an interactive API documentation UI.
Key Features of Automation Gateway
Automation Gateway is a robust, standalone application that runs as its own process. It provides a REST interface that is able to:
- Discover and execute the network family of Ansible modules.
- Discover and execute Red Hat certified Ansible roles.
- Discover and execute any Ansible playbook.
- Access and update Ansible hosts (inventory).
As a network automation solution, Automation Gateway:
- Uses the Ansible Runner python libraries to execute modules.
- Returns discovered elements as JSON-Schema models.
- Secures access via presentation of user/password credentials.
- Supports both HTTP and HTTPS protocols for client/server communication.
- Allows two options (internal or external) for managing device inventory.
- Provides a stateless server and has no requirements on redundancy roles.
Background Information
Red Hat® Ansible Architecture
Before learning the details of Itential Automation Gateway, it is helpful to have an overview of the Ansible architecture and the different terms and concepts associated with the Ansible automation engine.
In the diagram above, the Ansible automation engine has a direct interaction with the users who write playbooks to execute the Ansible Automation engine. It also interacts with cloud services and a Configuration Management Database (CMDB).
| Component | Description |
|---|---|
| Inventory | Inventory files are simple text files which describe servers, IP Addresses or DNS Names grouped by names. The inventory file can list individual hosts or user-defined groups of hosts. |
| API | APIs in Ansible are used as transport for Cloud services, public or private. |
| Modules | Modules are executed directly on remote hosts through playbooks. The modules can control system resources (i.e., services, packages, or files), or execute system commands, by acting on system files, installing packages or making API calls to the service network. |
| Plugins | Plugins augment Ansible’s core functionality and allows users to execute Ansible tasks. Ansible comes with built-in plugins; however, users are able to develop their own. |
| Networking | Ansible can be used to automate different networks. Ansible uses a simple, agentless automation framework. It uses a data model (a playbook or role) that is separate from the Ansible automation engine that easily spans different network hardware. |
| Hosts | The hosts in the Ansible architecture are just node systems which are getting automated by Ansible. It can be any kind of machine – Windows, Linux, Red Hat etc. |
| Playbooks | Playbooks are simple files written in YAML format which describes the tasks to be executed by Ansible. Playbooks can declare configurations, but they can also orchestrate the steps of any manual ordered process, even if it contains jump statements. They can launch tasks synchronously or asynchronously. |
| CMDB | The Configuration Management Database (CMDB) is a repository that acts as a data warehouse for IT installations. It holds data relating to a collection of IT assets (commonly referred to as configuration items (CI). |
| Cloud | A network of remote servers hosted on the Internet to store, manage, and process data, rather than a local server. You can launch your resources and instances on cloud and connect to your servers. |
Ansible Concepts and Terminology
Below are some additional terms and concepts to help you understand Ansible better, especially as it pertains to roles, modules and playbooks.
Playbooks
- Playbooks are expressed in YAML format, a simple syntax for Ansible’s configuration, deployment, and orchestration infrastructure.
- Playbooks 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 simple text files which describe your servers, IP Addresses or DNS Names grouped by names. The inventory file can list individual hosts or user-defined groups of hosts.
- The default location for the inventory file is /etc/ansible/hosts.
- Inventory files support variables and enumerations.
- 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. More simply, the role is 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.
Tasks
- At a basic level, a task is a call to an Ansible module.
- 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.
- The goal of each task is to execute a module, with very specific arguments.
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
- Variables (vars) are names of values; they can be simple scalar values (integers, booleans, strings) or complex ones (dictionaries/hashes, lists) that can be used in templates and playbooks.
- Vars are declared things, not things that are inferred from the remote system’s current state or nature.
Modules
- From a RESTful service standpoint, making multiple identical requests has the same effect as making a single request (idempotent).
- Ansible Modules will check whether its desired final state has already been achieved, and if that state has been achieved, will exit without performing any actions. If all the modules a playbook uses are idempotent, then the playbook itself is idempotent.
- Ansible refers to a collection of available modules as a library.
- Once modules are executed, they are removed, so no long running daemons are used.