Ansible Automation Platform 2.6 Architecture and Components: Complete Guide
By Luca Berton · Published 2024-01-01 · Category: installation
Complete guide to AAP 2.6 architecture and components: Platform Gateway, Automation Controller, Hub, EDA Controller, Automation Mesh, Execution Environments.
What Is Ansible Automation Platform 2.6?
Ansible Automation Platform (AAP) 2.6 is Red Hat's enterprise automation solution that packages multiple components into a unified platform for managing automation at scale. Unlike standalone Ansible (the open source CLI tool), AAP provides a complete control plane with role-based access control (RBAC), a centralized UI, event-driven automation, content management, and distributed execution.
AAP 2.6 introduces significant architectural improvements over previous versions, with the Platform Gateway serving as the single entry point and the shift toward a fully containerized deployment model.
This guide covers every core component, how they interact, and practical configuration examples.
See also: Containerized Ansible Automation Platform 2024 Update
AAP 2.6 Architecture Overview
AAP 2.6 follows a service-oriented architecture where each component handles a specific automation concern:
┌─────────────────────────────────────────────────────┐
│ Platform Gateway │
│ (Single Entry Point + Auth + UI) │
├──────────┬──────────┬──────────┬────────────────────┤
│Automation│Automation│ EDA │ Automation │
│Controller│ Hub │Controller│ Mesh │
├──────────┴──────────┴──────────┴────────────────────┤
│ Execution Environments (EEs) │
├─────────────────────────────────────────────────────┤
│ PostgreSQL │
└─────────────────────────────────────────────────────┘Data flow: Users authenticate through Platform Gateway Platform Gateway routes requests to the appropriate service Automation Controller orchestrates job execution Jobs run inside Execution Environments on Automation Mesh nodes Collections and EE images are sourced from Automation Hub EDA Controller listens for events and triggers automation All services store state in PostgreSQL
Platform Gateway
The Platform Gateway is the most important architectural change in AAP 2.6. It provides: • Single entry point into the entire platform • Unified authentication and authorization across all services • Platform UI — the main web interface users interact with • Service routing — fronts access to Controller, Hub, and EDA
Why Platform Gateway Matters
Before Platform Gateway, each AAP component had its own URL, login, and user management. Platform Gateway eliminates this fragmentation:
# Platform Gateway configuration in AAP installer inventory
[automationgateway]
gateway.example.com
# Gateway settings
automationgateway_pg_host=db.example.com
automationgateway_pg_database=gateway
automationgateway_pg_username=gateway
automationgateway_pg_password='{{ vault_gw_pg_password }}'
# SSO configuration through Gateway
automationgateway_main_url=https://gateway.example.com
automationgateway_ssl_cert=/path/to/ssl/cert.pem
automationgateway_ssl_key=/path/to/ssl/key.pem
Key Platform Gateway Features
| Feature | Description | |---------|-------------| | Unified login | Single sign-on across all AAP services | | RBAC integration | Central role and permission management | | Service discovery | Automatic routing to Controller, Hub, EDA | | API gateway | RESTful API access to all platform services | | Audit logging | Centralized authentication and access logs |
See also: Ansible Automation Platform Architecture: Components, Ecosystem, and Integration Guide
Automation Controller
Automation Controller (formerly Ansible Tower / AWX upstream) is the traditional control plane for running Ansible automation. It handles: • Inventories — define and manage target hosts • Credentials — securely store authentication secrets • Job Templates — reusable automation job definitions • Workflows — multi-step automation pipelines • RBAC — fine-grained role-based access control • Scheduling — cron-like job scheduling • Job execution orchestration — dispatch jobs to execution nodes
Example: Job Template via Automation Controller API
# Create a job template using the ansible.platform collection
- name: Create patching job template
ansible.platform.job_template:
controller_host: "{{ gateway_url }}"
controller_username: "{{ controller_user }}"
controller_password: "{{ controller_pass }}"
name: "Linux Patching - Production"
organization: "Operations"
project: "infrastructure-playbooks"
playbook: "patch-linux.yml"
inventory: "Production Servers"
credentials:
- "SSH Key - Production"
- "Vault - Production Secrets"
execution_environment: "ee-supported-rhel9"
ask_limit_on_launch: true
survey_enabled: true
state: presentAutomation Controller vs AWX
| Feature | Automation Controller | AWX | |---------|----------------------|-----| | Support | Red Hat supported | Community only | | Updates | Tested release cycle | Rolling upstream | | Clustering | Full HA support | Basic clustering | | RBAC | Enterprise RBAC | Basic RBAC | | Certifications | FIPS, FedRAMP eligible | None | | Integration | Platform Gateway SSO | Standalone auth |
Automation Hub and Private Automation Hub
Automation Hub provides the content layer for AAP: • Certified Collections — Red Hat tested and supported Ansible content • Private Collections — internally developed automation content • Execution Environment images — container images for job execution • Content signing — GPG signature verification for collections
Private Automation Hub
Private Automation Hub (also called HA Automation Hub when deployed with high availability) lets organizations: • Host internal collections behind the firewall • Mirror certified collections for air-gapped environments • Serve custom execution environment images • Enforce content approval workflows
# Configure ansible.cfg to use Private Automation Hub
[galaxy]
server_list = private_hub, certified_hub
[galaxy_server.private_hub]
url=https://hub.example.com/api/galaxy/content/internal/
token={{ hub_token }}
[galaxy_server.certified_hub]
url=https://hub.example.com/api/galaxy/content/rh-certified/
token={{ hub_token }}
Syncing Collections from Ansible Galaxy
# Sync community collections to Private Hub
- name: Configure community remote
ansible.platform.collection_remote:
hub_host: "{{ gateway_url }}"
hub_username: "{{ hub_user }}"
hub_password: "{{ hub_pass }}"
name: "community"
url: "https://galaxy.ansible.com/api/"
requirements:
- name: community.general
- name: community.crypto
- name: community.postgresql
state: presentSee also: AAP 2.6 Execution Environments: Build, Manage, and Deploy Custom EEs
Event-Driven Ansible (EDA) Controller
EDA Controller adds event-driven automation to the platform. It: • Connects to event sources (webhooks, message queues, log streams, monitoring tools) • Evaluates rulebooks — YAML-defined event-condition-action logic • Triggers actions — run playbooks, call APIs, send notifications
EDA Rulebook Example
---
- name: Respond to ServiceNow incidents
hosts: all
sources:
- ansible.eda.webhook:
host: 0.0.0.0
port: 5000
rules:
- name: Auto-remediate disk full alert
condition: event.payload.priority == "P1" and "disk" in event.payload.description
action:
run_job_template:
name: "Disk Cleanup - Emergency"
organization: "Operations"
job_args:
extra_vars:
target_host: "{{ event.payload.host }}"
threshold: 90
- name: Log low-priority events
condition: event.payload.priority == "P4"
action:
debug:
msg: "Low priority event: {{ event.payload.description }}"
EDA Event Sources
EDA supports multiple event source plugins:
| Source | Plugin | Use Case |
|--------|--------|----------|
| Webhooks | ansible.eda.webhook | ServiceNow, GitHub, PagerDuty |
| Kafka | ansible.eda.kafka | Stream processing, log aggregation |
| AWS SQS | ansible.eda.aws_sqs | Cloud event processing |
| Alertmanager | ansible.eda.alertmanager | Prometheus/Grafana alerts |
| File watch | ansible.eda.file_watch | Config file changes |
| URL check | ansible.eda.url_check | Endpoint health monitoring |
Automation Mesh
Automation Mesh separates control capacity from execution capacity, enabling distributed automation across networks, sites, and security zones.
Key Automation Mesh Concepts
• Control nodes — run the Controller services, manage job scheduling • Execution nodes — run the actual Ansible playbooks inside EEs • Hop nodes — relay traffic between control and execution nodes without running jobs • Peer-to-peer mesh routing — nodes communicate directly, with hop nodes bridging network boundariesMesh Topology Example
┌─────────────┐
│ Control │
│ Plane │
│ (Data │
│ Center) │
└──────┬───────┘
│
┌────┴────┐
│ Hop │ ← DMZ / Firewall boundary
│ Node │
└────┬────┘
│
┌────┴──────────────┐
│ │
┌─┴──────┐ ┌───────┴─┐
│Exec │ │Exec │
│Node │ │Node │
│(Site A)│ │(Site B) │
└────────┘ └─────────┘Mesh Installer Configuration
# AAP installer inventory for mesh topology
[automationcontroller]
controller1.example.com
controller2.example.com
[automationcontroller:vars]
peers=execution_nodes
[execution_nodes]
exec-dc1.example.com node_type=execution
exec-dc2.example.com node_type=execution
[execution_nodes:vars]
peers=hop_nodes
[hop_nodes]
hop-dmz.example.com node_type=hop
[hop_nodes:vars]
peers=remote_execution
[remote_execution]
exec-remote1.example.com node_type=execution
exec-remote2.example.com node_type=execution
When to Use Hop Nodes
• DMZ traversal — execution nodes in a restricted network zone • Multi-site deployments — reduce direct connections between sites • Latency optimization — hop nodes as regional relay points • Security boundaries — limit which nodes can reach the control planeAutomation Execution Environments
Execution Environments (EEs) are container images that package everything needed to run Ansible automation: • Ansible core • Python dependencies • System packages • Ansible collections • Custom modules and plugins
Why EEs Replace Python Virtual Environments
Before EEs, managing Ansible dependencies across control nodes was painful — conflicting Python packages, missing system libraries, inconsistent collection versions. EEs solve this by containerizing the entire execution context.
Building a Custom EE
# execution-environment.yml
---
version: 3
images:
base_image:
name: registry.redhat.io/ansible-automation-platform-26/ee-minimal-rhel9:latest
dependencies:
galaxy:
collections:
- name: ansible.netcommon
version: ">=7.0.0"
- name: cisco.ios
version: ">=9.0.0"
- name: arista.eos
version: ">=10.0.0"
python:
- paramiko>=3.0
- netaddr>=1.0
- jmespath>=1.0
system:
- iputils [platform:rpm]
- openssh-clients [platform:rpm]
additional_build_steps:
prepend_base:
- RUN whoami
- RUN cat /etc/os-release
append_final:
- RUN pip3 freeze | grep -i ansible
- COPY custom_filter_plugins/ /usr/share/ansible/plugins/filter/
Build with ansible-builder:
ansible-builder build \
--tag registry.example.com/ee-network:1.0 \
--container-runtime podman \
--prune-imagesRed Hat Provided EEs
| EE Image | Contents | Use Case |
|----------|----------|----------|
| ee-minimal-rhel9 | Ansible core + minimal deps | Lightweight automation |
| ee-supported-rhel9 | Core + Red Hat certified collections | General enterprise use |
| ee-29-rhel9 | Core 2.16+ supported collections | Latest features |
Ansible Galaxy
Ansible Galaxy serves as the community content hub: • Browse and download community collections • Publish your own collections and roles • Search for automation content by platform, category, or keyword
In AAP 2.6, Galaxy integrates with Private Automation Hub to sync approved community content into your internal content pipeline.
Automation Content Navigator
Automation Content Navigator (ansible-navigator) is the developer tool for AAP:
# Run a playbook inside an EE
ansible-navigator run site.yml \
--eei registry.example.com/ee-network:1.0 \
--mode stdout
# Explore collection documentation
ansible-navigator collections --eei ee-supported-rhel9
# Inspect an EE's contents
ansible-navigator images --eei ee-supported-rhel9
Navigator replaces multiple CLI tools:
| Old Tool | Navigator Equivalent |
|----------|---------------------|
| ansible-playbook | ansible-navigator run |
| ansible-doc | ansible-navigator doc |
| ansible-inventory | ansible-navigator inventory |
| ansible-config | ansible-navigator config |
PostgreSQL
PostgreSQL is the backing database for all AAP services: • Platform Gateway — session and routing data • Automation Controller — jobs, inventories, credentials, RBAC • Automation Hub — collection metadata, approval workflows • EDA Controller — rulebook activations, event logs
PostgreSQL Requirements for AAP 2.6
| Requirement | Specification |
|-------------|---------------|
| Managed databases | PostgreSQL 15 |
| External databases | PostgreSQL 15, 16, or 17 (ICU support required) |
| External DB minimum | 4 vCPU, 16 GB RAM, 200 GB storage, 3000 IOPS, max_connections: 1024 |
| Backup/restore | PostgreSQL 16/17 require external backup processes (utilities depend on PG 15) |
# External database configuration in installer inventory
[all:vars]
gateway_pg_host=externaldb.example.org
gateway_pg_database=gateway
gateway_pg_username=gateway
gateway_pg_password=<set your own>
controller_pg_host=externaldb.example.org
controller_pg_database=controller
controller_pg_username=controller
controller_pg_password=<set your own>
hub_pg_host=externaldb.example.org
hub_pg_database=hub
hub_pg_username=hub
hub_pg_password=<set your own>
eda_pg_host=externaldb.example.org
eda_pg_database=eda
eda_pg_username=eda
eda_pg_password=<set your own>
Red Hat Tested Deployment Models
Red Hat tests AAP 2.6 with specific reference architectures across three installation modes. Using a tested topology ensures the highest level of support, uptime, and scalability.
Installation Modes
| Mode | Infrastructure | Description | |------|---------------|-------------| | Containers (Recommended) | VMs and bare metal | Podman-based containers on RHEL. Recommended for new deployments. | | Operator | Red Hat OpenShift | Kubernetes Operator on OpenShift. Managed via Custom Resources. | | RPM (Deprecated) | VMs and bare metal | Traditional RPM packages on RHEL. Deprecated in 2.5, removed in 2.7. |
Each mode offers a growth topology (single-node or minimal, no redundancy) and an enterprise topology (multi-node with HA and redundancy).
> Important: The RPM installer is deprecated and will be removed in AAP 2.7. It is supported on RHEL 9 during the AAP 2.6 lifecycle only for migrations. See our AAP 2.6 RPM Deprecation and Containerized Migration guide.
System Requirements (Per VM)
| Requirement | Minimum |
|-------------|---------|
| RAM | 16 GB (32 GB for growth bundled installs with hub_seed_collections=true) |
| CPUs | 4 |
| Local disk | 60 GB total available |
| Disk IOPS | 3000 |
| OS | RHEL 9.4+ or RHEL 10+ |
| CPU architecture | x86_64, AArch64, s390x (IBM Z), ppc64le (IBM Power) |
| ansible-core | RHEL 9: 2.14, RHEL 10: 2.16 (platform bundles 2.16 separately) |
| Database | PostgreSQL 15 (managed) or 15/16/17 (external) |
| IP | IPv4, IPv6 (single-stack and dual-stack) |
Container Growth Topology (Single Node)
All components on one VM. Suitable for getting started and evaluation:
# Container growth topology — single VM
[automationgateway]
aap.example.org
[automationcontroller]
aap.example.org
[automationhub]
aap.example.org
[automationeda]
aap.example.org
[database]
aap.example.org
[all:vars]
ansible_connection=local
postgresql_admin_username=postgres
postgresql_admin_password=<set your own>
registry_username=<your RHN username>
registry_password=<your RHN password>
redis_mode=standalone
gateway_admin_password=<set your own>
gateway_pg_host=aap.example.org
gateway_pg_password=<set your own>
controller_admin_password=<set your own>
controller_pg_host=aap.example.org
controller_pg_password=<set your own>
controller_percent_memory_capacity=0.5
hub_admin_password=<set your own>
hub_pg_host=aap.example.org
hub_pg_password=<set your own>
hub_seed_collections=false
eda_admin_password=<set your own>
eda_pg_host=aap.example.org
eda_pg_password=<set your own>
Container Enterprise Topology (Multi-Node HA)
Full redundancy with external database and HAProxy load balancer:
| VM Count | Purpose | |----------|---------| | 2 | Platform Gateway with colocated Redis | | 2 | Automation Controller | | 2 | Private Automation Hub with colocated Redis | | 2 | Event-Driven Ansible with colocated Redis | | 1 | Automation Mesh hop node | | 2 | Automation Mesh execution nodes | | 1 | Externally managed database | | 1 | HAProxy load balancer (externally managed) |
# Container enterprise topology — multi-node HA
[automationgateway]
gateway1.example.org
gateway2.example.org
[automationcontroller]
controller1.example.org
controller2.example.org
[execution_nodes]
hop1.example.org receptor_type='hop'
exec1.example.org
exec2.example.org
[automationhub]
hub1.example.org
hub2.example.org
[automationeda]
eda1.example.org
eda2.example.org
[redis]
gateway1.example.org
gateway2.example.org
hub1.example.org
hub2.example.org
eda1.example.org
eda2.example.org
[all:vars]
postgresql_admin_username=<set your own>
postgresql_admin_password=<set your own>
registry_username=<your RHN username>
registry_password=<your RHN password>
gateway_admin_password=<set your own>
gateway_pg_host=externaldb.example.org
gateway_pg_database=<set your own>
gateway_pg_username=<set your own>
gateway_pg_password=<set your own>
controller_admin_password=<set your own>
controller_pg_host=externaldb.example.org
controller_pg_database=<set your own>
controller_pg_username=<set your own>
controller_pg_password=<set your own>
hub_admin_password=<set your own>
hub_pg_host=externaldb.example.org
hub_pg_database=<set your own>
hub_pg_username=<set your own>
hub_pg_password=<set your own>
eda_admin_password=<set your own>
eda_pg_host=externaldb.example.org
eda_pg_database=<set your own>
eda_pg_username=<set your own>
eda_pg_password=<set your own>
> Note: Redis HA requires 6 VMs. Redis can be colocated on any AAP component VM except execution nodes or the PostgreSQL database. External Redis is not supported for containerized AAP.
Operator Topology (OpenShift)
For OpenShift deployments, AAP uses a Kubernetes Operator with Custom Resources:
Growth (Single Node OpenShift): 32 GB RAM, 16 CPUs, 128 GB disk, 3000 IOPS.
# Operator growth topology — Custom Resource
apiVersion: aap.ansible.com/v1alpha1
kind: AnsibleAutomationPlatform
metadata:
name: aap
spec:
eda:
automation_server_ssl_verify: 'no'
hub:
storage_type: 's3'
object_storage_s3_secret: '<s3-secret-name>'Enterprise (Multi-Node OpenShift): Red Hat OpenShift on AWS (ROSA) with Hosted Control Planes, 2 worker nodes (t3.xlarge) across 2 availability zones, external PostgreSQL (RDS), external Redis (ElastiCache), S3 object storage for Hub.
| Component | Pod Count | |-----------|-----------| | Controller web | 1 | | Controller task | 1 | | Hub web | 1 | | Hub API | 1 | | Hub content | 2 | | Hub worker | 2 | | EDA API | 1 | | EDA activation worker | 2 | | EDA default worker | 2 | | EDA event stream | 2 | | EDA scheduler | 1 | | Platform Gateway | 1 | | Mesh ingress | 2 |
> Important: You can only install a single AAP Operator instance per namespace. Multiple instances in the same namespace cause improper operation.
How Components Interact
Understanding the data flow between components is critical for troubleshooting and capacity planning:
Job Execution Flow
User submits job via Platform Gateway UI or API Gateway authenticates and routes to Automation Controller Controller resolves inventory, credentials, and EE image Controller dispatches job to an execution node via Automation Mesh Execution node pulls EE image (from Automation Hub registry) Job runs inside the EE container Results flow back through Mesh to Controller Controller stores results in PostgreSQL User views results via Gateway UIEvent-Driven Flow
External event arrives at EDA Controller (webhook, Kafka, etc.) EDA evaluates event against active rulebook activations If a rule matches, EDA calls Automation Controller API Controller executes the triggered job template Results available in both Controller and EDA event logsNetwork Port Requirements
Red Hat Ansible Automation Platform uses these ports for inter-component communication. All must be open and not blocked by firewalls.
Core Service Ports
| Port | Protocol | Source | Destination | Purpose | |------|----------|--------|-------------|---------| | 80/443 | TCP HTTP/HTTPS | Platform Gateway | Controller | Gateway → Controller communication | | 80/443 | TCP HTTP/HTTPS | Platform Gateway | Hub | Gateway → Hub communication | | 80/443 | TCP HTTP/HTTPS | Platform Gateway | EDA | Gateway → EDA communication | | 80/443 | TCP HTTP/HTTPS | Controller | Hub | Pull collections and EE images | | 80/443 | TCP HTTP/HTTPS | EDA | Controller | Launch Controller jobs | | 80/443 | TCP HTTP/HTTPS | EDA | Hub | Pull decision environments | | 80/443 | TCP HTTP/HTTPS | HAProxy | Gateway | External load balancer (enterprise) |
Data and Mesh Ports
| Port | Protocol | Source | Destination | Purpose | |------|----------|--------|-------------|---------| | 5432 | TCP PostgreSQL | All components | Database | Database access | | 6379 | TCP Redis | Gateway, EDA | Redis node | Session/job data storage | | 16379 | TCP Redis | Redis node | Redis node | Redis cluster bus (enterprise HA) | | 27199 | TCP Receptor | Controller | Exec/Hop nodes | Automation Mesh communication | | 27199 | TCP Receptor | Hop node | Exec node | Mesh relay through hop nodes |
Internal NGINX Ports
| Port | Service | Configurable Via |
|------|---------|-----------------|
| 8080/8443 | Controller NGINX | controller_nginx_http_port, controller_nginx_https_port |
| 8081/8444 | Hub NGINX | hub_nginx_http_port, hub_nginx_https_port |
| 8082/8445 | EDA NGINX | eda_nginx_http_port, eda_nginx_https_port |
| 8083/8446 | Gateway NGINX | gateway_nginx_http_port, gateway_nginx_https_port |
Best Practices
Sizing Guidelines (Red Hat Tested)
Red Hat tests each VM with these minimum requirements:
| Requirement | All Components | |-------------|---------------| | RAM | 16 GB minimum | | CPUs | 4 | | Local disk | 60 GB | | Disk IOPS | 3000 |
For Operator enterprise topology on OpenShift, the external database minimum is:
• 4 vCPU, 16 GB RAM
• max_connections: 1024 minimum
• 200 GB storage on a volume capable of 3000+ IOPS
> Tip: Database storage consumption depends on job frequency, playbook task count, output verbosity, and managed hosts per job. Higher verbosity levels increase storage by 3-5x. Configure automated cleanup jobs to prevent unbounded growth.
Security Recommendations
• Enable TLS everywhere — all component-to-component communication • Use external certificate authority — not self-signed certs in production • Configure LDAP/SAML/OIDC through Platform Gateway for enterprise SSO • Rotate database credentials and API tokens regularly • Enable audit logging on Platform GatewayFAQ
What is the difference between AAP and Ansible Core?
Ansible Core is the open source command-line tool for running playbooks. AAP wraps Ansible Core with enterprise features: a web UI, RBAC, job scheduling, audit logging, event-driven automation, distributed execution, and certified content. AAP is a Red Hat subscription product; Ansible Core is free.
Can I run AAP 2.6 without Platform Gateway?
No. Platform Gateway is a required component in AAP 2.6. It provides the unified authentication layer and UI that all other services depend on. You cannot deploy Controller, Hub, or EDA independently in AAP 2.6.
What happened to Ansible Tower?
Ansible Tower was renamed to Automation Controller starting with AAP 2.0. The functionality is the same — job templates, inventories, workflows, RBAC — but it now operates as one service within the broader platform rather than a standalone product.
Is AWX the same as Automation Controller?
AWX is the open source upstream project for Automation Controller. They share the same codebase, but Automation Controller includes Red Hat support, tested releases, certified content integration, and Platform Gateway SSO. AWX is community-supported only.
How does Automation Mesh differ from isolated nodes in Tower?
Automation Mesh replaces the legacy isolated node concept from Ansible Tower. Mesh provides peer-to-peer communication (not just control→isolated), hop node routing for complex network topologies, automatic failover, and better scalability. Mesh nodes use the Receptor protocol (TCP 27199) instead of SSH.
Can I use AAP 2.6 in air-gapped environments?
Yes. Deploy Private Automation Hub to host collections and EE images internally. Mirror certified content and container images before disconnecting. The containerized installer supports fully disconnected installation with pre-downloaded images.
What is the recommended database for production?
PostgreSQL 15 (managed) or PostgreSQL 15, 16, or 17 (external with ICU support). For HA, use a managed service like Amazon RDS or Azure Database for PostgreSQL. The Operator-deployed database has a default max_connections limit of 100 and maximum size of 100 GB — use an external database if running more than 1 replica of any component, exceeding 100 concurrent Controller jobs, or expecting more than 100 GB of data in 30 days.
Is RPM installation still supported?
The RPM installer was deprecated in AAP 2.5 and will be removed in AAP 2.7. It is supported on RHEL 9 during the AAP 2.6 lifecycle only to support migrations to containerized or Operator-based topologies. All new deployments should use the containerized installer or the OpenShift Operator.
What CPU architectures does AAP 2.6 support?
AAP 2.6 supports x86_64, AArch64 (ARM), s390x (IBM Z), and ppc64le (IBM Power). This applies to container, Operator, and RPM deployment modes on RHEL 9.4+ or RHEL 10+.
Conclusion
AAP 2.6's architecture represents a mature, service-oriented approach to enterprise automation. The Platform Gateway unifies access, Automation Controller handles orchestration, EDA adds event-driven capabilities, Automation Mesh distributes execution, and Execution Environments ensure consistency.
Understanding how these components fit together is essential for planning deployments, troubleshooting issues, and scaling automation across your organization.
Related Articles
• AAP 2.6 RBAC and Gateway API • AAP 2.6 Event-Driven Ansible Enhancements • AAP 2.6 RPM Deprecation and Containerized Migration • AAP 2.6 Automation Dashboard Guide • AAP 2.6 Security Best Practices • AAP 2.6 Configuration as Code with ansible.platform • AAP 2.6 New Collections and Integrations • AAP 2.6 Lightspeed Intelligent Assistant • AAP 2.6 Upgrade Guide from 2.5 • AAP 2.6 vs 2.5 ComparisonRelated: Ansible Builder & Execution Environments
Related: Ansible Cisco UCS Automation
See also
• Ansible Event-Driven Automation (EDA): Complete Guide with Rulebooks and ExamplesCategory: installation