Event-Driven Ansible Controller ユーザーガイド
Event-Driven Ansible Controller を設定して使用し、自動化を強化および拡張する方法
概要
はじめに リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible Controller は、一貫性と復元力を実現しながら IT の速度と俊敏性を向上させることで、自動化を強化および拡張する新しい方法です。Red Hat によって開発されたこの機能は、シンプルさと柔軟性を考慮して設計されています。
Red Hat ドキュメントへのフィードバック (英語のみ) リンクのコピーリンクがクリップボードにコピーされました!
このドキュメントの改善に関するご意見がある場合や、エラーを発見した場合は、https://access.redhat.com から Technical Support チームに連絡してください。
第1章 Event-Driven Ansible Controller の概要 リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible は、他のソフトウェアベンダーのモニタリングツールなどのイベントソースと連携する、拡張性が高く柔軟な自動化機能です。このようなツールは、IT ソリューションを監視してイベントを特定し、ルールブックに記述された変更や対応を自動的に実装して、そのイベントを処理します。
ユーザー設定は次の手順で行います。
Event-Driven Ansible Controller の API ドキュメントは、https://<eda-server-host>/api/eda/v1/docs で入手できます。
第2章 Event-Driven Ansible Controller の認証情報のセットアップ リンクのコピーリンクがクリップボードにコピーされました!
認証情報は、ルールブックの起動時に、Event-Driven Ansible が認証するために使用されます。
2.1. 認証情報のセットアップ リンクのコピーリンクがクリップボードにコピーされました!
プライベートリポジトリー (GitHub または GitLab) あるいはプライベートコンテナーレジストリーで使用する認証情報を作成します。
GitHub または GitLab リポジトリーを使用している場合は、basic auth メソッドを使用します。両方の SCM サーバーが正式にサポートされています。basic auth をサポートする SCM プロバイダーを使用できます。
手順
- Event-Driven Ansible Controller ダッシュボードにログインします。
- ナビゲーションパネルから → を選択します。
- をクリックします。
以下を入力します。
- Name
- 名前を入力します。
- Description
- このフィールドは任意です。
- 認証情報タイプ
- 利用できるオプションは、GitHub パーソナルアクセストークン、GitLab パーソナルアクセストークン、またはコンテナーレジストリーです。
- Username
- ユーザー名を挿入します。
- Token
宛先への認証を可能にするトークンを挿入します。
注記コンテナーレジストリーを使用している場合、トークンフィールドは、レジストリープロバイダーに応じてトークンまたはパスワードにすることができます。Ansible Automation Platform ハブレジストリーを使用している場合は、そのパスワードを token フィールドに挿入します。
- をクリックします。
認証情報を保存すると、認証情報の詳細ページが表示されます。詳細ページまたは Credentials リストビューから、認証情報を編集または削除できます。
2.2. 認証情報のリストビュー リンクのコピーリンクがクリップボードにコピーされました!
Credentials ページで、認証情報の Type とともに作成した、作成済みの認証情報のリストを表示できます。
メニューバーの Name フィールドで、認証情報を検索できます。
メニューバーには、以下のオプションもあります。
- をクリックして、リストビューに表示する列を選択します。
- アイコンをクリックして、 または のいずれかを選択します。
2.3. 認証情報の編集 リンクのコピーリンクがクリップボードにコピーされました!
手順
以下のいずれかの方法を使用して、認証情報を編集します。
- Credentials リストビューで、必要な認証情報の横にある アイコンをクリックします。
- Credentials リストビューで認証情報の名前を選択し、 をクリックします。
- 適切な詳細を編集し、 をクリックします。
2.4. 認証情報の削除 リンクのコピーリンクがクリップボードにコピーされました!
手順
以下のいずれかの方法を使用して、認証情報を削除します。
- Credentials リストビューで、必要な認証情報の横にある アイコン ⋮ をクリックし、 をクリックします。
- Credentials リストビューで認証情報の名前を選択し、 の横にある アイコン ⋮ をクリックして、 をクリックします。
- ポップアップウィンドウで、Yes, I confirm to delete this credential を選択します。
- をクリックします。
各認証情報の横にあるチェックボックスを選択し、メニューバーの アイコン ⋮ をクリックしてから、 をクリックして、一度に複数の認証情報を削除できます。
第3章 プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトはルールブックの論理的なコレクションです。これは git リポジトリーである必要があり、http プロトコルのみがサポートされます。プロジェクトのルールブックは、Ansible コレクション内の Event-Driven Ansible コンテンツ用に定義されたパス (プロジェクトのルートにある /extensions/eda/rulebooks) に配置する必要があります。
3.1. 新しいプロジェクトの設定 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- Event-Driven Ansible Controller ダッシュボードに Content Consumer としてログインしている。
- 必要に応じて、認証情報が設定されている。詳細は、認証情報のセットアップ セクションを参照してください。
- Automation Controller が使用する、リポジトリーに含まれている Playbook と統合されたルールブックを含む既存のリポジトリーがある。
手順
- Event-Driven Ansible Controller ダッシュボードにログインします。
- ナビゲーションパネルから、 → を選択します。
以下を入力します。
- Name
- プロジェクト名を入力します。
- Description
- このフィールドは任意です。
- SCM type
- Git のみ使用できます。
- SCM URL
GitHub や GitLab などのリポジトリーの HTTP[S] プロトコルアドレス。
注記プロジェクトの作成後に SCM URL を編集することはできません。
- Credential
- このフィールドは任意です。これは、SCM URL を利用するために必要なトークンです。
- オプション
Verify SSL オプションはデフォルトで有効になっています。このオプションが有効になっていると、プロジェクトのインポート時に SSL が HTTPS で検証されます。
注記自己署名付き証明書を使用するローカルリポジトリーがある場合は、このオプションを無効にできます。
- を選択します。
プロジェクトが作成され、Projects 画面で管理できるようになります。
新しいプロジェクトを保存すると、プロジェクトの詳細ページが表示されます。詳細ページまたは Projects リストビューから、プロジェクトを編集または削除できます。
3.2. Projects リストビュー リンクのコピーリンクがクリップボードにコピーされました!
Projects ページでは、作成したプロジェクトを ステータス および Git ハッシュ とともに確認できます。
ソース管理でルールブックが変更された場合は、Projects リストビューでプロジェクトの横にある同期アイコンを選択することで、プロジェクトを再同期できます。Git ハッシュ の更新は、そのリポジトリー上の最新のコミットを表します。更新されたプロジェクトを使用する場合は、アクティベーションを再開または再作成する必要があります。
3.3. プロジェクトの編集 リンクのコピーリンクがクリップボードにコピーされました!
手順
- Projects リストビューで、目的のプロジェクトの横にある アイコン ⋮ を選択します。
- を選択します。
- 必要な変更を入力し、 を選択します。
3.4. プロジェクトの削除 リンクのコピーリンクがクリップボードにコピーされました!
手順
- Projects リストビューで、目的のプロジェクトの横にある アイコン ⋮ を選択します。
- を選択します。
- ポップアップウィンドウで、 を選択します。
- を選択します。
第4章 決定環境 リンクのコピーリンクがクリップボードにコピーされました!
決定環境は、Ansible ルールブックを実行するためのコンテナーイメージです。決定環境は、自動化の依存関係を伝達するための共通言語を作成し、自動化環境をビルドおよび配布するための標準的な方法を提供します。デフォルトの決定環境は Ansible-Rulebook にあります。
独自の決定環境を作成するには、Ansible Automation Platform 内での Event-Driven Ansible のカスタム決定環境のビルド を参照してください。
4.1. 新しい決定環境の設定 リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、Event-Driven Ansible Controller ダッシュボードに決定環境をインポートする方法を説明します。
前提条件
- Event-Driven Ansible Controller ダッシュボードに Content Consumer としてログインしている。
- 必要に応じて、認証情報が設定されている。詳細は、認証情報のセットアップ セクションを参照してください。
-
決定環境イメージをイメージリポジトリーにプッシュしたか、registry.redhat.io で提供されている
de-supportedイメージを使用することを選択した。
手順
- Event-Driven Ansible Controller ダッシュボードに移動します。
- ナビゲーションパネルから を選択します。
以下を入力します。
- Name
- 名前を入力します。
- Description
- このフィールドは任意です。
- Image
- これは、コンテナーレジストリー、イメージ名、およびバージョンタグを含む完全なイメージの場所です。
- Credential
- このフィールドは任意です。これは、決定環境イメージを利用するために必要なトークンです。
- を選択します。
これで決定環境が作成され、Decision Environments 画面で管理できるようになります。
新しい決定環境を保存すると、決定環境の詳細ページが表示されます。詳細ページまたは Decision Environment リストビューから、決定環境を編集または削除できます。
4.2. Ansible Automation Platform 内での Event-Driven Ansible のカスタム決定環境のビルド リンクのコピーリンクがクリップボードにコピーされました!
デフォルトの意思決定環境にはないカスタム管理やサードパーティーのイベントソースプラグインを提供するためにカスタム意思決定環境が必要な場合は、次の手順に従います。
前提条件
- Ansible Automation Platform 2.4 以降
- Event-Driven Ansible
- Ansible Builder 3.0 以降
手順
de-supported決定環境を追加します。このイメージは、de-minimalと呼ばれる Red Hat が提供するベースイメージからビルドされます。注記Red Hat は、Ansible Builder でベースイメージとして
de-minimalを使用して、カスタム決定環境をビルドすることを推奨しています。
以下は、ansible.eda コレクションでカスタム決定環境をビルドするために、ベースイメージとして de-minimal を使用する Ansible Builder 定義ファイルの例です。
さらに、他の Python パッケージまたは RPM が必要な場合は、1 つの定義ファイルに以下を追加します。
第5章 Automation Controller トークンの設定 リンクのコピーリンクがクリップボードにコピーされました!
Automation Controller には、Event-Driven Ansible ルールブックと連携するように設計された Playbook を含むリポジトリーをベースとしたプロジェクトが含まれている必要があります。Automation Controller には、そのプロジェクト内の Playbook に基づいて設定された対応するジョブテンプレートも必要です。
5.1. Automation Controller への認証のためのトークンのセットアップ リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- Event-Driven Ansible Controller ダッシュボードに Content Consumer としてログインしている。
- ユーザーを作成している。
- Event-Driven Ansible Controller ダッシュボードにログインできるか、組織内のユーザーとして追加されている。
手順
- Event-Driven Ansible Controller ダッシュボードに移動します。
- 上部のナビゲーションパネルからプロファイルを選択します。
- User details に移動します。
- → を選択します。
以下を入力します。
- Name
- 名前を入力します。
- Description
- このフィールドは任意です。
- Token
Automation Controller でトークンを作成します。トークンの作成の詳細は、Automation Controller ユーザーガイドの ユーザー - トークン セクションを参照してください。
注記トークンは書き込みスコープ内にある必要があり、割り当てられたユーザーの場合は、ジョブおよびワークフローテンプレートを実行する権限を持っている必要があります。
- を選択します。
新しいトークンを保存すると、Controller Tokens タブが表示され、そこでトークンを削除できます。
第6章 ルールブックアクティベーション リンクのコピーリンクがクリップボードにコピーされました!
ルールブックアクティベーションは、特定のルールブックを実行する決定環境によって定義されるバックグラウンドで実行されるプロセスです。
6.1. ルールブックアクティベーションの設定 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- Event-Driven Ansible Controller ダッシュボードに Content Consumer としてログインしている。
- プロジェクトを設定している。
- 決定環境を設定している。
- Automation Controller のトークンを設定している。
手順
- Event-Driven Ansible Controller ダッシュボードに移動します。
- ナビゲーションパネルから を選択します。
以下を入力します。
- Name
- 名前を入力します。
- Description
- このフィールドは任意です。
- Project
- プロジェクトはルールブックの論理的なコレクションです。
- Rulebook
- 選択したプロジェクトに応じてルールブックが表示されます。
- Decision environment
決定環境は、Ansible ルールブックを実行するためのコンテナーイメージです。
注記Event-Driven Ansible コントローラーでは、Decision environment のプルポリシーをカスタマイズできません。デフォルトでは、always ポリシーの動作に従います。アクティベーションが開始されるたびに、システムはイメージの最新バージョンを取得しようとします。
- Restart policy
これは、ルールブックを再起動する条件を決定するためのポリシーです。
Policies:
- Always: ルールブック終了時に再起動します。
- Never: 終了時にルールブックを再起動しません。
- On failure: 失敗した場合にのみ再起動します。
- Rulebook activation enabled?
- これを選択すると、ルールブックアクティベーションが自動的に有効になります。
- Variables
-
ルールブックの変数は JSON/YAML 形式です。内容は、ansible-rulebook コマンドの
--varsフラグによって渡されるファイルと同等です。
- をクリックします。
ルールブックアクティベーションが作成され、Rulebook Activations 画面で管理できるようになります。
新しいルールブックアクティベーションを保存すると、ルールブックアクティベーションの詳細ページが表示されます。詳細ページまたは Rulebook Activations リストビューから、ルールブックアクティベーションを編集または削除できます。
ソースプラグインのシャットダウンが原因で、ルールブックが正常に終了するまでに一定の時間かかることがあります。ルールブックアクティベーションがシャットダウンすると、待機しているすべてのタスクがキャンセルされ、info レベルのメッセージがアクティベーションログに送信されます。詳細は、Rulebooks を参照してください。
6.2. ルールブックアクティベーションのリストビュー リンクのコピーリンクがクリップボードにコピーされました!
Rulebook Activations ページでは、作成したルールブックアクティベーションを、アクティベーションステータス、ルールブックに 関連付けられたルールの数、起動数、および 再起動数 とともに確認できます。
Activation Status が Running の場合、ルールブックのアクティベーションがバックグラウンドで実行されており、ルールブックで宣言されたルールに従って必要なアクションが実行されていることを意味します。
Rulebook Activations リストビューからアクティベーションを選択すると、詳細を確認できます。
実行されたすべてのアクティベーションについて、Details タブと History タブを表示して、実行結果に関する詳細情報を取得できます。
6.2.1. アクティベーションの出力の表示 リンクのコピーリンクがクリップボードにコピーされました!
アクティベーションの出力は History タブで確認できます。
手順
- タブを選択して、すべてのアクティベーションインスタンスのリストにアクセスします。1 つのアクティベーションインスタンスは、1 回のアクティベーションの実行を表します。
- 対象のアクティベーションインスタンスを選択すると、その特定の実行によって生成された Output が表示されます。
アクションをトリガーした受信イベントを表示するには、Event-Driven Ansible コントローラーダッシュボードの Rule Audit セクションを使用できます。
6.3. ルールブックアクティベーションの有効化および無効化 リンクのコピーリンクがクリップボードにコピーされました!
- 行レベルのスイッチを選択して、選択したルールブックを有効または無効にします。
- ポップアップウィンドウで、 選択します。
- を選択します。
6.4. ルールブックアクティベーションの再起動 リンクのコピーリンクがクリップボードにコピーされました!
ルールブックアクティベーションが現在有効であり、作成時に再起動ポリシーが Always に設定されていた場合にのみ、ルールブックアクティベーションを再起動できます。
- Rulebook Activation enabled/disabled トグルの横にある アイコン ⋮ を選択します。
- を選択します。
- ポップアップウィンドウで、 を選択します。
- を選択します。
6.5. ルールブックアクティベーションの削除 リンクのコピーリンクがクリップボードにコピーされました!
- Rulebook Activation enabled/disabled トグルの横にある アイコン ⋮ を選択します。
- を選択します。
- ポップアップウィンドウで、 を選択します。
- を選択します。
6.6. Webhook ルールブックのアクティブ化 リンクのコピーリンクがクリップボードにコピーされました!
Openshift 環境では、ルールブックアクティベーションの Kubernetes サービスを公開するルートを作成することで、Webhook が特定のポートを介して activation-job-pod に到達できるようにすることが可能です。
前提条件
- Event-Driven Ansible Controller ダッシュボードでルールブックアクティベーションを作成している。
特定の Webhook を含むルールブックの例を以下に示します。
手順
サービスを公開するためのルートを (OpenShift Container Platform 上に) 作成します。以下は、決定環境 Pod のポート 5000 で POST を要求する ansible-rulebook ソースのルートの例です。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルートを作成したら、ルート URL へのポスト を使用してテストします。
curl -H "Content-Type: application/json" -X POST test-sync-bug-dynatrace.apps.aap-dt.ocp4.testing.ansible.com -d '{}'curl -H "Content-Type: application/json" -X POST test-sync-bug-dynatrace.apps.aap-dt.ocp4.testing.ansible.com -d '{}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ポートはルート (targetPort) で指定されているため、必要ありません。
6.7. Kubernetes を使用したテスト リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes を使用すると、Ingress の作成やポートの公開を行うことができます。ただし、これは実稼働環境用のものではありません。
手順
次のコマンドを実行して、クラスター上の特定のサービスのポートを公開します。
kubectl port-forward svc/<ACTIVATION_SVC_NAME> 5000:5000
kubectl port-forward svc/<ACTIVATION_SVC_NAME> 5000:5000Copy to Clipboard Copied! Toggle word wrap Toggle overflow localhost:5000に対して HTTP リクエストを実行して、ルールブックをトリガーします。curl -H "Content-Type: application/json" -X POST test-sync-bug-dynatrace.apps.aap-dt.ocp4.testing.ansible.com -d '{}'curl -H "Content-Type: application/json" -X POST test-sync-bug-dynatrace.apps.aap-dt.ocp4.testing.ansible.com -d '{}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第7章 ルール監査 リンクのコピーリンクがクリップボードにコピーされました!
ルール監査では、ある時点においてアクティブ化されたすべてのルールによってトリガーされたルールを監査できます。
Rule Audit リストビューには、ルールブック内の条件と一致してアクションをトリガーしたイベントを受信した各タイミングのリストが表示されます。リストにはルールブック内のルールが表示され、各見出しに実行されたルール名が表示されます。
7.1. ルール監査の詳細の表示 リンクのコピーリンクがクリップボードにコピーされました!
Rule Audit リストビューから、特定のアクションをトリガーしたイベントを確認できます。
手順
- ナビゲーションパネルから を選択します。
- 目的のルールを選択すると、Details タブが表示されます。
ここから、作成日時、最後に起動した日時、および対応するルールブックアクティベーションを確認できます。
7.2. ルール監査イベントの表示 リンクのコピーリンクがクリップボードにコピーされました!
手順
- ナビゲーションパネルから を選択します。
- 目的のルールを選択すると、Details タブが表示されます。アクションをトリガーしたすべてのイベントを表示するには、Events タブを選択します。選択すると、アクションをトリガーしたイベントが表示されます。
- イベントを選択すると、Event log が Source type と Timestamp とともに表示されます。
7.3. ルール監査アクションの表示 リンクのコピーリンクがクリップボードにコピーされました!
手順
- ナビゲーションパネルから を選択します。
- 目的のルールを選択すると、Actions タブが表示されます。
ここから、実行されたアクションを確認できます。一部のアクションは Automation Controller にリンクされています。そこで出力を確認できます。
第8章 Event-Driven Ansible Controller のパフォーマンスチューニング リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible は、非常にスケーラブルで柔軟な自動化機能です。Event-Driven Ansible Controller は、Event-Driven Ansible による自動化を実行するインターフェイスを提供します。Event-Driven Ansible Controller をチューニングし、次の方法でパフォーマンスとスケーラビリティーを最適化します。
- ワークロードの特徴付け
- システムレベルの監視
- パフォーマンスのトラブルシューティング
8.1. ワークロードの特徴付け リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible Controller では、ワークロードに、受信したルールブックアクティベーションとイベントの数が含まれます。Event-Driven Ansible Controller ワークロードを特徴付けるために、次の要素を考慮してください。
- ルールブックの同時アクティベーションの数
- Event-Driven Ansible Controller が受信したイベントの数
8.1.1. ルールブックの同時アクティベーションの数の変更 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Event-Driven Ansible Controller は 12 のルールブックアクティベーションを同時に実行できます。12 を超えるルールブックアクティベーションが作成されると、ルールブックアクティベーションワーカーが利用可能になるまで、後続のルールブックアクティベーションが保留中として待機することが予想されます。この場合、Event-Driven Ansible Controller インスタンスに空きメモリーと CPU が十分にある場合でも、ルールブックアクティベーションのステータスは “pending” と表示されます。この動作を変更するには、実行中のルールブックアクティベーションのデフォルトの最大数を変更する必要があります。
注記: EDA_MAX_RUNNING_ACTIVATIONS の値は、インスタンスサイズが変更されても変更されないため、手動で調整する必要があります。
8.1.1.1. Event-Driven Ansible Controller のインストール時に、ルールブックの同時アクティベーションの数を変更する リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Event-Driven Ansible Controller は 12 つのアクティベーションを同時に実行できます。以下の手順を使用して、インストール時にこのデフォルト値を変更できます。
手順
仮想マシンインストーラーに変数を指定します。
- セットアップインベントリーファイルに移動します。
-
[all:vars] セクションに
automationedacontroller_max_running_activationsを追加します。たとえば、automationedacontroller_max_running_activations=16などです。 - セットアップを実行します。
8.1.1.2. Event-Driven Ansible Controller のインストール後に、ルールブックの同時アクティベーションの数を変更する リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Event-Driven Ansible Controller は 12 つのアクティベーションを同時に実行できます。以下の手順を使用して、インストール後にこのデフォルト値を変更できます。
手順
-
/etc/ansible-automation-platform/edaの環境ファイルに移動します。 -
必要な実行中のアクティベーションの最大数を選択します。たとえば、
EDA_MAX_RUNNING_ACTIVATIONS = 16などです。 -
systemctl restart automation-eda-controller.targetコマンドを使用して、EDA サービスを再起動します。
関連情報
ルールブックアクティベーションの詳細は、ルールブックアクティベーション を参照してください。
8.1.2. ルールブックアクティベーションごとのデフォルトのメモリー制限の変更 リンクのコピーリンクがクリップボードにコピーされました!
メモリー使用量は、Event-Driven Ansible Controller が処理する必要のあるイベントの数に基づいています。各ルールブックアクティベーションコンテナーには、200MB のメモリー制限があります。たとえば、CPU が 4 個、RAM が 16 GB の場合、割り当てられたメモリー制限が 200 MB のルールブックアクティベーションコンテナー 1 つでは、1 分あたり 150,000 件を超えるイベントを処理できません。並行して実行されるルールブックアクティベーションの数が多い場合は、各ルールブックアクティベーションが処理できるイベントの最大数は少なくなります。非常に高いレートでの受信イベントが多すぎる場合、コンテナーはイベントを処理しようとしてメモリー不足になる可能性があります。これによりコンテナーが強制終了され、ルールブックアクティベーションはステータスコード 137 で失敗します。
この障害に対処するには、次のいずれかの手順を使用して、ルールブックアクティベーションに割り当てられるメモリーの量を増やし、多数のイベントを高いレートで処理できるようにします。
- インストール中に、ルールブックアクティベーションごとにデフォルトのメモリー制限を変更する
- インストール後に、ルールブックアクティベーションごとにデフォルトのメモリー制限を変更する
8.1.2.1. インストール中に、ルールブックアクティベーションごとにデフォルトのメモリー制限を変更する リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、ルールブックアクティベーションコンテナーごとに 200MB のメモリー制限があります。以下の手順を使用して、インストール時にこのデフォルト値を変更できます。
手順
- セットアップインベントリーファイルに移動します。
-
[all:vars] セクションに
automationedacontroller_podman_mem_limitを追加します。たとえば、automationedacontroller_podman_mem_limit='400m'などです。 - セットアップを実行します。
8.1.2.2. インストール後に、ルールブックアクティベーションごとにデフォルトのメモリー制限を変更する リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、ルールブックアクティベーションコンテナーごとに 200MB のメモリー制限があります。以下の手順を使用して、インストール後にこのデフォルト値を変更できます。
手順
-
/etc/ansible-automation-platform/edaの環境ファイルに移動します。 -
デフォルトのコンテナーのメモリー制限を変更します。たとえば、
EDA_PODMAN_MEM_LIMIT = '300m'などです。 -
systemctl restart automation-eda-controller.targetを使用して、Event-Driven Ansible Controller サービスを再起動します。
8.2. Event-Driven Ansible Controller のシステムレベルの監視 リンクのコピーリンクがクリップボードにコピーされました!
ワークロードを特徴付けし、並行して実行しているルールブックのアクティベーションの数と、特定の時点で受信しているイベントの数を特定した後、システムレベルで Event-Driven Ansible Controller ホストを監視することを検討する必要があります。システムレベルのモニタリングを使用して、Event-Driven Ansible のパフォーマンスに関する情報を時間の経過とともに確認することで、問題を診断したり、将来的な容量の増加を検討したりする場合に役立ちます。
システムレベルの監視では、次の情報が含まれます。
- ディスク I/O
- RAM 使用率
- CPU の使用率
- ネットワークトラフィック
CPU、RAM、またはディスクの使用率が高いと、Event-Driven Ansible Controller の全体的なパフォーマンスに影響を与える可能性があります。たとえば、これらのシステムレベルリソースのうち、使用率が高い場合は、Event-Driven Ansible Controller が実行しているルールブックアクティベーションが多すぎるか、または個々のルールブックアクティベーションの一部で大量のリソースを使用していることを示しています。このような場合は、ワークロードをサポートするためにシステムレベルのリソースを増やす必要があります。
8.3. Event-Driven Ansible Controller のパフォーマンストラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible Controller のデフォルトパラメーターに基づいて、ワークロードを完了するのに課題となるシナリオが発生する可能性があります。次のセクションでは、これらのシナリオおよびトラブルシューティングのガイダンスについて説明します。
アクティベーションのステータスは "running" と表示されますが、イベントを処理していません。
- ルールブックアクティベーションで正しいイベントソースを使用していることを確認します。ルールブック以外のソースから発生するイベントを想定している場合は、Event-Driven Ansible Controller はそのイベントを処理しません。
アクティベーションステータスは "running" と表示され、Event-Driven Ansible Controller もイベントを受信していますが、アクションが実行されません。
- ルールブックアクティベーションでイベントの一致とアクションの実行に対して、正しい条件を設定していることを確認します。
アクティベーションは無限ループで再起動し続けます。
デフォルトでは、ルールブックアクティベーションのリセットポリシーは "on failure" に設定されています。以下の手順を使用して、Restart Policy を変更します。
- Rulebook Activation 画面に移動します。
- Restart Policy ドロップダウンメニューをクリックします。
- 適切な値 (“On Failure”、“Always”、“Never”) を選択します。