Operator growth topology

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

Infrastructure topology

The Red Hat tested infrastructure topology for this deployment model:

Red Hat tests a Single Node OpenShift (SNO) cluster with these requirements:

Tested system configurations

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

Example custom resource file

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>'
metrics:
    disabled: false

Metrics service configuration

spec.metrics.disabled: false - Enables metrics service deployment (default: false, meaning enabled)

• Setting disabled: true will prevent metrics service deployment
• The operator automatically creates a MetricsService CR named <aap-name>-metrics

Metrics service automatic provisioning

The operator handles all metrics service deployment details automatically:

Database provisioning

The operator automatically creates:

• metrics_service database with full permissions for the metrics_service user
• ms_awx_readonly user in the automation controller database with SELECT-only permissions
• All database connection secrets as Kubernetes secrets

No manual database setup required for operator deployments with managed databases.

Secrets management

The operator creates and manages these Kubernetes secrets:

• <aap-name>- automationmetrics-pg-password - Metrics database credentials
• <aap-name>- automationmetrics-controller-read-pg-password - Read-only controller database credentials
• <aap-name>- automationmetrics-secret-key - Django secret key
• <aap-name>- automationmetrics-resource-server - Resource server configuration

Gateway routing

The operator configures Envoy routing through platform gateway:

• Dashboard requests route to /api/metrics/ endpoint
• Internal communication between gateway and metrics service web pod
• No external exposure of metrics service (access only through gateway)

ConfigMap

Configuration is managed via ConfigMap:

• <aap-name>- metrics-env-properties - Contains all metrics service environment variables including feature flags

External database configuration

When using an external database (not operator-managed), you must manually provision the metrics service databases before deployment.

Create metrics_service database:

CREATE DATABASE metrics_service
  WITH ENCODING='UTF8'
       LC_COLLATE='en_US.UTF-8'
       LC_CTYPE='en_US.UTF-8'
       TEMPLATE=template0;

CREATE USER metrics_service WITH PASSWORD '<secure_password>';
GRANT ALL PRIVILEGES ON DATABASE metrics_service TO metrics_service;
\c metrics_service
GRANT ALL ON SCHEMA public TO metrics_service;

Create read-only user for controller database:

CREATE USER ms_awx_readonly WITH PASSWORD '<readonly_password>';
\c awx  -- Connect to controller database
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ms_awx_readonly;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO ms_awx_readonly;

Configure external database in CR:

spec:
  metrics:
    disabled: false
    postgres_configuration_secret: <secret-name-with-db-credentials>

Nonfunctional requirements

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

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.