Red Hat Ansible Automation is an open source automation platform. It is suitable for both low-level automation, which connects directly to each of the elements separately, and high-level, which is implemented through dedicated controllers from other manufacturers. In addition to the automation of other Red Hat Solutions, it also automat products and solutions from other manufacturers and binds automation within the entire infrastructure.

The platform provides CLI and WebUI as well as API for integration with external systems. It provides centralized insight into current and historical events. It can create very advanced task flows that can be dependent on each other and be conditionally performed. A schedule is also supported which enables cyclical tasks and facilitates compliance verification. Access to its individual elements can be differentiated and controlled using RBAC (Role Based Access Control). It also enables convenient integration with internal and external credential containers and user databases.

It uses natively available and popular management methods, which include SSH (Secure Shell), WinRM (Windows Remote Management), NETCONF (RFC 6241), RESTCONF (RFC 8040) or API. Thanks to this, it can usually be used without major changes within the infrastructure, such as firewall reconfiguration or the installation of additional software in the form of indirect agents.

The Red Hat Ansible Automation platform includes several elements, which include:

• Ansible Engine – an engine used to perform playbooks and ad hoc commands.
• Ansible Tower – central service, control and management of automation within the organization.
• Automation Hub – a portal containing certified collections, roles and modules.
• Automation Analytics – analytics, reports and statistics within clusters consisting of many Ansible Towers.

Red Hat Ansible Automation is a framework for automation that can be comfortably expanded with new functionalities. This is accomplished through additional plugins and modules. Their quantity is still growing.

The task of the Red Hat Ansible Automation platform is to bring devices, systems, files, applications or services to the desired state, which is described in a declarative language. This means that we only specify the state that we want the object to assume, without describing in detail how it must be done. The modules are already in charge of bringing it to a certain state. Depending on the initial state of the object, the module we use can perform more or less different operations on it, or even do not perform any operations at all, if it is not needed. This approach is characterized by idempotence, which here is the ability to repeatedly run the same module without changing the final state of the object.

It also means that we can safely execute the same module many times on a given object. If the object is already in the declared state, then nothing will happen, and if it is not, Ansible will bring the object to the desired state.

It should be remembered that idempotence is guaranteed only if we use specialized and built-in modules. If we create them ourselves or use other methods, such as sending ad hoc commands, then we have to take care of idempotence ourselves.

In addition to modules and commands, we can also use Jinja2 templates. They are great for personalizing the content of files based on the declared values of variables.

While the use of Jinja2 templates or the ability to issue CLI commands can be convenient and sometimes even necessary, these methods should be used as a last resort. If only a suitable specialized module is available, we should use it first.

In this way, we will not only be guaranteed idempotence, but also we can describe the entire infrastructure with one consistent code or language (IaC – Infrastructure as Code).

In the case of Ansible, the language is YAML (YAML Ain’t Markup Language). With its help, we build playbooks, which are a sequential list of tasks to play on given objects, or in other words, the states that they should have after their execution. Please note, that various other operations may also be defined as part of the playbook, including copying the file, downloading something from somewhere, running specific CLI commands or using the Jinja2 templates. You can also use various loops, conditions, regular expressions, variables and handlers.

We also have the ability to perform ad hoc commands and tasks, as well as define more complex roles. Roles are a collection of files and playbooks that are necessary for a given device or system to perform a specific role or function in our environment.

Red Hat Ansible Automation supports both static and dynamic inventories. Static are created manually in INI or YAML files. Dynamic download data from other solutions, such as Amazon EC2, Red Hat Satellite, Cisco ACI (Application Centric Infrastructure) or from the results of dynamically running scripts that download data from various databases.

Red Hat Ansible Automation is great for automating both small and large networks. In smaller networks, it can directly connect to devices, adapting them to specific requirements, and in larger networks, it can do so through dedicated systems, such as Cisco NSO, Cisco SD-WAN, Cisco ACI or Cisco DNA.

The reason for using additional SDN (Software Defined Network) controllers in larger networks is not just automation and orchestration. These systems provide extensive diagnostic, analysis and visualization tools, which Ansible does not provide. Therefore, while Ansible cannot fully replace such solutions, it can cooperate with them by acting at a higher level. Manual clicking through a large number of tabs of various controllers is tedious, time-consuming and prone to errors and omissions. That is why it is much easier to automate it at the Ansible level.

In this way, Red Hat Ansible Automation can combine our entire infrastructure into one harmonious organism.