Scale automation across your infrastructure with automation mesh

Learn how to plan an automation mesh deployment in your Ansible Automation Platform environment.

The subsequent sections:

  • Explain the concepts that comprise automation mesh
  • Provide examples on how you can design automation mesh topologies
  • Include simple to complex topology examples that illustrate the various ways you can deploy automation mesh
  • Contain information to help plan an automation mesh deployment in your operator-based Red Hat Ansible Automation Platform environment
  • Covers the setting up of automation mesh on operator-based deployments, such as OpenShift Container Platform and Ansible Automation Platform on Amazon Web Services (AWS) and Microsoft Azure managed applications.

About automation mesh
Copy link

Use automation mesh to scale Ansible capacity, improve execution reliability, and reduce latency by distributing automation workloads across multiple servers, cloud regions, and edge environments.

In this context, "scaling" means increasing your automation capacity, handling more parallel jobs and workloads without overloading a single server. Scaling distributes automation work across your infrastructure so you can handle more parallel jobs, support geographically distributed teams, and maintain availability if a server goes down.

The nodes (control, hop, and execution instances) are connected through a receptor mesh, forming a virtual mesh.

Automation mesh uses TLS encryption for communication, so traffic that uses external networks (the internet or other untrusted networks) is encrypted in transit.

Use automation mesh when you want to:

  • Scale your automation workloads: Run more automation tasks in parallel without overloading a single server
  • Execute automation closer to your infrastructure: Send automation jobs to servers in different locations or environments (data centers, cloud regions, edge locations) rather than routing everything through a central point
  • Improve reliability: If one execution location goes offline, your automation continues running from other locations in your mesh
  • Work across different environments: Deploy automation mesh nodes in virtual machines, containers, or OpenShift so you can work with however your infrastructure is built
  • Provide better performance: Reduce latency by running automation where your resources actually live instead of over the network

Automation mesh is useful if you have:

  • Large-scale automation environments with many jobs running daily
  • Infrastructure spread across multiple data centers, cloud providers, or regions
  • Teams in different locations who need to manage automation independently
  • Complex infrastructure that needs reliable, distributed automation

Working with an automation mesh generally involves the following phases:

  • Planning the topology: Deciding where execution nodes should reside and how they connect to each other.
  • Setting up execution nodes: Deploying nodes in the locations where automation needs to run, such as virtual machines, containers, or OpenShift.
  • Configuring the inventory: Setting up the automation controller so that it routes specific jobs to the correct execution nodes.
  • Monitoring the mesh: Using the topology viewer to check node status and verify that jobs are running in the right places.
  • Managing the mesh: Adding, removing, or adjusting nodes over time as the underlying infrastructure changes.

Control and execution planes
Copy link

Automation mesh makes use of unique node types to create both the control and execution plane. Learn more about the control and execution plane and their node types before designing your automation mesh topology.

Control plane
Copy link

The control plane contains the persistent services that manage and scale your automation environment. The specific set up of the control plane depends on your deployment model:
For VM environment mesh deployments
The control plane consists of hybrid and control nodes. Instances in the control plane run persistent automation controller services such as the the web server and task dispatcher, in addition to project updates, and management jobs.
Hybrid nodes
This is the default node type for control plane nodes, responsible for automation controller runtime functions like project updates, management jobs and ansible-runner task operations. Hybrid nodes are also used for automation execution.
Control nodes
Control nodes run project and inventory updates and system jobs, but not regular jobs. Execution capabilities are disabled on these nodes.
For managed cloud or operator environment mesh deployments
Instances in the control plane run persistent Ansible Automation Platform services such as the web server and task dispatcher, in addition to project updates, and management jobs. However, in the operator-based model, there are no hybrid or control nodes. There are container groups, which make up containers running on the Kubernetes cluster. That comprises the control plane. That control plane is local to the kubernetes cluster in which Red Hat Ansible Automation Platform is deployed.

Execution plane
Copy link

The execution plane consists of execution nodes that execute automation on behalf of the control plane and have no control functions. Hop nodes serve to communicate. Nodes in the execution plane only run user-space jobs, and may be geographically separated, with high latency, from the control plane.
Execution notes
Execution nodes run jobs under ansible-runner with podman isolation. This node type is similar to isolated nodes. This is the default node type for execution plane nodes.
Hop nodes
Similar to a jump host, hop nodes route traffic to other execution nodes. Hop nodes cannot execute automation.

Peers
Copy link

Peer relationships are essential for defining the node-to-node connections that form the automation mesh. The method for defining peers depends on your specific deployment model:
For VM environment mesh deployments
You can define peers within the [automationcontroller] and [execution_nodes] groups or using the [automationcontroller:vars] or [execution_nodes:vars] groups
For managed cloud or operator environment mesh deployments
Peers are defined through the UI for individual instances.

Define automation mesh node types
Copy link

The examples in this section demonstrate how to set the node type for the hosts in your inventory file.

Important

For a container-based installation of Ansible Automation Platform, replace node_type with receptor_type.

You can set the node_type for single nodes in the control plane or execution plane inventory groups. To define the node type for an entire group of nodes, set the node_type in the vars stanza for the group.

  • The permitted values for node_type in the control plane [automationcontroller] group are hybrid (default) and control.
  • The permitted values for node_type in the [execution_nodes] group are execution (default) and hop.

Hybrid nodes
Copy link

The following inventory consists of a single hybrid node in the control plane:

[automationcontroller]
control-plane-1.example.com

Control nodes
Copy link

The following inventory consists of a single control node in the control plane:

[automationcontroller]
control-plane-1.example.com node_type=control

If you set node_type to control in the vars stanza for the control plane nodes, then all of the nodes in control plane are control nodes.

[automationcontroller]
control-plane-1.example.com

[automationcontroller:vars]
node_type=control

Execution nodes
Copy link

The following stanza defines a single execution node in the execution plane:

[execution_nodes]
execution-plane-1.example.com

Hop nodes
Copy link

The following stanza defines a single hop node and an execution node in the execution plane. The node_type variable is set for every individual node.

[execution_nodes]
execution-plane-1.example.com node_type=hop
execution-plane-2.example.com

If you want to set the node_type at the group level, you must create separate groups for the execution nodes and the hop nodes.

[execution_nodes]
execution-plane-1.example.com
execution-plane-2.example.com

[execution_group]
execution-plane-2.example.com

[execution_group:vars]
node_type=execution

[hop_group]
execution-plane-1.example.com

[hop_group:vars]
node_type=hop

Peer connections
Copy link

Important

For a container-based installation of Ansible Automation Platform, use the receptor_peers= variable instead of peers=.

The value of receptor_peers must be a comma-separated list of hostnames. Do not use inventory group names. For more information, see Adding execution nodes.

Create node-to-node connections using the peers= host variable. The following example connects control-plane-1.example.com to execution-node-1.example.com and execution-node-1.example.com to execution-node-2.example.com:

[automationcontroller]
control-plane-1.example.com peers=execution-node-1.example.com

[automationcontroller:vars]
node_type=control

[execution_nodes]
execution-node-1.example.com peers=execution-node-2.example.com
execution-node-2.example.com

See the example automation mesh topologies in this section for more examples of how to implement mesh nodes.