Network Automation with Red Hat Ansible Automation Platform
Abstract
| Goal |
Describe the fundamental concepts of Ansible and how it is used, and install development tools from Red Hat Ansible Automation Platform. |
| Objectives |
|
| Sections |
|
Describe the motivation for automating network administration tasks with Ansible, fundamental Ansible concepts, and the basic architecture of Ansible.
For many years, network engineering and administration has relied mostly on manual tasks performed through graphical or command-line user interfaces. Network engineers often work from checklists, configuration templates, or a memorized routine to perform standard tasks.
This approach is error-prone and difficult to maintain. It is easy to skip steps and make mistakes. Verification that the steps were performed properly or that they result in the expected outcome is often limited.
By managing devices manually and independently, it is easy for many devices that are supposed to have the same configuration to be different in minor (or major) ways. This can make maintenance more difficult and introduce errors or instability into your infrastructure.
Automation can help avoid the problems caused by manual configuration.
Automation can help you perform the following tasks:
Ensure that your network infrastructure is quickly and correctly deployed and configured.
Perform routine or repetitive tasks with minimal effort.
Free up your time and enable you to focus on more critical tasks.
Reduce risks associated with network infrastructure upgrades or changes.
Respond to service outages and quickly restore service.
Roll out security configuration updates quickly and effectively.
NetDevOps means applying the methods, strategies, and best practices of DevOps to networking. Using Ansible for network automation provides you with implementation flexibility and the ability to mitigate risks. Network automation is a foundational component of a NetDevOps culture, but you do not have to take an all or nothing approach.
With Ansible, you can implement automation in phases. You can start with read-only automation by performing the following tasks:
Gather an inventory of your network.
Create backups of device configurations.
Gather the configuration states of your network devices.
View specific statistics debugging information to help you resolve issues.
When you are ready, you can continue your automation adoption journey by performing the following tasks:
Automate the configuration of certain devices or services.
Automate specific standard configuration settings, such as logging and reporting, or security settings.
You can then continue to roll out automation to your entire infrastructure.
A good automation system allows you to implement infrastructure as code (IaC) practices. IaC means that you can use a machine readable automation language to define and describe the required state of your infrastructure.
Ideally, this automation language should also be easy for humans to read, because then you can readily understand the current state. This code is then applied to your infrastructure to ensure that it is in the expected or desired state.
If the automation language is represented as simple text files, then it is easy to manage in a version control system. The advantage of this is that every change can be uploaded to the version control system, ensuring that you have an ongoing history of changes. If you want to revert to an earlier known-good configuration, then you can pull that version and apply it to your infrastructure.
IaC techniques help you to accurately and consistently manage your network infrastructure, and provide a foundation for NetDevOps workflows. You can define the desired configuration in the automation language, and then a peer can review the accuracy of those changes. You can then use that automation to ensure that the network is in the state that you expect.
Using task automation and IaC practices can help you ensure that your network is consistently configured. This means that you need to become accustomed to making changes by updating your automation code, rather than manually applying the changes to devices. Otherwise, you run the risk of losing manually applied changes the next time you apply changes using automation.
You can use code review, peer review by multiple subject matter experts, and document the procedure within the automation content to reduce your operational risks.
To mitigate human error, changes must be made through automation.
Ansible is an open source automation platform. It is a simple automation language that can accurately describe an IT application infrastructure in Ansible Playbooks. It is also an automation engine that runs Ansible Playbooks.
Ansible can manage powerful automation tasks and can adapt to many workflows and environments. At the same time, new users of Ansible can quickly use it to become productive.
The following goals were used during the design of Ansible.
- Complexity Kills Productivity
Simpler is better. Ansible is designed so that its tools are simple to use and automation is simple to write and read. You should take advantage of this to strive for simplification in how you create your automation.
- Optimize for Readability
The Ansible automation language is built around simple, declarative, text files that are easy for humans to read. Written properly, Ansible Playbooks can clearly document your workflow automation.
- Think Declaratively
Ansible is a desired-state engine. It approaches the problem of how to automate technology deployments by expressing them in terms of the required end state of your systems. The goal of Ansible is to put your systems into the desired state, only making changes that are necessary. Trying to treat Ansible like a scripting language is not the right approach.
Ansible has a number of important strengths:
Cross-platform support: Ansible provides agentless support for Linux, Windows, UNIX, and network devices, in physical, virtual, cloud, and container environments.
Precise application descriptions: Every change can be made by Ansible Playbooks, and every aspect of your application environment can be described and documented.
Easy to manage in version control: Ansible Playbooks and projects are plain text. They can be treated like source code and placed in your existing version control system.
Support for dynamic inventories: The list of machines that Ansible manages can be dynamically updated from external sources to capture the correct, current list of all managed nodes all the time, regardless of infrastructure or location.
Orchestration that integrates with other systems: Puppet, Jenkins, Red Hat Satellite, and other systems that exist in your environment can be leveraged and integrated into your Ansible workflow.
Human-readable automation: Ansible Playbooks, written as YAML text files, are easy to read and help ensure that everyone understands what the playbooks do.
 |
Communication is the key to DevOps and NetDevOps. Ansible is the first automation language that can be read and written across IT.
The Ansible architecture consists of two types of machines: control nodes and managed nodes. Ansible is installed and run from a control node, and this machine also has copies of your Ansible project files.
The Ansible architecture is agentless. Typically, when you run an Ansible Playbook, the control node connects to the managed host by using SSH by default. For managed nodes that are network devices, you might access the device command-line interface (CLI) over SSH, send XML messages over SSH, or connect to an API using the HTTP or HTTPS protocol.
Because the Ansible architecture is agentless, you do not need to have an Ansible-specific agent installed on managed nodes, and do not need to configure any additional communication between the control node and managed nodes.
- Inventory Management
Managed nodes are listed in an inventory, which also organizes those systems into groups for easier collective management. You can define the inventory statically in a text file, or dynamically using scripts that obtain group and host information from external sources.
- Playbooks and Plays
Instead of writing complex scripts, Ansible users create high-level plays, which ensure that hosts are in a particular state. A play performs a series of tasks on the hosts, in the order specified by the play. These plays are expressed in YAML format in a text file. A file that contains one or more plays is called a playbook.
- Tasks and Modules
Each task runs a module, a small piece of code (written in Python, PowerShell, or some other language), with specific arguments. Each module is essentially a tool in your toolkit. Ansible ships with a core set of useful modules, and you can install additional modules using Ansible content collections. Modules can perform a wide variety of automation tasks, such as modifying system files, installing software, or making API calls.
- Idempotent State Management
Tasks, plays, and playbooks are designed to be idempotent. This means that you can safely run a playbook against the same nodes multiple times. When your systems are in the correct state, the playbook makes no changes when you run it.
- Using Plug-ins
Ansible also uses plug-ins. Plug-ins are code that you can add to Ansible to extend it and adapt it to new uses and platforms.
Red Hat Ansible Automation Platform 2 includes a number of distinct components, which together provide a complete and integrated set of automation tools and resources.
Ansible Core provides the fundamental functionality used to run Ansible Playbooks. It defines the automation language that is used to write Ansible Playbooks in YAML text files. It provides the key functions needed for automation code, such as loops, conditionals, and other Ansible imperatives. It also provides the framework and basic command-line tools to drive automation.
Red Hat Ansible Automation Platform 2.3 provides Ansible Core 2.14 in the ansible-core RPM package.
Historically, Ansible provided many modules as part of the core package; an approach referred to in the Ansible community as "batteries included". However, with the success and rapid growth of Ansible, the number of modules included with Ansible grew exponentially. This led to certain challenges with support, especially because users sometimes wanted to use earlier or later versions of modules than were packaged with a particular version of Ansible.
The upstream developers decided to reorganize most modules into separate Ansible Content Collections, made up of related modules, roles, and plug-ins that are supported by the same group of developers.
Ansible Core itself is limited to a small set of modules provided by the ansible.builtin Ansible Content Collection, which is always part of Ansible Core.
This provides users with the flexibility to select different versions of collections, or different sets of collections, based on their needs. It also provides developers with the ability to update their modules on a separate cadence from Ansible itself.
Certain collections, such as those belonging to Red Hat Ansible Certified Content Collections, are officially supported by Red Hat and its partners through Ansible Automation Platform.
Ansible Automation Platform 2 provides a new top-level tool to develop and test Ansible Playbooks, called automation content navigator (ansible-navigator).
This tool replaces and extends the functionality of several earlier command-line utilities, including ansible-playbook, ansible-inventory, and ansible-config.
In addition, automation content navigator separates the control node, on which you run Ansible, from the automation execution environment that runs it, by running your playbooks in a container. This separation makes it easier for you to provide a complete working environment for your automation code from deployment to production.
An automation execution environment is a container image that contains Ansible Core, Ansible Content Collections, and any Python libraries, executables, or other dependencies needed to run your playbook.
 |
When you run a playbook with ansible-navigator, you can select an automation execution environment for it to use to run that playbook.
When your code is working, you can provide the playbook and the automation execution environment to automation controller (formerly called Red Hat Ansible Tower) and know that automation controller has everything it needs to correctly run your playbook.
Automation controller, formerly called Red Hat Ansible Tower, is the component of Ansible Automation Platform that provides a central point of control to run your enterprise automation code. It provides a web UI and a REST API that can be used to configure, run, and evaluate your automation jobs.
The automation controller design separates the control node (providing the web UI and API) from the automation execution environments (which run in containers). You can deploy containerized automation execution environments from a container registry. Replacing execution environments for a particular Ansible Playbook is a matter of a simple configuration change in the web UI.
 |
Automation controller can run automation execution environments on remote nodes (execution nodes), communicating with them over the network using a feature called automation mesh.
Note
Automation controller and automation content navigator both support automation execution environments. This simplifies the transition from developing playbooks to running them in production, because you do not need to use virtual environments or to install modules and their dependencies on automation controller. You can customize execution engines to contain everything that your organization requires to execute its playbooks.
Provided that automation content navigator and automation controller have access to the same automation execution environments, the transition of your playbooks from development to production should be almost seamless.
Automation hub provides a way to manage and distribute automation content.
A public service at console.redhat.com provides access to Red Hat Ansible Certified Content Collections, which you can download and use with ansible-galaxy (for ansible-navigator) and with automation controller.
You can also set up a private automation hub. A private automation hub enables you to create your own curated set of Ansible Content Collections. It also provides a container registry that you can use for distributing your automation execution environments, if you do not already have one.
A private automation hub provides a centralized place for automation controller and the organization's Ansible developers to obtain automation content.
 |
In addition to the hosted automation hub at console.redhat.com, two other hosted services are available.
Red Hat Insights for Red Hat Ansible Automation Platform helps you understand what automation code you are running and whether it is successful. You can also use it to evaluate the positive impact of automation on your organization.
Automation Analytics helps to provide better insight into the performance of your automation infrastructure. You can use it to analyze how you use automation and what modules, playbooks, and workflows you most often use.
The following diagram shows the components of a Red Hat Ansible Automation Platform 2 deployment alongside the personas of some people who would use them.
 |
