Operator growth topology

The Operator-based growth topology provides a smaller footprint deployment without redundancy for organizations getting started with Ansible Automation Platform on Red Hat OpenShift Container Platform.

Included are the tested infrastructure topology, system requirements, network port configurations, and an example custom resource file for installation.

Important

You can only install a single instance of the Ansible Automation Platform Operator into a single namespace. Installing multiple instances in the same namespace can lead to improper operation for both Operator instances.

Infrastructure topology
Copy link

The Red Hat tested infrastructure topology for this deployment model:

Figure 1. Infrastructure topology diagram

Operator growth topology diagram
Important

While Redis and PostgreSQL can be installed as part of the operator-based installation process, the topology diagram represents a Red Hat supported topology where both Redis and PostgreSQL are external to Ansible Automation Platform.

Red Hat tests a Single Node OpenShift (SNO) cluster with these requirements: 32 GB RAM, 16 CPUs, 128 GB local disk, and 3000 IOPS.

Expand
Table 1. Infrastructure topology components
Count Component

1

Automation controller web pod

1

Automation controller task pod

1

Automation hub web pod

1

Automation hub API pod

2

Automation hub content pod

2

Automation hub worker pod

1

Automation hub Redis pod

1

Event-Driven Ansible API pod

1

Event-Driven Ansible activation worker pod

1

Event-Driven Ansible default worker pod

1

Event-Driven Ansible event stream pod

1

Event-Driven Ansible scheduler pod

1

Platform gateway pod

1

Database pod

1

Redis pod
Note

You can deploy multiple isolated instances of Ansible Automation Platform into the same Red Hat OpenShift Container Platform cluster. To do this, use a namespace-scoped deployment model (isolated within a namespace).

This approach allows you to use the same cluster for several deployments.

Tested system configurations
Copy link

Red Hat has tested these configurations to install and run Red Hat Ansible Automation Platform:

Expand
Table 2. Tested system configurations
Type Description Notes

Subscription

Valid Red Hat Ansible Automation Platform subscription

Red Hat OpenShift
  • Version: 4.14
  • num_of_control_nodes: 1
  • num_of_worker_nodes: 1

Ansible-core

Ansible-core version 2.16 or later

Browser

A currently supported version of Mozilla Firefox or Google Chrome.

Database
  • For Ansible Automation Platform managed databases: PostgreSQL 15
  • For customer provided (external) databases: PostgreSQL 15, 16, or 17.
  • External (customer supported) databases require International Components for Unicode (ICU) support.
  • External databases using PostgreSQL 16 or 17 must rely on external backup and restore processes. Backup and restore functionality depends on utilities provided with PostgreSQL 15.
Warning

Operator-deployed database connection limits

The operator-deployed PostgreSQL database has a default max_connections limit of 100 and a maximum database size of 100 GB.

Do not use the operator-deployed database if any of the following conditions apply:

  • You are running more than 1 replica of any component (platform gateway, automation controller, automation hub, or Event-dDriven Ansible).
  • The automation controller capacity exceeds 100 concurrent jobs.
  • Total database connections from all components exceed 100.
  • Estimated 30-day database storage exceeds 100 GB.

If your deployment exceeds any of these limits, use an external database instead of the operator-deployed database.

Database storage consumption depends on your workload, including job frequency, playbook task count, output verbosity, and the number of managed hosts per job. Higher verbosity levels can increase storage consumption by 3-5x.

IP version

IPv4, IPv6 (single-stack and dual-stack)

Example custom resource file
Copy link

Use this example custom resource (CR) to add your Ansible Automation Platform instance to your project:

apiVersion: aap.ansible.com/v1alpha1
kind: AnsibleAutomationPlatform
metadata:
  name: <aap instance name>
spec:
  eda:
    automation_server_ssl_verify: 'no'
  hub:
    storage_type: 's3'
    object_storage_s3_secret: '<name of the Secret resource holding s3 configuration>'

Nonfunctional requirements
Copy link

Ansible Automation Platform’s performance characteristics and capacity depend on its resource allocation and configuration. With OpenShift, each Ansible Automation Platform component deploys as a pod. You can specify resource requests and limits for each pod.

Use the Ansible Automation Platform Custom Resource (CR) to configure resource allocation for OpenShift installations. Each configurable item has default settings. These settings are the minimum requirements for an installation, but might not meet your production workload needs.

By default, each component’s deployments use minimum resource requests but no resource limits. OpenShift only schedules pods with available resource requests, but the pods can consume unlimited RAM or CPU as long as the OpenShift worker node itself is not under node pressure.

In the Operator growth topology, Ansible Automation Platform runs on a Single Node OpenShift (SNO) with 32 GB RAM, 16 CPUs, 128 GB local disk, and 3000 IOPS. This is not a shared environment, so Ansible Automation Platform pods have full access to all of the compute resources of the OpenShift SNO. In this scenario, the capacity calculation for automation controller task pods comes from the underlying OpenShift Container Platform node that runs the pod. It does not have access to the entire node. This capacity calculation influences how many concurrent jobs automation controller can run.

OpenShift manages storage distinctly from VMs. This impacts how automation hub stores its artifacts. In the Operator growth topology, the topology uses S3 storage because automation hub requires a ReadWriteMany type storage, which is not a default storage type in OpenShift.

Network ports
Copy link

Red Hat Ansible Automation Platform uses several ports to communicate with its services. These ports must be open and available for Red Hat Ansible Automation Platform to work. Ensure that these ports are available and are not blocked by a firewall.

Expand
Table 3. Network ports and protocols
Port number Protocol Service Source Destination

80/443

HTTP/HTTPS

Receptor

Execution node

OpenShift Container Platform ingress

80/443

HTTP/HTTPS

Receptor

Hop node

OpenShift Container Platform ingress

80/443

HTTP/HTTPS

Platform

Customer clients

OpenShift Container Platform ingress

27199

TCP

Receptor

OpenShift Container Platform cluster

Execution node

27199

TCP

Receptor

OpenShift Container Platform cluster

Hop node