第 4 章 Operator 拓扑

下图显示了红帽已经测试过此部署模型的基础架构拓扑，供客户在自我管理 Ansible Automation Platform 时使用：

图 4.1. 基础架构拓扑图

单一节点 OpenShift (SNO)集群已使用以下要求进行测试：32 GB RAM、16 个 CPU、128 GB 本地磁盘和 3000 IOPS。

红帽已测试了以下配置来安装和运行 Red Hat Ansible Automation Platform：

使用以下示例自定义资源(CR)将 Ansible Automation Platform 实例添加到项目中：

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>'

Ansible Automation Platform 的性能特性和容量受到资源分配和配置的影响。使用 OpenShift 时，每个 Ansible Automation Platform 组件都部署为 pod。您可以为每个 pod 指定资源请求和限值。

使用 Ansible Automation Platform 自定义资源(CR)为 OpenShift 安装配置资源分配。每个可配置的项目都有默认设置。这些设置是安装的最低要求，但可能无法满足您的生产工作负载需求。

默认情况下，每个组件的部署会针对最小资源请求设置，但不会设置资源限值。OpenShift 仅调度带有可用资源请求的 pod，但 pod 允许消耗无限的 RAM 或 CPU，只要 OpenShift 工作程序节点本身不在节点压力下。

在 Operator 增长拓扑中，Ansible Automation Platform 部署到具有 32 GB RAM、16 个 CPU、128 GB 本地磁盘和 3000 IOPS 的单节点 OpenShift (SNO)上。这并不是一个共享的环境，因此 Ansible Automation Platform pod 对 OpenShift SNO 的所有计算资源具有完全访问权限。在这种情况下，自动化控制器任务 pod 的容量计算派生自运行 pod 的底层 OpenShift Container Platform 节点。它无法访问整个节点。此容量计算会影响自动化控制器可以运行的并发作业数量。

OpenShift 管理与虚拟机不同的存储。这会影响自动化中心存储其工件的方式。在 Operator 增长拓扑中，我们使用 S3 存储，因为自动化中心需要一个 ReadWriteMany 类型存储，这不是 OpenShift 中的默认存储类型。

Red Hat Ansible Automation Platform 使用多个端口与其服务进行通信。这些端口必须处于打开状态，并可用于 Red Hat Ansible Automation Platform 服务器的传入连接，以便它正常工作。确保这些端口可用，且服务器防火墙不会阻止。