第4章 Operator トポロジー

次の図は、このデプロイメントモデルを使用して Red Hat がテストしたインフラストラクチャートポロジーの概要を示しています。このモデルは、お客様が Ansible Automation Platform を自己管理する際に使用できるものです。

図4.1 インフラストラクチャートポロジー図

シングルノード OpenShift (SNO) クラスターは、32 GB RAM、16 CPU、128 GB ローカルディスク、3000 IOPS という要件でテストされています。

Red Hat は、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 のリソース要求と制限を指定できます。

OpenShift インストールのリソースの割り当ては、Ansible Automation Platform カスタムリソース (CR) を使用して設定します。設定可能な各項目にはデフォルト設定があります。これらの設定はインストールの最小要件ですが、実稼働ワークロードのニーズを満たさない可能性があります。

デフォルトでは、各コンポーネントのデプロイメントは最小限のリソース要求に設定されていますが、リソース制限はありません。OpenShift は、利用可能なリソース要求を持つ Pod のみをスケジュールします。ただし、OpenShift ワーカーノード自体がプレッシャーを受けていない限り、Pod は RAM または CPU を無制限に消費できます。

Operator グローストポロジーでは、Ansible Automation Platform を、32 GB RAM、16 CPU、128 GB のローカルディスク、3000 IOPS を備えた Single Node OpenShift (SNO) にデプロイします。これは共有環境ではないため、Ansible Automation Platform の Pod に、OpenShift SNO のすべてのコンピュートリソースに対するフルアクセス権が付与されます。この場合、Automation Controller のタスク Pod の容量計算が、Pod を実行する基盤となる OpenShift Container Platform ノードに基づいて行われます。ノード全体にはアクセスできません。この容量計算は、Automation Controller が実行できる同時ジョブの数に影響します。

OpenShift は仮想マシンとは別にストレージを管理します。これは、Automation Hub がアーティファクトを保存する方法に影響します。Operator グローストポロジーでは、S3 ストレージを使用します。Automation Hub には、OpenShift のデフォルトのストレージタイプではない ReadWriteMany タイプのストレージが必要であるためです。

Red Hat Ansible Automation Platform は、サービスとの通信に複数のポートを使用します。Red Hat Ansible Automation Platform サーバーを機能させるには、これらのポートを開いてサーバーへの着信接続に利用できるようにする必要があります。これらのポートが利用可能で、サーバーのファイアウォールでブロックされていないことを確認してください。