This document outlines the architecture of different deployment topology setups on which our CI tests will run, providing a comprehensive overview of these setups, their components, interactions, and the rationale behind the design choices.

The following matrix defines the topology and environment configurations to target.

These shorthand identifiers make it easier to track which infra type and environment configuration are in use. All "A" type infrastructure topologies are meant for "Standard" deployments, for smaller scale customers. All "B" type topologies are designated "Enterprise" and include additional resources for more robust deployments.

Due to business requirements, we have opted to support environments both fully updated to the latest 2.5 release of AAP, as well as allowing customers to install only Gateway and EDA to connect to their existing 2.4 environments. The intent is to allow customers who are adverse to a full upgrade to experience the enhanced functionality of the Platform Gateway and EDA enterprise functionality.

1. All 2.5 (ENV-A)

   • AAP Gateway 2.5
   • Controller 2.5
   • Private Automation Hub 2.5
   • EDA 2.5

2. EDA-GA (ENV-B) Note: "Mixed versioned" topologies are only supported on RPM-based installation methods

• AAP Gateway 2.5
• Controller 2.4
• Private Automation Hub 2.4
• EDA 2.5

RPM installations are the "classic" way of installing AAP. This always requires multiple VMs; how many is based on which deployment type is chosen.

• 1 VM for AAP Gateway / Unified UI
• 1 VM for Automation Controller
• 1 VM for Private Automation Hub
• 1 VM for Event Driven Ansible
• 1 VM for Automation Mesh Execution Node
• 1 VM Managed Database

• 2 VMs for AAP Gateway / Unified UI
• 2 VMs for Automation Controller
• 2 VMs for Private Automation Hub
• 2 VMs for Event Driven Ansible
• 1 VM for Automation Mesh Hop Node
• 2 VM for Automation Mesh Execution Node
• External unmanaged database service
• HAProxy load balancer in front of AAP Gateway

Containerized installations are being fully supported starting with AAP 2.5. There is both a "single" VM option, requiring very limited infrastructure as well as the "enterprise" deployment, requiring the same number of VMs as the RPM install method.

• All components collocated on a single VM or "All in One (aio)"
• 1 VM for AAP Gateway / Unified UI, Controller, Private Automation Hub, EDA, Managed Database
  • Each component is on a single container

• 2 VMs for AAP Gateway / Unified UI - with redis
• 2 VMs for Automation Controller
• 2 VMs for Private Automation Hub - with redis
• 2 VMs for Event Driven Ansible - with redis
• 1 VM for Automation Mesh Hop Node
• 2 VM for Automation Mesh Execution Node
• External unmanaged database service
• HAProxy load balancer in front of AAP Gateway

Any Red Hat managed deployment will be considered "Enterprise", thus there is no "Standard" deployment available for Managed AAP.

• 1 VM for Hop Node (traditional mesh)
• 1 VM for Execution Node (traditional mesh)
• 1 VM for Execution Node (mesh ingress)

Openshift installations require a Red Hat subscription to Red Hat Openshift Container Platform. Deploying on OCP is only supported via the Operator available in the OCP Operator Marketplace.

• Operator defaults for the deployment

• This specific deployment matches both "Enterprise" OCP and what we provide for our SaaS (AAP as a Service) customers.
  • 1 pod for AAP Gateway / Unified UI
  • 2 pods for Automation Controller
    • task
    • web
  • 5 pods for Private Automation Hub
    • api
    • content
    • web
    • 2 workers
  • x pods for Event Driven Ansible
  • 2 pods for mesh ingress
  • Each pod has 1 replica set configured by default
  • External managed redis service
  • External managed database service

The following ports must be opened on the host machine in order to ensure inter-service communication.

• 22
• 80
• 443
• 6379
• 27199

A platform service that aims to centralize access to the various platform services by SSO configurations, serving the AAP UI and providing a common authentication layer that all of the existing services will be able to integrate.

Serves as the control plane for automation, offering a user interface (UI), RESTful API, role-based access control (RBAC) workflows, and CI/CD integrations.

An overlay network that facilitates the distribution of work across a large and dispersed collection of workers. It achieves this through nodes that establish peer-to-peer connections using existing networks.

Enables automation developers to collaborate and publish their automation content, streamlining the delivery of Ansible code within their organization.

Provides the event-handling capability necessary to automate time-consuming tasks and respond to changing conditions in any IT domain.

A single server rpm install of Redis in the rpm installer will be implemented. This does not support high availability (HA). Ansible supports external Redis deployments for SaaS. Redis HA is deployed and supported for OCP and Containerized Deployments.