When Red Hat Ansible Automation Platform is central to your enterprise environment, a controller outage halts continuous integration and continuous delivery (CI/CD) pipelines and automated remediation. To maintain continuous availability and prevent downtime, platform teams can use a federated multi-cluster deployment managed through GitOps. This approach uses Git repositories as a single source of truth to declaratively manage, automate, and audit Infrastructure as Code (IaC).
End-to-end enterprise architecture
Decoupling platform configuration from workload execution allows GitHub Actions to coordinate deployment while integrating directly with ServiceNow for change governance and Splunk for central logging.
Figure 1 illustrates the end-to-end architecture connecting change governance, GitOps automation, multi-cluster execution, and centralized logging.
This GitOps framework coordinates platform configuration and application delivery across two operational stages.
Declarative infrastructure provisioning (main branch)
Pushing platform updates to the main branch automatically triggers playbooks/configure_aap.yml. The workflow runs inside the quay.io/jopaik/aap-runner:jp1 execution environment, which contains a supported execution environment with Red Hat Ansible Certified Content Collections). It iterates across all gateways (AAP-Platform-DC1 and AAP-Platform-DC2) using ansible.controller modules to establish core automation settings.
During execution, the playbook configures standardized enterprise boundaries and machine SSH keys using encrypted Ansible Vault secrets. It then uses ansible.controller.group to configure multi-datacenter inventory mappings across dc1, dc2, production, and non-production environments. Finally, the workflow synchronizes Git workload repositories (wait: true) and provisions templates with dynamic limit overrides enabled (ask_limit_on_launch: true).
Dynamic workload dispatch (deploy branch)
When deploying application workloads through the deploy branch, playbooks/dispatch_round_robin.yml dynamically routes execution across clusters based on target variables. The playbook evaluates target_aap in deploy_job.yml to filter gateway labels dynamically when targeting an explicit environment such as dc1 or production.
If target_aap is set to auto, job execution alternates evenly across cluster instances using the GitHub index round-robin algorithm. In production environments, dedicated infrastructure such as an F5 load balancer typically handles load balancing.
Key use cases
This architecture supports 3 primary operational scenarios: continuous execution, rolling updates, and platform migrations.
To maintain continuous operations without downtime, platform teams can run business-critical automation tasks across multiple clusters in different geographic regions. Federated multi-cluster topologies also work with Ansible Automation Platform high availability and disaster recovery (HA/DR) architectures to provide a resilient enterprise foundation.
During scheduled maintenance, divert current workloads to dc2 so you can complete operating system (OS) upgrades on Ansible Automation Platform nodes in dc1 without service interruption.
For platform migrations, operate distinct Ansible Automation Platform versions side by side across environments to support a controlled, phased workload transition.
Enterprise integrations: ServiceNow and Splunk
This framework easily integrates with enterprise IT tools: ServiceNow Flow Designer can initiate deployment pipelines when a change request is approved, while Ansible Automation Platform deployments stream event logs directly to centralized analytics platforms such as Splunk.
Next steps
Test this pattern in your own lab by cloning the proof-of-concept repository and running the deployment workflow against your test clusters: Federated Multi-Cluster Red Hat Ansible Automation Platform with GitOps
Have suggestions or improvements for this architecture? Open an issue or submit a pull request in the example repository to help refine the framework.
