Questo contenuto non è disponibile nella lingua selezionata.

Chapter 4. Operator topologies


The Ansible Automation Platform Operator uses Red Hat OpenShift Operators to deploy Ansible Automation Platform within Red Hat OpenShift. Customers manage the product and infrastructure lifecycle.

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.

4.1. Operator growth topology

The growth topology is intended for organizations that are getting started with Ansible Automation Platform and do not require redundancy or higher compute for large volumes of automation. This topology allows for smaller footprint deployments.

4.1.1. Infrastructure topology

The following diagram outlines the infrastructure topology that Red Hat has tested with this deployment model that customers can use when self-managing Ansible Automation Platform:

Figure 4.1. Infrastructure topology diagram

Operator growth topology diagram

A Single Node OpenShift (SNO) cluster has been tested with the following requirements: 32 GB RAM, 16 CPUs, 128 GB local disk, and 3000 IOPS.

Table 4.1. Infrastructure topology
CountComponent

1

Automation controller web pod

1

Automation controller task 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

4.1.2. Tested system configurations

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

Table 4.2. Tested system configurations
TypeDescription

Subscription

Valid Red Hat Ansible Automation Platform subscription

Operating system

Red Hat Enterprise Linux 9.2 or later x86_64 and AArch64

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

PostgreSQL 15

4.1.3. Example custom resource file

Use the following 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>'

4.1.4. Nonfunctional requirements

Ansible Automation Platform’s performance characteristics and capacity are impacted by its resource allocation and configuration. With OpenShift, each Ansible Automation Platform component is deployed 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 are set for minimum resource requests but no resource limits. OpenShift only schedules the pods with available resource requests, but the pods are allowed to consume unlimited RAM or CPU provided that the OpenShift worker node itself is not under node pressure.

In the Operator growth topology, Ansible Automation Platform is deployed 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 the automation controller task pods is derived 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, we use S3 storage because automation hub requires a ReadWriteMany type storage, which is not a default storage type in OpenShift.

4.1.5. Network ports

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

Table 4.3. Network ports and protocols
Port numberProtocolServiceSourceDestination

27199

TCP

Receptor

OpenShift Container Platform cluster

Execution node

27199

TCP

Receptor

OpenShift Container Platform cluster

Hop node

443

HTTPS

Receptor

Execution node

OpenShift Container Platform ingress

443

HTTPS

Receptor

Hop node

OpenShift Container Platform ingress

443

HTTPS

Platform

Customer clients

OpenShift Container Platform ingress

4.2. Operator enterprise topology

The enterprise topology is intended for organizations that require Ansible Automation Platform to be deployed with redundancy or higher compute for large volumes of automation.

4.2.1. Infrastructure topology

The following diagram outlines the infrastructure topology that Red Hat has tested with this deployment model that customers can use when self-managing Ansible Automation Platform:

Figure 4.2. Infrastructure topology diagram

Operator enterprise topology diagram

The following infrastructure topology describes an OpenShift Cluster with 3 master nodes and 2 worker nodes.

Each OpenShift Worker node has been tested with the following component requirements: 16 GB RAM, 4 CPUs, 128 GB local disk, and 3000 IOPS.

Table 4.4. Infrastructure topology
CountComponent

1

Automation controller web pod

1

Automation controller task 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

2

Event-Driven Ansible activation worker pod

2

Event-Driven Ansible default worker pod

2

Event-Driven Ansible event stream pod

1

Event-Driven Ansible scheduler pod

1

Platform gateway pod

2

Mesh ingress pod

N/A

Externally managed database service

N/A

Externally managed Redis

N/A

Externally managed object storage service (for automation hub)

4.2.2. Tested system configurations

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

Table 4.5. Tested system configurations
TypeDescription

Subscription

Valid Red Hat Ansible Automation Platform subscription

Red Hat OpenShift

  • Red Hat OpenShift on AWS Hosted Control Planes 4.15.16

    • 2 worker nodes in different availability zones (AZs) at t3.xlarge

Ansible-core

Ansible-core version 2.16 or later

Browser

A currently supported version of Mozilla Firefox or Google Chrome.

AWS RDS PostgreSQL service

  • engine: "postgres"
  • engine_version: 15"
  • parameter_group_name: "default.postgres15"
  • allocated_storage: 20
  • max_allocated_storage: 1000
  • storage_type: "gp2"
  • storage_encrypted: true
  • instance_class: "db.t4g.small"
  • multi_az: true
  • backup_retention_period: 5

AWS Memcached Service

  • engine: "redis"
  • engine_version: "6.2"
  • auto_minor_version_upgrade: "false"
  • node_type: "cache.t3.micro"
  • parameter_group_name: "default.redis6.x.cluster.on"
  • transit_encryption_enabled: "true"
  • num_node_groups: 2
  • replicas_per_node_group: 1
  • automatic_failover_enabled: true

s3 storage

HTTPS only accessible through AWS Role assigned to automation hub SA at runtime by using AWS Pod Identity

4.2.3. Nonfunctional requirements

Ansible Automation Platform’s performance characteristics and capacity are impacted by its resource allocation and configuration. With OpenShift, each Ansible Automation Platform component is deployed as a pod. You can specify resource requests and limits for each pod.

Use the Ansible Automation Platform custom resource to configure resource allocation for OpenShift installations. Each configurable item has default settings. These settings are the exact configuration used within the context of this reference deployment architecture and presumes that the environment is being deployed and managed by an Enterprise IT organization for production purposes.

By default, each component’s deployments are set for minimum resource requests but no resource limits. OpenShift only schedules the pods with available resource requests, but the pods are allowed to consume unlimited RAM or CPU provided that the OpenShift worker node itself is not under node pressure.

In the Operator enterprise topology, Ansible Automation Platform is deployed on a Red Hat OpenShift on AWS (ROSA) Hosted Control Plane (HCP) cluster with 2 t3.xlarge worker nodes spread across 2 AZs within a single AWS Region. This is not a shared environment, so Ansible Automation Platform pods have full access to all of the compute resources of the ROSA HCP cluster. In this scenario, the capacity calculation for the automation controller task pods is derived from the underlying HCP worker node that runs the pod. It does not have access to the CPU or memory resources of 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 enterprise topology, we use S3 storage because automation hub requires a ReadWriteMany type storage, which is not a default storage type in OpenShift. Externally provided Redis, PostgreSQL, and object storage for automation hub are specified. This provides the Ansible Automation Platform deployment with additional scalability and reliability features, including specialized backup, restore, and replication services and scalable storage.

4.2.4. Network ports

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

Table 4.6. Network ports and protocols
Port numberProtocolServiceSourceDestination

5432

TCP

PostgreSQL

OpenShift Container Platform cluster

External database service

6379

TCP

Redis

OpenShift Container Platform cluster

External Redis service

443

HTTPS

Object storage

OpenShift Container Platform cluster

External object storage service

27199

TCP

Receptor

OpenShift Container Platform cluster

Execution node

27199

TCP

Receptor

OpenShift Container Platform cluster

Hop node

443

HTTPS

Receptor

Execution node

OpenShift Container Platform ingress

443

HTTPS

Receptor

Hop node

OpenShift Container Platform ingress

Red Hat logoGithubRedditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita ilBlog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

© 2024 Red Hat, Inc.