自動化決定の使用
Event-Driven Ansible Controller を設定して使用し、自動化を強化および拡張する
概要
はじめに リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible Controller は、一貫性と復元力を実現しながら IT の速度と俊敏性を向上させることで、自動化を強化および拡張する新しい方法です。Red Hat によって開発されたこの機能は、シンプルさと柔軟性を考慮して設計されています。
Red Hat ドキュメントへのフィードバック (英語のみ) リンクのコピーリンクがクリップボードにコピーされました!
このドキュメントの改善に関するご意見がある場合や、エラーを発見した場合は、https://access.redhat.com からテクニカルサポートに連絡してリクエストを送信してください。
第1章 Event-Driven Ansible Controller の概要 リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible は、他のソフトウェアベンダーのモニタリングツールなどのイベントソースと連携する、拡張性が高く柔軟な自動化機能です。このようなツールは、IT ソリューションを監視してイベントを特定し、ルールブックに記述された変更や対応を自動的に実装して、そのイベントを処理します。
ユーザー設定は次の手順で行います。
- Event-Driven Ansible Controller の API ドキュメントは、https://<gateway-host>/api/eda/v1/docs で入手できます。
- 高可用性の要求を満たすために、Event-Driven Ansible Controller は、集中型の Redis (REmote DIctionary Server) を Ansible Automation Platform UI と共有します。Redis が利用できない場合、プロジェクトを作成または同期したり、ルールブックアクティベーションを有効にしたりすることはできません。
第2章 認証情報 リンクのコピーリンクがクリップボードにコピーされました!
認証情報を使用すると、決定環境、ルールブックアクティベーション、Event-Driven Ansible Controller のプロジェクト、Automation Controller のプロジェクトなどのリソースでの認証に使用できるシークレットを保存できます。
認証情報は、マシンに対してジョブを起動したり、バージョン管理システムからプロジェクトコンテンツをインポートしたりするときにユーザーを認証します。
認証情報をユーザーに公開せずに、ユーザーとチームにこれらの認証情報を使用する権限を付与できます。ユーザーが別のチームに異動する場合や、組織から離職する場合でも、そのユーザーの認証情報が以前に使用可能であったという理由だけで、すべてのシステムのキーを再設定する必要はありません。
Automation Controller と Event-Driven Ansible Controller のコンテキストでは、extra_vars と認証情報の両方を使用してさまざまな情報を保存できます。認証情報は、セキュリティーに優れ、管理が一元化されているため、パスワードや API キーなどの機密情報を保存する方法として推奨されます。一方、extra_vars は動的な非機密データを渡すのに適しています。
2.1. 認証情報のリストビュー リンクのコピーリンクがクリップボードにコピーされました!
Ansible Automation Platform にログインし、 → → を選択すると、Credentials ページに Decision Environment Container Registry の認証情報が事前に読み込まれます。独自の認証情報を作成すると、その認証情報がこのリストビューに追加されます。
メニューバーから、Name 検索フィールドで認証情報を検索できます。
メニューバーには、以下のオプションもあります。
Manage columns - このオプションをクリックすると、リストビューでフィールドを表示する方法を選択できます。フィールドを配置する方法は 4 つあります。
- Column - テーブル内の列を表示します。
- Description - 項目が展開されたときに、列の幅全体に説明を表示します。
- Expanded - 項目が展開されたときに、列を詳細として表示します。
- Hidden - 列を非表示にします。
- List view または Card view - これらの表示を選択するには、該当するアイコンをクリックします。
2.2. 認証情報のセットアップ リンクのコピーリンクがクリップボードにコピーされました!
選択したソースプラグインまたはプライベートコンテナーレジストリーで使用する認証情報を作成できます。認証情報は、チームまたは個人に提供できます。
手順
- Ansible Automation Platform ダッシュボードにログインします。
- ナビゲーションパネルから、 → → を選択します。
- をクリックします。
以下を入力します。
- Name
- 名前を入力します。
- Description
- このフィールドは任意です。
- Organization
- リストをクリックして組織を選択するか、Default を選択します。
- Credential type
リストをクリックして認証情報タイプを選択します。
注記認証情報タイプを選択すると、Type Details セクションと、選択した認証情報タイプに適用できるフィールドが表示されます。
- 選択した認証情報タイプに該当するフィールドに入力します。
- をクリックします。
次のステップ
認証情報を保存すると、認証情報の詳細ページが表示されます。そのページまたは Credentials リストビューから、認証情報を編集または削除できます。
2.3. 認証情報の編集 リンクのコピーリンクがクリップボードにコピーされました!
既存の認証情報を編集し、組織に応じて適切なアクセスレベルを確保できます。
手順
以下のいずれかの方法を使用して、認証情報を編集します。
- Credentials リストビューで、必要な認証情報の横にある アイコンをクリックします。
- Credentials リストビューで認証情報の名前を選択し、 をクリックします。
- 適切な詳細を編集し、 をクリックします。
2.4. 認証情報の複製 リンクのコピーリンクがクリップボードにコピーされました!
既存の認証情報と同様のフィールド入力情報を使用して新しい認証情報を設定する場合は、手動で入力する代わりに、詳細タブの Duplicate credential 機能を使用して情報を複製できます。認証情報の設定には時間がかかる場合がありますが、既存の認証情報から必要なフィールドを複製する機能により、時間が節約され、場合によっては人為的エラーの可能性も軽減されます。
手順
- Credentials リストページで、複製する認証情報の名前をクリックします。認証情報の Details タブに移動します。
Details タブの右上にある をクリックします。
注記Credentials リストページで、目的の認証情報の横にある アイコンをクリックすることもできます。
選択した認証情報が複製されたことを確認するメッセージ ("<Name of credential> duplicated.") が表示されます。
タブをクリックして、複製した認証情報を表示します。
複製した認証情報の名前は、元の認証情報名の後ろに 24 時間形式のタイムスタンプが付いたものになります (例: <認証情報の名前> @ 17:26:30)。
- 複製した認証情報の希望する詳細を編集します。
- をクリックします。
2.5. 認証情報の削除 リンクのコピーリンクがクリップボードにコピーされました!
組織で認証情報が必要なくなった場合は、削除できます。
手順
以下のいずれかの方法を使用して、認証情報を削除します。
- Credentials リストビューで、必要な認証情報の横にある アイコン ⋮ をクリックし、 をクリックします。
- Credentials リストビューで認証情報の名前を選択し、 の横にある アイコン ⋮ をクリックして、 をクリックします。
ポップアップウィンドウで、Yes, I confirm that I want to delete this credential を選択します。
注記認証情報が組織内の他のリソースによってまだ使用されている場合は、認証情報を削除できないことを知らせる警告メッセージが表示されます。また、認証情報がイベントストリームで使用されている場合は、イベントストリームが削除されるか、別の認証情報に割り当てられるまで、認証情報を削除することはできません。一般に、使用中の認証情報を削除するとアクティベーションが壊れる可能性があるため、削除することは避けてください。
- をクリックします。
結果
各認証情報の横にあるチェックボックスを選択し、メニューバーの アイコン ⋮ をクリックしてから、 をクリックして、一度に複数の認証情報を削除できます。
第3章 認証情報タイプ リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible Controller には、プロジェクトの同期、ルールブックアクティベーションの実行、自動化実行 (Automation Controller) によるジョブテンプレートの実行、コンテナーレジストリーからのイメージの取得、イベントストリームによるデータの処理に使用できるいくつかの認証情報タイプが組み込まれています。
これらの組み込みの認証情報タイプは編集できません。他のシステムによる認証に対応した認証情報タイプが必要な場合は、ソースプラグインで使用できる独自の認証情報タイプを作成できます。各認証情報タイプには、入力設定とインジェクター設定が含まれています。これらの設定を Ansible ルールブックに渡すことで、ソースを設定できます。
詳細は、カスタム認証情報タイプ を参照してください。
3.1. カスタム認証情報タイプ リンクのコピーリンクがクリップボードにコピーされました!
システム管理者は、YAML または JSON ライクな定義を使用して、標準形式の既存の認証情報タイプと同様に機能するカスタム認証情報タイプを定義できます。
各認証情報タイプでは、該当する場合、Input Configuration フィールドと Injector Configuration フィールドに独自の固有の設定が表示されます。YAML 形式と JSON 形式の両方が設定フィールドでサポートされています。
カスタム認証情報は、認証情報を注入する手段として Ansible の追加変数をサポートしています。
ルールブックアクティベーションに、1 つ以上のクラウド、Vault、および Red Hat Ansible Automation Platform の認証情報タイプを割り当てることができます。
-
新しい認証情報タイプを作成するときは、
extra_varsでの競合を回避する必要があります。 - 追加の変数名の先頭を EDA_ にすることはできません。そのような変数名は予約されているためです。
- 認証情報タイプの作成と編集および Injector configuration フィールドの表示を行うには、システム管理者 (スーパーユーザー) 権限が必要です。
独自の認証情報タイプをカスタマイズすると、組み込みの認証情報タイプのリストとともに、認証情報タイプページに表示されます。
3.1.1. 入力設定 リンクのコピーリンクがクリップボードにコピーされました!
入力設定には 2 つの属性があります。
- フィールド - 認証情報タイプのプロパティー群。
- 必須 - 必須フィールドのリスト。
選択した認証情報タイプに応じて、フィールドに複数のプロパティーを設定できます。
| フィールド | 説明 | 必須 (はい/いいえ) |
|---|---|---|
| id | フィールドの一意の ID。文字列型で、変数名を格納する必要があります。 | はい |
| type | 文字列型またはブール型にすることができます。 | いいえ、デフォルトは文字列です。 |
| label | UI 要素をレンダリングするときに UI によって使用されます。 | はい |
| secret | 暗号化されます。 | いいえ、デフォルトは false です。 |
| multiline | フィールドにファイルからのデータが含まれる場合は、multiline を True に設定できます。 | いいえ、デフォルトは false です。 |
| help_text | このフィールドに関連するヘルプテキスト。 | いいえ |
3.1.2. インジェクター設定 リンクのコピーリンクがクリップボードにコピーされました!
インジェクター設定を使用すると、入力設定フィールドから情報を取得し、その情報を、ルールブックアクティベーションの実行時に ansible-rulebook に送信できるインジェクタータイプにマッピングできます。Event-Driven Ansible は、次のインジェクタータイプをサポートします。
-
環境変数 (
env) - 基礎となるパッケージまたは共有ライブラリーのソースプラグインで使用されます。 -
Ansible 追加変数 (
extra_vars) - ルールブックの条件、アクション、またはソースプラグインパラメーターの置換に使用されます。 -
ファイルベースのテンプレート (
file) - ソースプラグインで必要になる可能性のある証明書やキーなどの認証情報入力からファイルコンテンツを作成するために使用されます。ファイルインジェクターを使用すると、これらの証明書とキーを決定環境に保存しなくても、実行時に ansible-rulebook に提供できます。その結果、ansible-rulebook は一時ファイルを作成し、そのファイル名にはeda.filename変数を使用してアクセスできます。この変数は、ファイルが作成された後に自動的に作成されます (例: "{{eda.filename.my_cert}}”)。
ルールブックアクティベーションと認証情報タイプインジェクターで extra_vars を作成する場合は、キー名に eda または ansible を使用しないでください。これは、内部使用と競合し、ルールブックアクティベーションと認証情報タイプの作成の両方で失敗する可能性があるためです。
上記のインジェクタータイプは、最上位レベルで重複キーを持つことができませんが、インジェクターを使用すると、上記のインジェクタータイプの 1 つとしてルールブックに注入できるようにフィールドが調整されます。ルールブックに username や password などのパラメーターを必要とする 2 つのソースがある場合、ルールブックとともにインジェクターを使用すると、各ソースの引数を調整できます。
サンプルのインジェクターと入力を表示するには、それぞれ次の GitHub gist を参照してください。
3.2. 新しい認証情報タイプの作成 リンクのコピーリンクがクリップボードにコピーされました!
サポートされているデフォルトの認証情報タイプに基づいて、選択したソースプラグインで使用する認証情報タイプを作成できます。認証情報タイプは、チームまたは個人に提供できます。
手順
- Ansible Automation Platform ダッシュボードにログインします。
- ナビゲーションパネルから、 → → を選択します。
- をクリックします。
以下を入力します。
- Name
- 名前を入力します。
- Description
- このフィールドは任意です。
Input Configuration フィールドで、対象のタイプの順序付きフィールドのセットを定義する入力スキーマを指定します。形式は YAML または JSON です。
YAML
fields: - type: string id: username label: Username - type: string id: password label: Password secret: true required: - username - passwordYAML ページ でさらに YAML の例をご覧ください。
JSON
{ "fields": [ { "type": "string", "id": "username", "label": "Username" }, { "secret": true, "type": "string", "id": "password", "label": "Password" } ], "required": ["username", "password"] }その他の JSON の例は、JSON Web サイト をご覧ください。
Injector Configuration フィールドに、認証情報タイプが注入できる値を指定する環境変数または追加変数を入力します。形式は YAML または JSON に指定できます (前の手順の例を参照)。
JSON 形式の次の設定は、各フィールドとその使用方法を示しています。
{ "extra_vars": { "some_extra_var": "{{ username }}:{{ password }}" } }をクリックします。
新しく作成した認証情報タイプが、認証情報タイプのリストに表示されます。
-
アイコンをクリックして、認証情報タイプのオプションを変更します。
検証
- 新しい認証情報を作成するときに、新しく作成した認証情報タイプが Credential Type リストから選択できることを確認します。
次のステップ
- Edit ページでは、詳細を変更したり、認証情報を削除したりできます。
- Delete オプションが無効になっている場合は、その認証情報タイプが認証情報によって使用されています。認証情報タイプを削除する前に、それを使用しているすべての認証情報からその認証情報タイプを削除する必要があります。
関連情報
第4章 プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトはルールブックの論理的なコレクションです。これらは Git リポジトリーで、Ansible コレクション内の Event-Driven Ansible コンテンツ用に定義されたパス (プロジェクトのルートにある /extensions/eda/rulebooks) に配置する必要があります。
高可用性の要求を満たすために、Event-Driven Ansible Controller は、集中型の Redis (REmote DIctionary Server) を Ansible Automation Platform UI と共有します。Redis が利用できない場合は、プロジェクトを作成したり同期したりできません。
4.1. 新しいプロジェクトの設定 リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible Controller で、ルールブックを管理および保存するためのプロジェクトを設定できます。
前提条件
- Ansible Automation Platform ダッシュボードにコンテンツコンシューマーとしてログインしている。
- 必要に応じて認証情報を設定した。詳細は、認証情報のセットアップ セクションを参照してください。
- ルールブックを含む既存のリポジトリーがある。
手順
- Ansible Automation Platform ダッシュボードにログインします。
- → に移動します。
- をクリックします。
以下を入力します。
- Name
- プロジェクト名を入力します。
- Description
- このフィールドは任意です。
- Source control type
- 使用できる Source control type は Git のみです。このフィールドは任意です。
- Source control URL
GitHub や GitLab などのリポジトリーの Git、SSH、または HTTP[S] プロトコルアドレスを入力します。この必須フィールドは編集可能です。このフィールドの編集がルールブックのアクティブ化に与える影響に関する詳細は、プロジェクトの編集 を参照してください。
注記このフィールドは、SSH 秘密鍵または秘密鍵フレーズを受け入れます。これらの秘密鍵の使用は、
git@で開始するプロジェクト URL でなければ有効になりません。- プロキシー
- これは、HTTP または HTTPS サーバーにアクセスするために使用されます。このフィールドはオプションであり、編集可能です。このフィールドの編集がルールブックのアクティブ化に与える影響に関する詳細は、プロジェクトの編集 を参照してください。
- Source control branch/tag/commit
- これはチェックアウトするブランチです。ブランチに加えて、タグ、コミットハッシュ、任意の参照を入力できます。一部のコミットハッシュと参照を使用するには、カスタム refspec も指定する必要がある場合があります。このフィールドはオプションであり、編集可能です。このフィールドの編集がルールブックのアクティブ化に与える影響に関する詳細は、プロジェクトの編集 を参照してください。
- Source control refspec
- 取得する refspec (Ansible git モジュールに渡されます)。このパラメーターにより、他の方法では利用できないブランチフィールド経由の参照にアクセスできるようになります。このフィールドはオプションであり、編集可能です。このフィールドの編集がルールブックのアクティブ化に与える影響に関する詳細は、プロジェクトの編集 を参照してください。詳細は、Examples を参照してください。
- Source control credential
- これは、提供された Source control URL で認証するために使用されるオプションの認証情報です。
- Content signature validation credential
- コンテンツ署名を有効にして、プロジェクトの同期時にコンテンツがセキュアな状態に保たれていることを検証します。コンテンツが改ざんされている場合、ジョブは実行されません。このフィールドは任意です。
- オプション
Verify SSL オプションはデフォルトで有効になっています。このオプションが有効になっていると、プロジェクトのインポート時に SSL が HTTPS で検証されます。
注記自己署名付き証明書を使用するローカルリポジトリーがある場合は、このオプションを無効にできます。
- を選択します。
結果
プロジェクトが作成され、Projects ページで管理できるようになります。
新しいプロジェクトを保存すると、プロジェクトの詳細ページが表示されます。そのページまたは Projects リストビューから、プロジェクトを編集または削除できます。
4.2. Projects リストビュー リンクのコピーリンクがクリップボードにコピーされました!
Projects ページでは、作成したプロジェクトを ステータス および Git ハッシュ とともに確認できます。
Source control でルールブックが変更された場合は、Projects リストビューでプロジェクトの横にある同期アイコンを選択することで、プロジェクトを再同期できます。Git ハッシュ の更新は、そのリポジトリー上の最新のコミットを表します。更新されたプロジェクトを使用する場合は、アクティベーションを再開または再作成する必要があります。
4.3. プロジェクトの編集 リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトは、作成後にさまざまな側面を変更できます。変更内容によっては、ルールブックのアクティベーションが影響を受ける可能性があり、確認して再起動する必要があります。
手順
- Projects リストビューで、目的のプロジェクトの横にある アイコン ⋮ を選択します。Edit ページが表示されます。
必要なフィールドを編集します。
重要プロジェクトの Source control URL、Source control ブランチ/タグ/コミット、または Source control refspec を更新すると、Event-Driven Ansible によってプロジェクトの再同期が自動的にトリガーされます。このプロセスは、Event-Driven Ansible コントローラー内で利用可能なルールブックを更新し、既存のルールブックのアクティベーションに大きな影響を与える可能性があります。
- ルールブックのコンテンツの更新: ルールブックのコンテンツが変更されても、実行中のアクティベーションでは古いコンテンツが引き続き使用されます。新しいコンテンツを適用するには、影響を受けるルールブックのアクティベーションを再起動する必要があります。更新するルールブックのコンテンツがイベントストリームを使用するアクティベーションにアタッチされている場合は、更新を適用した後でイベントストリームをそのアクティベーションに再度アタッチし、アクティベーションを再起動する必要があります。
- 新しいルールブック: リポジトリーに追加された新しいルールブックは、同期後にデータベースで使用できるようになります。
- 削除されたルールブック: 削除されたルールブックは、同期時にデータベースから削除されます。ただし、関連するアクティベーションは引き続き実行され、再起動できます。ソースルールブックから切り離されたアクティベーションを確認して更新します。
- を選択します。
4.4. プロジェクトの削除 リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトを削除する必要がある場合、Event-Driven Ansible Controller インターフェイスにある複数のオプションを使用できます。
手順
プロジェクトを削除するには、次のいずれかを実行します。
- Projects リストビューで、目的のプロジェクトの横にあるチェックボックスをオンにし、ページメニューから アイコン ⋮ をクリックします。
- Projects リストビューで、目的のプロジェクトの横にある アイコン ⋮ をクリックします。
- を選択します。
- Permanently delete projects ウィンドウで、 を選択します。
- を選択します。
第5章 決定環境 リンクのコピーリンクがクリップボードにコピーされました!
決定環境は、Ansible ルールブックを実行するコンテナーイメージです。決定環境は、自動化の依存関係をやり取りするための共通言語を作り出し、自動化環境をビルドおよび配布するための標準的な方法を提供します。デフォルトの決定環境は、Ansible-Rulebook にあります。
独自の決定環境を作成するには、ansible-builder のインストール および Ansible Automation Platform 内での Event-Driven Ansible のカスタム決定環境のビルド を参照してください。
5.1. ansible-builder のインストール リンクのコピーリンクがクリップボードにコピーされました!
イメージをビルドするには、Podman または Docker と ansible-builder Python パッケージがインストールされている必要があります。
--container-runtime オプションは、使用する Podman または Docker 実行可能ファイルに対応している必要があります。
決定環境イメージをビルドするときは、Ansible Automation Platform がデプロイされるアーキテクチャーをサポートする必要があります。
詳細は、Ansible Builder のクイックスタート または 実行環境の作成と使用 を参照してください。
5.2. Event-Driven Ansible のカスタム決定環境のビルド リンクのコピーリンクがクリップボードにコピーされました!
決定環境は、Ansible ルールブックの実行に合わせてカスタマイズされた実行環境です。
Automation Controller の Ansible Playbook を実行する実行環境と同様に、決定環境は Event-Driven Ansible Controller のルールブックを実行するためのものです。
Event-Driven Ansible 用のカスタム決定環境を作成することで、デフォルトの決定環境にはない、カスタム管理またはサードパーティーのイベントソースプラグインを提供できます。
前提条件
- Ansible Automation Platform 2.5 以降
- Event-Driven Ansible
- Ansible Builder 3.0 以降
ルールブックアクティベーションの失敗を防ぐために、Ansible Automation Platform で適切な Event-Driven Ansible Controller 決定環境を使用してください。
-
Event-Driven Ansible Controller を Ansible Automation Platform 2.4 に接続する場合は、
registry.redhat.io/ansible-automation-platform-24/de-minimal-rhel9:latestを使用する必要があります。 -
Event-Driven Ansible Controller を Ansible Automation Platform 2.5 に接続する場合は、
registry.redhat.io/ansible-automation-platform-25/de-minimal-rhel9:latestを使用する必要があります。
-
Event-Driven Ansible Controller を Ansible Automation Platform 2.4 に接続する場合は、
手順
-
Ansible Builder で
de-minimalをベースイメージとして使用して、カスタム決定環境をビルドします。このイメージは、Ansible Automation Platform minimal decision environment で Red Hat が提供しているベースイメージからビルドされています。
例
以下は、ansible.eda コレクションでカスタム決定環境をビルドするために、ベースイメージとして de-minimal を使用する Ansible Builder 定義ファイルの例です。
version: 3
images:
base_image:
name: 'registry.redhat.io/ansible-automation-platform-25/de-minimal-rhel9:latest'
dependencies:
galaxy:
collections:
- ansible.eda
python_interpreter:
package_system: "python39"
options:
package_manager_path: /usr/bin/microdnf
さらに、他の Python パッケージまたは RPM が必要な場合は、1 つの定義ファイルに以下を追加します。
version: 3
images:
base_image:
name: 'registry.redhat.io/ansible-automation-platform-25/de-minimal-rhel9:latest'
dependencies:
galaxy:
collections:
- ansible.eda
python:
- six
- psutil
system:
- iputils [platform:rpm]
python_interpreter:
package_system: "python39"
options:
package_manager_path: /usr/bin/microdnf
5.3. 新しい決定環境の設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトまたはカスタムの決定環境を使用して、決定環境を Event-Driven Ansible Controller にインポートできます。
前提条件
- 必要に応じて認証情報を設定した。詳細は、認証情報のセットアップ セクションを参照してください。
-
決定環境イメージをイメージリポジトリーにプッシュしたか、registry.redhat.io にある
de-minimalイメージを使用することを選択した。
手順
- Ansible Automation Platform にログインします。
- → に移動します。
- をクリックします。
以下を入力します。
- Name
- 名前を入力します。
- Description
- このフィールドは任意です。
- Organization
- 決定環境に関連付ける組織を選択します。
- Image
- これは、コンテナーレジストリー、イメージ名、およびバージョンタグを含む完全なイメージの場所です。
- Credential
- このフィールドは任意です。これは、決定環境イメージを使用するために必要な認証情報です。
- を選択します。
結果
これで決定環境が作成され、Decision Environments ページで管理できるようになります。
新しい決定環境を保存すると、決定環境の詳細ページが表示されます。そのページまたは Decision Environments リストビューから、決定環境を編集または削除できます。
第6章 Red Hat Ansible Automation Platform 認証情報 リンクのコピーリンクがクリップボードにコピーされました!
Ansible Automation Platform 2.5 に Event-Driven Ansible Controller をデプロイすると、Automation Controller の URL とユーザー名およびパスワードを使用して Automation Controller に接続するための Red Hat Ansible Automation Platform 認証情報を作成できます。作成したら、Red Hat Ansible Automation Platform の認証情報をルールブックに割り当て、それを使用してルールブックアクティベーションを実行できます。これらの認証情報を使用すると、Automation Controller と Event-Driven Ansible Controller 間の通信を簡単に設定できるようになり、ルールブックのアクティブ化によってジョブテンプレートを起動できるようになります。
Ansible Automation Platform 2.4 を使用して Event-Driven Ansible Controller をデプロイした場合は、コントローラートークンで Automation Controller と Event-Driven Ansible Controller を接続している可能性があります。これらのコントローラートークンは Ansible Automation Platform 2.5 では非推奨になりました。非推奨のコントローラートークンとそれに関連付けられたルールブックアクティベーションを削除するには、Red Hat Ansible Automation Platform 認証情報の設定 に進む前に、Ansible Automation Platform 2.5 でのコントローラートークンの置き換え から始まる次の手順を完了してください。
6.1. Red Hat Ansible Automation Platform 2.5 でのコントローラートークンの置き換え リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Ansible Automation Platform 2.5 で Event-Driven Ansible Controller を使用するには、コントローラートークンが非推奨になっているため、環境で設定されている従来のコントローラートークンを Red Hat Ansible Automation Platform の認証情報に置き換える必要があります。
6.1.1. コントローラートークンを使用したルールブックアクティベーションの削除 リンクのコピーリンクがクリップボードにコピーされました!
コントローラートークンを置き換えるには、それに関連付けられていたルールブックアクティベーションを削除する必要があります。
手順
- Ansible Automation Platform ダッシュボードにログインします。
- 上部のナビゲーションパネルから、 → を選択します。
- コントローラートークンを使用するルールブックアクティベーションを選択します。
- Rulebook Activation enabled/disabled トグルの横にある アイコン ⋮ を選択します。
- を選択します。
- ウィンドウで、 を選択します。
- を選択します。
6.1.2. コントローラートークンの削除 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Ansible Automation Platform の認証情報を設定する前に、既存のコントローラートークンを削除する必要があります。
前提条件
- コントローラートークンを使用するすべてのルールブックアクティベーションを削除した。
手順
- Ansible Automation Platform ダッシュボードにログインします。
- 上部のナビゲーションパネルからプロファイルを選択します。
- User details をクリックします。
- Tokens タブを選択します。
- 以前のコントローラートークンをすべて削除します。
次のステップ
コントローラートークンとルールブックアクティベーションを削除したら、Red Hat Ansible Automation Platform 認証情報の設定 に進みます。
6.2. Red Hat Ansible Automation Platform 認証情報の設定 リンクのコピーリンクがクリップボードにコピーされました!
Automation Controller の URL とユーザー名およびパスワードを使用して Automation Controller に接続するための Red Hat Ansible Automation Platform 認証情報を作成します。
前提条件
- ユーザーを作成した。
- Automation Controller にアクセスするための URL と認証情報を取得した。
手順
- Ansible Automation Platform ダッシュボードにログインします。
- ナビゲーションパネルから、 → → を選択します。
- をクリックします。
以下を入力します。
- Name
- 名前を入力します。
- Description
- このフィールドは任意です。
- Organization
- リストをクリックして組織を選択するか、Default を選択します。
- Credential type
リストをクリックして、Red Hat Ansible Automation Platform を選択します。
注記認証情報タイプを選択すると、Type Details セクションと、選択した認証情報タイプに適用できるフィールドが表示されます。
警告バックアップと復元操作を使用して Ansible Automation Platform インスタンスを別のクラスターまたは新しいホスト名セットに移行する予定の場合、Red Hat Ansible Automation Platform の認証情報が機能せず、ルールブックのアクティベーションが失敗します。復元操作が完了したら、接続を復元するために、Automation Controller URL と関連する認証情報を手動で編集および更新する必要があります。
必須の Red Hat Ansible Automation Platform フィールドに、Automation Controller URL を入力します。
注記Event-Driven Ansible Controller 2.5 と Automation Controller 2.4 の場合は、https://<your_controller_host> などを使用してください。
Ansible Automation Platform 2.5 の場合は、https://<your_gateway_host>/api/controller/ などを使用してください。
- 有効な Username と Password または Oauth Token を入力します。
- をクリックします。
次のステップ
この認証情報を作成したら、それを使用してルールブックアクティベーションを設定できます。
第7章 ルールブックアクティベーション リンクのコピーリンクがクリップボードにコピーされました!
ルールブックは、イベント駆動型自動化モデルで IT アクションを実行するために Event-Driven Ansible が使用する条件付きルールのセットです。ルールブックは、どのソースでイベントをチェックするか、そのイベントが発生したときに特定の条件が満たされ場合に何を実行するかを、ユーザーが Event-Driven Ansible に指示する手段です。
ルールブックは、ルールがトリガーされたときに実行されるアクションを指定するものです。イベントがルールの条件に一致すると、ルールがトリガーされます。現在、次のアクションがサポートされています。
-
run_playbook(ansible-rulebook CLI でのみサポート) -
run_module -
run_job_template -
run_workflow_template -
set_fact -
post_event -
retract_fact -
print_event -
shutdown -
debug -
none
詳細を確認するには、アクション を参照してください。
ルールブックアクティベーションは、特定のルールブックを実行する決定環境によって定義されるバックグラウンドで実行されるプロセスです。ルールブックアクティベーションをセットアップするには、ルールブックアクティベーションの設定 に従ってください。
Red Hat は、1 つの postgres データベースでサポートされていないソースプラグインを使用することを推奨していません。これにより、Ansible Automation Platform を使用する際に潜在的なリスクが生じる可能性があります。
高可用性の要求を満たすために、Event-Driven Ansible Controller は、集中型の Redis (REmote DIctionary Server) を Ansible Automation Platform UI と共有します。Redis が利用できない場合は、次の機能が利用できなくなります。
-
is_enabledが True の場合は、アクティベーションの作成 - アクティベーションの削除
- アクティベーションの有効化 (まだ有効化されていない場合)
- アクティベーションの無効化 (まだ無効化されていない場合)
- アクティベーションの再開
7.1. サポートされるイベントソース リンクのコピーリンクがクリップボードにコピーされました!
イベントソースは、ルールブックがイベントをどこから受信できるかを決定するため、Event-Driven Ansible の基本的なコンポーネントです。ルールブックのアクティベーションの有効性は、自動化環境と互換性のあるイベントソースの選択によって決まります。一部のイベントソースは、Web ベースの Event-Driven Ansible コントローラーで使用するように設計されていますが、その他のイベントソースは、ローカルホスト機能に依存しているため、ansible-rulebook コマンドラインインターフェイス (CLI) 専用となっています。この違いを理解することは、ルールブックのアクティベーションを成功させるために非常に重要です。
次のリストには、Web ベースの Event-Driven Ansible コントローラーで使用するために現在サポートされているイベントソースが含まれています。ルールブックのアクティベーションに対して、どのイベントソースが望ましい結果をもたらすかを決定できます。
-
alertmanager -
aws_cloudtrail -
aws_sqs_queue -
azure_service_bus -
kafka -
pg_listener -
webhook
7.2. ルールブックアクティベーションの設定 リンクのコピーリンクがクリップボードにコピーされました!
Ansible Automation Platform ダッシュボード内でルールブックアクティベーションを作成および設定できます。このプロセスにより、イベント駆動型の自動化を効率的に管理およびデプロイできるようになります。
前提条件
- Ansible Automation Platform ダッシュボードにコンテンツコンシューマーとしてログインしている。
- プロジェクトを設定した。
- 決定環境を設定した。
手順
- Ansible Automation Platform にログインします。
- → に移動します。
- をクリックします。
以下を入力します。
- Name
- 名前を入力します。
- Description
- このフィールドは任意です。
- Organization
- 組織名を入力するか、リストから Default を選択します。
- Project
- プロジェクトはルールブックの論理的なコレクションです。このフィールドは任意です。
- Rulebook
- 選択したプロジェクトに応じてルールブックが表示されます。
- Credential
このルールブックアクティベーションの認証情報を 0 個以上選択します。このフィールドは任意です。
注記- このフィールドに表示される認証情報は、ルールブックアクティベーションに基づいてカスタマイズされています。表示される認証情報のタイプは、Vault、Red Hat Ansible Automation Platform、または作成したカスタム認証情報タイプだけです。認証情報の詳細は、認証情報 を参照してください。
- Red Hat Ansible Automation Platform 認証情報を使用する予定の場合、ルールブックアクティベーションに選択できる Red Hat Ansible Automation Platform 認証情報タイプは 1 つだけ です。
- Decision environment
決定環境は、Ansible ルールブックを実行するためのコンテナーイメージです。
注記Event-Driven Ansible Controller では、決定環境のプルポリシーをカスタマイズすることはできません。デフォルトでは、always ポリシーの動作に従います。アクティベーションが開始されるたびに、システムはイメージの最新バージョンを取得しようとします。
- Restart policy
これは、ソースプラグインを実行しているコンテナープロセスが終了した後にアクティベーションを再開する方法を決定するポリシーです。
Policies:
- Always: ルールブックアクティベーションが正常に終了したかどうかに関係なく、ルールブックアクティベーションを直ちに再開します。これは 5 回まで実行されます。
- Never: コンテナープロセスが終了したときに、ルールブックアクティベーションを再開しません。
- On failure: コンテナープロセスが失敗した場合にのみ、デフォルトで 60 秒後にルールブックアクティベーションを再開します。これは 5 回まで実行されます。
- Log level
このフィールドでは、ログに記録するイベントの重大度とコンテンツのタイプを定義します。
Levels:
- Error: アクティベーションの History タブに表示されるエラーメッセージを含むログ。
- Info: 成功または失敗、トリガーされたアクション名と関連するアクションイベント、エラーなど、ルールブックアクティベーションに関する有用な情報を含むログ。
- Debug: デバッグフェーズでのみ役立ち、運用時にはあまり有用でない可能性がある情報を含むログ。このログレベルでは、エラーデータとログレベルデータの両方が対象となります。
- Service name
- これは、アクティベーションによりポートが公開される場合に、Kubernetes が受信接続を設定するためのサービス名を定義します。このフィールドは任意です。
- Rulebook activation enabled?
- これを選択すると、ルールブックアクティベーションが自動的に有効になります。
- Variables
ルールブックの変数は JSON または YAML 形式です。内容は、ansible-rulebook コマンドの
--varsフラグによって渡されるファイルと同等です。注記Automation Controller と Event-Driven Ansible Controller のコンテキストでは、
extra_varsと認証情報の両方を使用してさまざまな情報を保存できます。認証情報は、セキュリティーに優れ、管理が一元化されているため、パスワードや API キーなどの機密情報を保存する方法として推奨されます。一方、extra_varsは動的な非機密データを渡すのに適しています。- オプション
- ルール監査にイベントを表示しない場合は、Skip audit events オプションをオンにします。
- をクリックします。
結果
ルールブックアクティベーションが作成され、Rulebook Activations 画面で管理できるようになります。
新しいルールブックアクティベーションを保存すると、ルールブックアクティベーションの詳細ページが、Pending、Running、または Failed ステータスとともに表示されます。詳細ページまたは Rulebook Activations リストビューから、ルールブックアクティベーションを再開または削除できます。
ソースプラグインがシャットダウンすると、一定時間後にルールブックがグレースフルに終了することがあります。ルールブックアクティベーションがシャットダウンすると、待機中のタスクがすべてキャンセルされ、アクティベーションのログに info レベルのメッセージが送信されます。詳細は、Rulebooks を参照してください。
7.3. ルールブックアクティベーションのリストビュー リンクのコピーリンクがクリップボードにコピーされました!
Rulebook Activations ページでは、作成したルールブックアクティベーションを、Status、ルールブックの Number of rules、Fire count、および Restart count とともに表示できます。
Status が Running の場合、ルールブックアクティベーションがバックグラウンドで実行されており、ルールブックで宣言されたルールに従って必要なアクションが実行されていることを意味します。
Rulebook Activations リストビューからアクティベーションを選択すると、詳細を確認できます。
実行されたすべてのアクティベーションについて、Details タブと History タブを表示して、実行結果に関する詳細情報を取得できます。
7.3.1. アクティベーションの出力の表示 リンクのコピーリンクがクリップボードにコピーされました!
アクティベーションの出力は History タブで確認できます。
手順
- History タブを選択して、すべてのアクティベーションインスタンスのリストにアクセスします。1 つのアクティベーションインスタンスは、1 回のアクティベーションの実行を表します。
- 次に、表示するアクティベーションインスタンスを選択します。アクティベーションインスタンスの Output が表示されます。
次のステップ
アクションをトリガーしたイベントを表示するには、 → に移動し、Rule Audit セクションの指示に従います。
7.4. ルールブックアクティベーションの有効化および無効化 リンクのコピーリンクがクリップボードにコピーされました!
ルールブックのアクティベーションを有効化または無効化して、いつ実行されるかを制御できます。アクティベーションを無効にすると、トラブルシューティングを行う場合や、設定を削除せずに自動化を一時的に停止する場合に役立ちます。
手順
- 行レベルのスイッチを選択して、選択したルールブックを有効または無効にします。
- ウィンドウで、 を選択します。
- を選択します。
7.5. ルールブックアクティベーションの再起動 リンクのコピーリンクがクリップボードにコピーされました!
ルールブックのアクティベーションを再起動すると、自動化をすぐに再有効化できます。これは、更新を行った後やエラーから回復する場合に便利です。
ルールブックアクティベーションを再開できるのは、ルールブックアクティベーションが現在有効で、作成時に再開ポリシーを Always に設定した場合だけです。
手順
- Rulebook Activation enabled/disabled トグルの横にある アイコン ⋮ を選択します。
- を選択します。
- ウィンドウで、 を選択します。
- を選択します。
7.6. ルールブックアクティベーションの編集 リンクのコピーリンクがクリップボードにコピーされました!
ルールブックアクティベーションを作成または実行した後に編集して、フィールドの入力 (ログレベル、再起動ポリシー、監査のオン/オフなど) を修正したり、障害によって発生した問題を軽減したりすることができます。
手順
Rulebook Activations ページで、編集するアクティベーションの横にある ボタンをオフの位置に切り替えて、アクティベーションを無効にします。
Disable rulebook activations というメッセージが表示され、アクティベーションを無効にするかどうかの確認を求められます。
- Yes, I confirm that I want to disable these <1> rulebook activations チェックボックスをオンにし、 をクリックします。
ルールブックアクティベーションの横にある Edit アイコンをクリックします。Edit フォームに移動します。
注記Edit 機能には別の方法でもアクセスできます。Rulebook Activations ページでルールブックアクティベーションをクリックし、 ボタンをオフの位置に切り替えて、アクティベーションを無効にすることを確認してから、ページの右上にある ボタンをクリックすると、Edit フォームにアクセスできます。
必要なフィールドを編集します。
注記アクティベーションをすぐに実行する場合は、 ボタンをオンの位置に切り替えて、変更を保存してください。
- をクリックします。
結果
これにより、Rulebook Activations ページに戻ります。
7.7. ルールブックアクティベーションの複製 リンクのコピーリンクがクリップボードにコピーされました!
既存のルールブックアクティベーションと同様のフィールド入力情報を使用して新しいルールブックアクティベーションを設定する場合は、各フィールドに手動で入力する代わりに、Duplicate rulebook activation 機能を使用できます。ルールブックアクティベーションの設定には時間がかかる場合がありますが、既存のアクティベーションから必要なフィールドを複製する機能により、時間が節約され、場合によっては人為的エラーの可能性も軽減されます。
手順
Rulebook Activations ページで、複製するアクティベーションの行にある More Actions アイコン ⋮ をクリックします。More Actions リストには、次の 3 つのオプションが表示されます。
- Restart rulebook activation
- Duplicate rulebook activation
- Delete rulebook activation
を選択します。
"<Name of rulebook activation 1> duplicated." というメッセージが表示されます。最初、新しく複製したアクティベーションは、無効な状態で Rulebook Activations ページに表示されます。その名前は、元のアクティベーション名の後ろに 24 時間形式のタイムスタンプが付いたものになります (例: <ルールブックアクティベーション 1 の名前> @ 18:43:27)。
重要ルールブックを複製した後も、元のルールブックアクティベーションは引き続き実行されます。フィールド (Name フィールドを含む) を編集せずに複製したアクティベーションを有効にして、元のアクティベーションと区別しようとすると、ルールブックアクティベーションが元のアクティベーションから複製されたものであるため、有効化に失敗したり、ジョブの重複やその他の問題が発生する可能性があることを通知するメッセージが表示されます。
複製したルールブックアクティベーションを実行する前に、次の手順を実行してフィールドを編集します。
- 複製したルールブックアクティベーションの横にある Edit アイコンをクリックします。Edit フォームに移動します。
必要なフィールドを編集します。
注記新しく複製したアクティベーションに、元のアクティベーションと区別できる意味のある Name を必ず付けてください。
- ボタンをオンの位置に切り替えます。
- すべての編集が完了したことを確認したら、 をクリックします。
結果
これにより、ルールブックアクティベーションが開始されます。アクティベーションが正常に実行されると、ステータスが Running または Completed に変わります。
7.8. ルールブックアクティベーションの削除 リンクのコピーリンクがクリップボードにコピーされました!
不要になったルールブックのアクティベーションは、削除することで完全に除去できます。
手順
- Rulebook Activation enabled/disabled トグルの横にある アイコン ⋮ を選択します。
- を選択します。
- ウィンドウで、 を選択します。
- を選択します。
7.9. Webhook ルールブックのアクティブ化 リンクのコピーリンクがクリップボードにコピーされました!
Openshift 環境では、ルールブックアクティベーションの Kubernetes サービスを公開するルートを作成することで、Webhook が特定のポートを介して activation-job-pod に到達できるようにすることが可能です。
前提条件
- ルールブックアクティベーションを作成した。
特定の Webhook を含むルールブックの例を以下に示します。
- name: Listen for storage-monitor events
hosts: all
sources:
- ansible.eda.webhook:
host: 0.0.0.0
port: 5000
rules:
- name: Rule - Print event information
condition: event.meta.headers is defined
action:
run_job_template:
name: StorageRemediation
organization: Default
job_args:
extra_vars:
message: from eda
sleep: 1
手順
サービスを公開するためのルートを (OpenShift Container Platform 上に) 作成します。以下は、決定環境 Pod のポート 5000 で POST を要求する ansible-rulebook ソースのルートの例です。
kind: Route apiVersion: route.openshift.io/v1 metadata: name: test-sync-bug namespace: dynatrace labels: app: eda job-name: activation-job-1-5000 spec: host: test-sync-bug-dynatrace.apps.aap-dt.ocp4.testing.ansible.com to: kind: Service name: activation-job-1-5000 weight: 100 port: targetPort: 5000 tls: termination: edge insecureEdgeTerminationPolicy: Redirect wildcardPolicy: Noneルートを作成したら、ルート URL へのポスト を使用してテストします。
注記ポートはルート (targetPort) で指定されているため、必要ありません。
curl -H "Content-Type: application/json" -X POST test-sync-bug-dynatrace.apps.aap-dt.ocp4.testing.ansible.com -d '{}'
7.10. Kubernetes を使用したテスト リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes を使用すると、Ingress の作成やポートの公開を行うことができます。ただし、これは実稼働環境用のものではありません。
手順
次のコマンドを実行して、クラスター上の特定のサービスのポートを公開します。
kubectl port-forward svc/<ACTIVATION_SVC_NAME> 5000:5000localhost:5000に対して HTTP 要求を実行して、ルールブックをトリガーします。curl -H "Content-Type: application/json" -X POST test-sync-bug-dynatrace.apps.aap-dt.ocp4.testing.ansible.com -d '{}'
第8章 ルールブックアクティベーションのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
さまざまな理由により、ルールブックのアクティベーションが失敗する場合があります。多くの問題は基本的なチェックで解決できますが、分散システム全体の障害を診断するには、堅牢なロギングが必要です。
Event-Driven Ansible の強化されたログ記録ストラテジーには、すべての出力にトラッキングの一意識別子が追加され、トラブルシューティングが大幅に改善されます。
本章では、アクティベーション失敗の原因となり得る問題の一覧と、それぞれの推奨される解決方法を説明します。新しい識別子を使用した詳細なログフィルタリングは、Event-Driven Ansible ログフィルタリング を参照してください。
8.1. Event-Driven Ansible ログフィルタリング リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible は、すべてのログ出力にトラッキングの識別子を含めることで、トラブルシューティングを大幅に改善します。これらの識別子は、複数のサービスとログファイルにわたるユーザーアクションとアクティベーションプロセスを追跡するのに役立ちます。
| 識別子 | 省略形 | 目的 | 場所 |
|---|---|---|---|
| X-REQUEST-ID |
| Event-Driven Ansible リクエストのライフサイクル全体を通じて、プラットフォームゲートウェイからの HTTP リクエストを追跡します。これを使用して、UI アクションまたは API 呼び出しをバックエンド処理と関連付けます。 | HTTP 応答ヘッダーと Event-Driven Ansible ログエントリーに含まれます。 |
| Log Tracking ID |
| アクティベーションのライフサイクル を作成から完了まで追跡し、再起動後も複数のログファイルにわたって保持します。 | すべてのアクティベーション関連ログエントリーに含まれます。UI のアクティベーション History タブから取得できます。 |
| Activation Instance ID |
|
ルールブックのアクティベーションに含まれる 1 つの実行インスタンスに固有のログを特定し、その実行の | アクティベーションログに含まれます。 |
すべてのプロセスがユーザーまたは外部クライアントから発生するわけではありません。Event-Driven Ansible オーケストレーターが内部的にプロセス (例: モニター要求) をトリガーすると、そのプロセスのライフサイクルを追跡するために rid UUID が内部的に生成され、プラットフォームゲートウェイログには表示されません。
拡張ログ形式では、これらの識別子がメッセージの先頭に配置されるため、フィルタリングが容易になります。
[rid: <UUID>] [tid: <UUID>] [aiid: <ID>] aap_eda.tasks.orchestrator Processing request…
8.1.1. トラブルシューティングにログフィルタリングを使用する リンクのコピーリンクがクリップボードにコピーされました!
トラッキングの一意識別子を活用して、すべてのシステムログを効率的に検索およびフィルタリングする方法を学習します。このプロセスでは、特定のルールブックのアクティベーションまたは API リクエストの正確なタイムラインと失敗の原因を特定します。
手順
識別子を収集します。
-
問題が発生した場合は、UI の History タブ で、失敗したアクティベーションインスタンスのログから Log Tracking ID (
tid) を取得します。 -
問題がユーザーアクション (アクティベーションの再開など) によって発生した場合は、HTTP 応答ヘッダーから X-REQUEST-ID (
rid) を取得します。
-
問題が発生した場合は、UI の History タブ で、失敗したアクティベーションインスタンスのログから Log Tracking ID (
システムログを検索します。
- 収集された UUID を使用して、バックエンドログ (ワーカー、スケジューラー、API など) を検索します。これにより不要なノイズが除外され、すべてのサービスにわたって、特定のリクエストやアクティベーションの全体的なタイムラインを把握しやすくなります。
タイムラインを関連付けます。
-
共通の
tidを使用して、さまざまなログファイルとサービスにわたるアクティベーションの進行状況 (または失敗) を追跡します。
-
共通の
サポートツールを使用します。
-
必要に応じて、
sosreportまたはmustgatherツールを使用して、/var/log/ansible-automation-platform/eda/から関連するすべての Event-Driven Ansible ログを自動的に収集します。
-
必要に応じて、
8.2. アクティベーションが Pending 状態でスタックする リンクのコピーリンクがクリップボードにコピーされました!
ルールブックアクティベーションが Pending 状態でスタックする場合は、次の手順を実行します。
手順
他に実行中のアクティベーションがあるか、制限 (メモリーや CPU の制限など) に達していないかを確認します。
- 他のアクティベーションが実行中の場合は、可能であれば 1 つ以上のアクティベーションを終了します。
そうでない場合は、デフォルトのワーカー、Redis、およびアクティベーションワーカーがすべて実行されていることを確認します。すべてのシステムが期待どおりに動作している場合は、ワーカー、スケジューラー、API、nginx コンテナーおよびサービス内の eda-server 内部ログをチェックして、問題を特定できるか確認します。
注記これらのログは、コードが出力した例外、ネットワークの問題によるランタイムエラー、ルールブックコードのエラーなど、問題の原因を明らかにします。内部ログに解決につながる情報が含まれていない場合は、Red Hat サポートに問題を報告してください。
調整が必要な場合は、ルールブックアクティベーションの同時実行数の変更 を参照してください。
注記OpenShift Container Platform デプロイメントで Ansible Automation Platform Operator の最大同時アクティベーション数を調整するには、OpenShift Container Platform へのインストール の Event-Driven Ansible Controller のインストール中またはインストール後にルールブックアクティベーションの同時実行数を変更する を参照してください。
8.3. アクティベーションが繰り返し再起動する リンクのコピーリンクがクリップボードにコピーされました!
ルールブックアクティベーションの再起動が繰り返される場合は、次の手順を実行します。
手順
- Ansible Automation Platform にログインします。
- ナビゲーションパネルから、 → を選択します。
- Rulebook Activations ページで、再起動を繰り返すアクティベーションをリストから選択します。Details ページが表示されます。
- 詳細は、History タブをクリックし、再起動を繰り返すルールブックアクティベーションを選択します。Details タブが表示され、出力情報が表示されます。
アクティベーションの Restart policy フィールドを確認します。
ここでは、On failure (コンテナープロセスが失敗した場合にルールブックアクティベーションを再起動)、Always (成功または失敗にかかわらず常に再起動し、再起動は 5 回まで)、Never (コンテナープロセスが終了したら決して再起動しない) のいずれかを選択できます。
- ルールブックアクティベーションの再起動ポリシーが On failure に設定されていることを確認します。これは、何らかの問題が原因で失敗していることを示しています。
- ルールブックアクティベーションの YAML コードとインスタンスログでエラーを確認することで、問題を診断できる場合があります。
- 再起動ポリシーの値から解決策を判断できない場合は、ログレベル に関連する次の手順に進みます。
アクティベーションのログレベルを確認します。
- デフォルトのログレベルが Error の場合は、Rulebook Activation ページに戻り、ルールブックアクティベーションの設定 で説明されている手順を実行してアクティベーションを再作成します。
- Log level を Debug に変更します。
- アクティベーションを再度実行し、アクティベーションの詳細ページから History タブに移動します。
- History ページで、最近のアクティベーションの 1 つをクリックし、Output を表示します。
8.4. ルールブックの有効化によってイベントが処理されない リンクのコピーリンクがクリップボードにコピーされました!
ルールブックのアクティベーションは実行されているにもかかわらず、イベントが処理されていない場合、最も一般的に、想定のイベントソースとルールブックで定義されたソースが一致していないことが原因です。
手順
- ルールブックのソースを確認します。ルールブック YAML で定義されているソースプラグインを確認します (例: ansible.eda.webhook、ansible.eda.kafka)。
- イベント入力を検証します。Event-Driven Ansible コントローラーに送信するイベントが、ルールブックで定義されているソースプラグインと互換性があることを確認します。ルールブックが Kafka メッセージを想定している場合、汎用 Webhook イベントは処理できません。
- アクティベーションマッピングを確認します。イベントストリームを使用している場合は、アクティベーションのセットアップ中に正しいイベントストリームがルールブックにマッピングされていることを確認します。ここで不一致があると、アクティベーションでデータが受信されなくなります。
8.5. イベントを受信したにもかかわらずアクションがトリガーされない リンクのコピーリンクがクリップボードにコピーされました!
ルールブックのアクティベーションが Running で、イベントを正常に受信しているにもかかわらず、アクションが実行されていない場合は、ルールブックのロジック内に問題がある可能性があります。
手順
- ルール条件を確認します。ルールブック YAML を確認して、条件 (when ステートメント) が正確に記述されており、受信イベントペイロードの構造と値と正確に一致していることを確認します。
- インデントと構文を確認します。単純なエラーによりルールエンジンが条件を評価できなくなる可能性があるため、すべてのルールブックの構文とインデントが正しいことを確認します。
-
アクションを検証します。指定されたアクションが認識され、正しく設定されたアクションであることを確認します (適切な引数を持つ
run_job_templateなど)。
8.6. イベントストリームがアクティベーションにイベントを送信しない リンクのコピーリンクがクリップボードにコピーされました!
イベントストリームを使用してルールブックアクティベーションにイベントを送信する場合、イベントがルールブックアクティベーションに正常にルーティングされないことがあります。
手順
これを解決するには、次のオプションを試してください。
- Event-Driven Ansible Controller の各イベントストリームが Test モードに なっていない ことを確認します。これは、アクティベーションがイベントを受信しないことを意味します。
- 元のサービスが要求を適切に送信していることを確認します。
- プラットフォームゲートウェイインスタンスへのネットワーク接続が安定していることを確認します。イベントストリームを設定している場合、これは送信者からのイベントストリーム要求のエントリーです。
- プラットフォームゲートウェイのプロキシーが実行されていることを確認します。
- イベントストリームワーカーが起動して実行されており、要求を処理できることを確認します。
- イベントストリームで認証情報が正しく設定されていることを確認します。
要求が、設定された認証情報に基づく認証メカニズムに準拠していることを確認します (たとえば、Basic には認証情報を含むヘッダーが含まれている必要があり、HMAC にはヘッダー内のコンテンツに署名が含まれている必要があります)。
注記Event-Driven Ansible Controller で変更された認証情報が、元のサービスで更新されない可能性があります。
- アクティベーションで実行されているルールブックがこれらのイベントに反応することを確認します。これが確認できれば、イベントソースの記述 と、入ってくるイベントを処理するアクションの追加は完了していることになります。そうでなければ、イベントはアクティベーションに到達はするものの、それをアクティブ化するものが何もない状態です。
- 自己署名付き証明書を使用している場合は、ベンダーから Webhook を送信するときに証明書の検証を無効にすることが推奨されます。ほとんどのベンダーには、テスト用または非実稼働環境用の証明書検証を無効にするオプションがあります。
8.7. アクティベーションの実行中に 2.5 Automation Controller に接続できない リンクのコピーリンクがクリップボードにコピーされました!
アクティベーションを実行すると、Automation Controller への接続に失敗する場合があります。
手順
問題を解決するには、Red Hat Ansible Automation Platform の認証情報を設定し、正しい Automation Controller URL を取得していることを確認します。
- Red Hat Ansible Automation Platform の認証情報を設定していない場合は、Red Hat Ansible Automation Platform 認証情報の設定 の手順を実行します。この認証情報のホストが https://<your_gateway>/api/controller の URL 形式で設定されていることを確認します。
- このプロセスを完了したら、ルールブックアクティベーションを再度設定します。
第9章 ルール監査 リンクのコピーリンクがクリップボードにコピーされました!
ルール監査では、ある時点においてアクティブ化されたすべてのルールによってトリガーされたルールを監査できます。
Rule Audit リストビューには、ルールブック内の条件と一致してアクションをトリガーしたイベントを受信した各タイミングのリストが表示されます。リストにはルールブック内のルールが表示され、各見出しに実行されたルール名が表示されます。
9.1. ルール監査の詳細の表示 リンクのコピーリンクがクリップボードにコピーされました!
Rule Audit リストビューから、特定のアクションをトリガーしたイベントを確認できます。
手順
- ナビゲーションパネルから → を選択します。
- 目的のルールを選択すると、Details タブが表示されます。
結果
ここから、作成日時、最後に起動した日時、および対応するルールブックアクティベーションを確認できます。
9.2. ルール監査イベントの表示 リンクのコピーリンクがクリップボードにコピーされました!
特定のルールを選択して対応するイベントのリストを表示し、各イベントのログ、ソースタイプ、タイムスタンプを調べて詳細情報を確認できます。
手順
- ナビゲーションパネルから、 → を選択します。
- 目的のルールを選択すると、Details タブが表示されます。アクションをトリガーしたすべてのイベントを表示するには、Events タブを選択します。選択すると、アクションをトリガーしたイベントが表示されます。
- イベントを選択すると、Event log が Source type と Timestamp とともに表示されます。
9.3. ルール監査アクションの表示 リンクのコピーリンクがクリップボードにコピーされました!
特定のルールを選択すると、対応するアクションのリストが表示され、その出力を表示できます。
手順
- ナビゲーションパネルから → を選択します。
- 目的のルールを選択してから、Actions タブを選択します。
結果
ここから、実行されたアクションを確認できます。一部のアクションは、自動化実行にリンクされています。そこで出力を確認できます。
第10章 簡易イベントルーティング リンクのコピーリンクがクリップボードにコピーされました!
簡易イベントルーティングを使用すると、Event-Driven Ansible Controller でイベントストリームを使用してさまざまなリモートシステムからデータをキャプチャーおよび分析できます。イベントストリームを使用すると、GitHub や GitLab などのリモートシステムから Event-Driven Ansible Controller にイベントを送信できます。ルールブック内のソースを交換することで、アクティベーションに 1 つ以上のイベントストリームを割り当てることができます。
イベントストリームは、ソースをルールブックに接続する簡単な方法です。この機能を使用すると、1 つのエンドポイントを作成してイベントソースからアラートを受信し、複数のルールブックでイベントを使用できます。
10.1. イベントストリーム リンクのコピーリンクがクリップボードにコピーされました!
イベントストリームは、リモートシステムから Event-Driven Ansible Controller にイベントを送信できます。一般的なセットアップでは、サーバーからインターネット経由でイベントストリームにデータを送信し、さらに Event-Driven Ansible イベントストリームレシーバーに送信します。データをインターネット経由で送信する場合、要求を認証する必要があります。Webhook ベンダーまたはリモートシステムによって、認証方法が異なる場合があります。
Event-Driven Ansible Controller は、6 つの異なるイベントストリームタイプをサポートしています。
| 型 | Description | ベンダー |
|---|---|---|
| HMAC | Hashed Message Authentication Code (HMAC)。Event-Driven Ansible Controller とベンダーの Webhook サーバー間の共有シークレットを使用します。これによりメッセージの整合性が保証されます。 | GitHub |
| Basic 認証 | HTTP Basic 認証を使用します。 | Datadog、Dynatrace |
| トークン認証 | トークン認証を使用します。通常、HTTP ヘッダーは Authorization ですが、Gitlab などの一部のベンダーは X-Gitlab-Token を使用します。 | Gitlab、ServiceNow |
| OAuth2 | クライアントクレデンシャル と呼ばれる付与タイプで Machine-to-Machine (M2M) モードを使用します。トークンは不透明です。 | Dynatrace |
| JWT を使用した OAuth2 | クライアントクレデンシャル と呼ばれる付与タイプで M2M モードを使用します。トークンは JSON Web Token (JWT) です。 | Datadog |
| ECDSA | Elliptic Curve Digital Signature Algorithm | SendGrid、Twilio |
Event-Driven Ansible Controller は、6 つの基本的なイベントストリームタイプに基づく 4 つの他の特殊なイベントストリームもサポートしています。
- GitLab Event Stream
- GitHub Event Stream
- ServiceNow Event Stream
- Dynatrace Event Stream
これらの特殊なタイプでは、デフォルト値が追加されているため、使用するパラメーターが制限されます。たとえば、GitHub Event Stream は、HMAC Event Stream を特殊化したものであり、多くのフィールドがあらかじめ入力されています。GitHub Event Stream の認証情報を保存すると、GitHub Event Stream の推奨デフォルト値が表示されます。
10.2. イベントストリームの認証情報の作成 リンクのコピーリンクがクリップボードにコピーされました!
イベントストリームを使用する前に、イベントストリームの認証情報を作成する必要があります。
前提条件
- 各イベントストリームに認証情報が 1 つだけ存在する。
手順
- Ansible Automation Platform ダッシュボードにログインします。
- ナビゲーションパネルから、 → → を選択します。
- をクリックします。
以下を入力します。
- Name
- 名前を入力します。
- Description
- このフィールドは任意です。
- Organization
- リストをクリックして組織を選択するか、Default を選択します。
- Credential type
リストをクリックして認証情報タイプを選択します。
注記認証情報タイプを選択すると、Type Details セクションと、選択した認証情報タイプに適用できるフィールドが表示されます。
- Type Details
- 選択した認証情報タイプに応じて要求される情報を追加します。たとえば、GitHub Event Stream 認証情報タイプを選択した場合は、Event-Driven Ansible Controller とリモートサーバーの間に HMAC Secret (対称共有シークレット) を追加する必要があります。
- をクリックします。
結果
Details ページが表示されます。そのページまたは Credentials リストビューから、認証情報を編集または削除できます。
10.3. イベントストリームの作成 リンクのコピーリンクがクリップボードにコピーされました!
ルールブックアクティベーションに割り当てるイベントストリームを作成できます。
前提条件
- イベントストリームをルールブックアクティベーションに割り当てる場合は、アクティベーションに決定環境とプロジェクトがすでに設定されていることを確認する。
- Automation Controller に接続してルールブックアクティベーションを実行する予定の場合は、決定環境とプロジェクトに加えて、Red Hat Ansible Automation Platform 認証情報タイプが作成済みであることを確認する。詳細は、Red Hat Ansible Automation Platform 認証情報の設定 を参照してください。
手順
- Ansible Automation Platform にログインします。
- ナビゲーションパネルから、 → を選択します。
- をクリックします。
以下を入力します。
- Name
- 名前を入力します。
- Organization
- リストをクリックして組織を選択するか、Default を選択します。
- Event stream type
目的のイベントストリームタイプを選択します。
注記このリストには、リモートサーバーからの接続を認証するために使用できるデフォルトのイベントストリームタイプが少なくとも 10 種類表示されます。
- Credentials
- リストから認証情報を選択します。イベントストリーム用に作成した認証情報を選択することを推奨します。
- Headers
イベントペイロードに含める HTTP ヘッダーキーをコンマで区切って入力します。
重要自動化がイベントペイロード内に存在する HTTP ヘッダーに依存している場合は、機密情報が意図せず公開されないように、それらを明示的に定義する必要があります。HTTP ヘッダーの詳細と、ヘッダーをセキュアに設定する方法は、HTTP ヘッダー および イベントストリーム用の HTTP ヘッダーのセキュアな設定 を参照してください。
- Forward events to rulebook activation
このオプションは、ルールブックアクティベーションにイベントを転送する機能を有効または無効にするために使用します。
注記イベントストリームのイベント転送は、接続を診断して受信データを評価する際に、テスト目的で無効にすることができます。Forward events to rulebook activation オプションを無効にすると、リモートシステムとイベントストリームの接続をテストし、ヘッダーとペイロードを分析し、必要に応じて認証情報の問題を診断できます。これにより、テスト中にイベントがルールブックアクティベーションに転送され、ルールや条件が誤ってトリガーされることがなくなります。企業によっては、機密情報やパスワードを定期的に変更するポリシーを設けている場合があります。このオプションは、イベントストリームの作成後、いつでも有効/無効にできます。
- をクリックします。
結果
イベントストリームを作成すると、以下が出力されます。
- Details ページが表示されます。そのページまたは Event Streams リストビューから、イベントストリームを編集または削除できます。また、Event Streams ページには、作成したすべてのイベントストリームと、各イベントの Events received、Last event received、および Event stream type 列が表示されます。最初の 2 つの列は、イベントストリームを通じて外部データを受信するため、リモートシステムからイベントを受信していることがわかるように、継続的に更新されます。
イベントストリームを無効にした場合、Details ページに This event stream is disabled という警告メッセージが表示されます。
注記イベントストリームの作成後、関連付けられている認証情報は、それが割り当てられているイベントストリームが削除されるまで削除できません。
- 新しいイベントストリームで、イベントを送信するリモートシステムで Webhook を設定するときに必要な URL が生成されます。
10.4. HTTP ヘッダー リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible およびイベントストリームでは、サードパーティーソース (GitHub、監視ツール、独自の Webhook など) から受信するイベントに必要なコンテキスト情報とセキュリティー情報を伝送するため、HTTP ヘッダーが不可欠です。これらには次の機能が含まれます。
- 認証と否認防止
-
これは最も重要な用途です。ヘッダーには、多くの場合、トークン、API キー、またはセキュリティー署名 (
X-Hub-Signatureヘッダーの HMAC など) が含まれており、Event-Driven Ansible はこれらを使用して 送信者のアイデンティティーを検証 し、イベントペイロードが改ざんされていないことを確認します。これにより、否認防止がサポートされます。つまりイベントが正当なソースから発生したことが証明されます。 - デバッグとログ
-
ヘッダーは、イベントのパスを追跡するための重要なデータポイント (
Date、User-Agent、X-Request-ID) を提供し、システム管理者と SRE がイベント処理の遅延または失敗に関連する問題を デバッグする のに役立ちます。
ヘッダーはすべての HTTP 通信に不可欠であり、複数の役割を果たします。
-
コンテキストとメタデータ: 送信されるデータに関する情報を記述します (例:
Content-Type: application/json, Content-Length: 1024)。 -
クライアント/サーバー機能: 送信者の機能または設定を受信側に通知します (例:
Accept-Language: en-US)。 -
認証/認可: セキュリティー認証情報を持ちます (例:
Authorization: Bearer <token>)。 -
キャッシュ: クライアントとプロキシーがコンテンツをキャッシュする方法を制御します (例:
Cache-Control: max-age=3600)。 -
ルーティングと追跡: 多くの場合、カスタムヘッダー (例:
X-Request-ID) を介して、ネットワークルーティングとトランザクション追跡を容易にします。
10.4.1. イベントストリームの HTTP ヘッダーをセキュアに設定する リンクのコピーリンクがクリップボードにコピーされました!
イベントストリームのセキュリティーを強化するには、渡される HTTP ヘッダーを明示的に定義する必要があります。これらのヘッダーには、処理に必要な重要なコンテキストと認証データが含まれます。
手順
すべての HTTP ヘッダーを含めるには、Headers フィールドにアスタリスク (*) を入力します。これにより、いくつかのヘッダーを除くすべての HTTP ヘッダーが許可されます。
-
Excluded:
X-Envoy、X-Trusted-Proxy、X-Forwarded-For、X-Real-Idで始まるヘッダー Redacted: 認証ヘッダー (例:
Authorization: Redacted)重要Headers フィールドが空の場合、実稼働モードとテストモードでは、イベントペイロードに HTTP ヘッダーは追加されません。
-
Excluded:
-
特定の HTTP ヘッダーセットを含めるには、必要なヘッダーの名前をコンマ区切りの文字列として入力します (例:
Host,Authorization,X-Request-ID)。
10.5. イベントを送信するようにリモートシステムを設定する リンクのコピーリンクがクリップボードにコピーされました!
イベントストリームを作成したら、イベントを Event-Driven Ansible Controller に送信するようにリモートシステムを設定する必要があります。この設定に使用する方法は、選択したイベントストリーム認証情報タイプのベンダーによって異なります。
前提条件
- イベントストリームを作成したときに生成された URL
- イベントストリーム認証情報に設定したシークレットまたはパスワード
手順
次の例は、GitHub などのリモートシステムで Webhook を設定して、イベントを Event-Driven Ansible Controller に送信する方法を示しています。Event-Driven Ansible Controller にイベントを送信するようにリモートシステムを設定する方法は、ベンダーごとに異なります。
- GitHub リポジトリーにログインします。
Your profile name → Your repositories をクリックします。
注記リポジトリーがない場合は、New をクリックして新しいリポジトリーを作成し、所有者を選択し、Repository name を追加して、Create repository をクリックします。
- Settings (ツールバー) に移動します。
- General ナビゲーションペインで、Webhooks を選択します。
- Add webhook をクリックします。
- Payload URL フィールドに、イベントストリームを作成したときに保存した URL を貼り付けます。
- Content type リストで application/json を選択します。
- Secret を入力します。
- Add webhook をクリックします。
結果
Webhook を追加したら、2 つのシステム (GitHub と Event-Driven Ansible Controller) 間の接続を確認するためにテストペイロードの送信を試みます。データを正常に送信できた場合は、Webhook URL の横に緑色のチェックマークが表示され、Last delivery was successful というメッセージが表示されます。
10.6. イベントストリームの動作確認 リンクのコピーリンクがクリップボードにコピーされました!
イベントストリームを使用してリモートシステムに接続し、データを受信できることを確認します。
- Ansible Automation Platform にログインします。
- ナビゲーションパネルから、 → を選択します。
- 作成したイベントストリームを選択して接続を検証し、イベントストリームがルールブックアクティベーションにデータを送信することを確認します。
イベントが受信されたことを確認します。Events received の数が、イベントの詳細を含むヘッダーとともに表示されます。
UI を下にスクロールすると、Webhook に関する詳細情報を含むペイロードのボディーも確認できます。
イベントストリームの Header セクションと Body セクションが Details ページに表示されます。これらはイベントを送信するベンダーによって異なります。ヘッダーとボディーを使用してイベントペイロード内の属性を確認できます。この情報は、ルールブックに条件を記述する際に役立ちます。
- Forward events to rulebook activation オプションを切り替えて、イベントをルールブックアクティベーションにプッシュできるようにします。
結果
これにより、イベントストリームが実稼働モードに移行し、ルールブックアクティベーションに簡単に割り当てることができるようになります。このオプションをオフにすると、ルールブックアクティベーションにイベントを転送する機能が無効になり、This event stream is disabled というメッセージが表示されます。
10.7. ソースの置き換えとアクティベーションへのイベントストリームの割り当て リンクのコピーリンクがクリップボードにコピーされました!
ルールブックアクティベーションを作成するときに、イベントストリームを使用して、ルールブックアクティベーション内のソースマッピングを交換し、外部ソースから Event-Driven Ansible Controller へのルーティングを簡素化できます。
ソースマッピングに関して留意すべき重要なポイントがいくつかあります。
- イベントストリームは、ルールブックソースの交換で 1 回だけ使用できます。ルールブックに複数のソースがある場合、各ソースを 1 回だけ置き換えることができます。
- ソースマッピングは、現在のルールブックアクティベーションでのみ実行されます。同じルールブックを使用する他のアクティベーションがある場合は、そのアクティベーションに対してこのプロセスを繰り返す必要があります。
- ソースマッピングは、ルールブックが変更されない場合に限り有効です。ソースマッピングプロセス中にルールブックが変更されると、ソースマッピングが失敗し、プロセスをやり直す必要があります。
- ソースマッピングの作成後にルールブックが変更され、再起動 が発生すると、ルールブックアクティベーションが失敗します。
手順
- Ansible Automation Platform にログインします。
- ナビゲーションパネルから、 → を選択します。
- をクリックします。
以下を入力します。
- Name
- 名前を入力します。
- Description
- このフィールドは任意です。
- Organization
- 組織名を入力するか、リストから Default を選択します。
- Project
プロジェクトはルールブックの論理的なコレクションです。このフィールドは任意です。
注記このフィールドは任意ですが、プロジェクトを選択すると、ルールブックの選択肢のリストを絞り込むのに役立ちます。
- Rulebook
選択したプロジェクトに応じてルールブックが表示されます。ルールブックを選択します。
注記ルールブックを選択すると、Event streams フィールドが有効になります。歯車アイコンをクリックすると、イベントストリームマッピングのフォームが表示されます。
- Event streams
イベントをルールブックアクティベーションに転送するように設定されている利用可能なイベントストリームがすべて表示されます。イベントストリームを作成していない場合、このフィールドは無効のままです。
歯車アイコンをクリックすると、イベントストリームマッピングの UI が表示されます。
以下のフィールドに入力します。
- Rulebook source
ルールブックには、複数のルールセットにわたる複数のソースを含めることができます。複数のアクティベーションで、同じルールブックを複数のイベントストリームにマッピングできます。イベントストリームを管理する際、名前のないソースに、識別のために一時的な名前 (__SOURCE {n}) が割り当てられます。
リストから __SOURCE_1 を選択します。
- Event stream
リストからイベントストリーム名を選択します。
をクリックします。
イベントストリームは、ルールブック内の一致するソースを置き換えることができます。イベントストリームは、さまざまなイベントソースをルールブックアクティベーションに接続できるようにするサーバー側の Webhook です。ansible.eda.pg_listener タイプのイベントストリームのソースに置き換えることができるソースタイプとしては、ansible.eda.webhook やその他の互換性のある Webhook ソースプラグインなどがあります。選択したソースを置き換えると、このアクティベーションにのみ影響が発生し、ルールブックのソースタイプ、ソース名、および引数が変更されます。フィルター、ルール、条件、アクションは、いずれも影響を受けません。
1 つのイベントストリームで置き換えるソースを選択できます。ルールブックに複数のソースがある場合は、各ソースをイベントストリームで置き換えることもできますが、各ソースを置き換える必要はありません。次の画像は、置き換えることができるソースを示しています。
ピンク色の項目は、置き換え可能なソース (ソースタイプ、ソース名、引数) を示しています。残りの項目 (フィルター、ルール、アクション) は置き換えられません。
- Credential
このルールブックアクティベーションの認証情報を 0 個以上選択します。このフィールドは任意です。
注記このフィールドに表示される認証情報は、ルールブックアクティベーションに基づいてカスタマイズされています。表示される認証情報のタイプは、Vault、Red Hat Ansible Automation Platform、または作成したカスタム認証情報タイプだけです。認証情報の詳細は、認証情報 を参照してください。
- Decision environment
決定環境は、Ansible ルールブックを実行するために使用するコンテナーイメージです。
注記Event-Driven Ansible Controller では、決定環境のプルポリシーをカスタマイズすることはできません。デフォルトでは、always ポリシーの動作に従います。アクティベーションが開始されるたびに、システムはイメージの最新バージョンを取得しようとします。
- Restart policy
これは、ソースプラグインを実行しているコンテナープロセスが終了した後にアクティベーションを再開する方法を決定するポリシーです。
Policies:
- Always: ルールブックアクティベーションが正常に終了したかどうかに関係なく、ルールブックアクティベーションを直ちに再開します。これは 5 回まで実行されます。
- Never: コンテナープロセスが終了したときに、ルールブックアクティベーションを再開しません。
- On failure: コンテナープロセスが失敗した場合にのみ、デフォルトで 60 秒後にルールブックアクティベーションを再開します。これは 5 回まで実行されます。
- Log level
このフィールドでは、ログに記録するイベントの重大度とコンテンツのタイプを定義します。
Levels:
- Error: アクティベーションの History タブに表示されるエラーメッセージを含むログ。
- Info: 成功または失敗、トリガーされたアクション名と関連するアクションイベント、エラーなど、ルールブックアクティベーションに関する有用な情報を含むログ。
- Debug: デバッグフェーズでのみ役立ち、運用時にはあまり有用でない可能性がある情報を含むログ。このログレベルでは、エラーデータとログレベルデータの両方が対象となります。
- Service name
- これは、アクティベーションによりポートが公開される場合に、Kubernetes が受信接続を設定するためのサービス名を定義します。このフィールドは任意です。
- Rulebook activation enabled?
- これを選択すると、ルールブックアクティベーションが自動的に有効になります。
- Variables
-
ルールブックの変数は JSON または YAML 形式です。内容は、ansible-rulebook コマンドの
--varsフラグによって渡されるファイルと同等です。 - Options
- ルール監査にイベントを表示しない場合は、Skip audit events オプションをオンにします。
- をクリックします。
結果
ルールブックアクティベーションを作成すると、Details ページが表示されます。Event streams ページに移動すると、イベントが受信されたことを確認できます。
10.8. イベントストリームタイプからの Webhook データの再送信 リンクのコピーリンクがクリップボードにコピーされました!
作成したイベントストリームでソースを置き換えたら、イベントストリームからデータを再送信して、ルールブックアクティベーションにデータが割り当てられていることを確認できます。先ほど示した例では、GitHub イベントストリームを使用しました。次の例は、GitHub イベントストリームを使用している場合に Webhook データを再送信する方法を示しています。
手順
- GitHub Webhook / Manage webhook ページに戻ります。
- Recent Deliveries タブをクリックします。
- をクリックします。
- をクリックします。Redeliver payload? ウィンドウに送信に関するメッセージが表示されます。
- Yes, redeliver this payload をクリックします。
- Ansible Automation Platform に戻り、ルール監査を確認します。
10.9. Rule Audit で新しいイベントストリームのイベントを確認する リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible Controller によってイベントが送受信されたら、Rule Audit ページに移動してイベントストリームの結果を表示することで、アクションがトリガーされたことを確認できます。
手順
- Ansible Automation Platform にログインします。
- ナビゲーションパネルから、 → を選択します。
結果
選択したイベントストリームタイプからのイベントデータがルールブックアクティベーションに届いた場合、Rule Audit ページに、Status、Rulebook activation、および Last fired date フィールドの結果が表示されます。
第11章 Event-Driven Ansible Controller のパフォーマンスチューニング リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible は、非常にスケーラブルで柔軟な自動化機能です。Event-Driven Ansible Controller は、Event-Driven Ansible による自動化を実行するインターフェイスを提供します。Event-Driven Ansible Controller をチューニングし、次の方法でパフォーマンスとスケーラビリティーを最適化します。
- ワークロードの特性評価
- システムレベルの監視
- パフォーマンスのトラブルシューティング
11.1. ワークロードの特性評価 リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible Controller では、ワークロードに、ルールブックアクティベーションの数と受信するイベントの数が含まれます。Event-Driven Ansible Controller のワークロードの特性を評価する際には、次の要素を考慮してください。
- ルールブックアクティベーションの同時実行数
- Event-Driven Ansible Controller が受信するイベントの数
11.2. ルールブックアクティベーションごとのデフォルトのメモリー制限の変更 リンクのコピーリンクがクリップボードにコピーされました!
メモリー使用量は、Event-Driven Ansible Controller が処理する必要のあるイベントの数に基づいています。デフォルトでは、ルールブックアクティベーションコンテナーごとに 200 MB のメモリー制限があります。たとえば、CPU が 4 個、RAM が 16 GB の場合、割り当てられたメモリー制限が 200 MB のルールブックアクティベーションコンテナー 1 つでは、1 分あたり 150,000 件を超えるイベントを処理できません。並行して実行されるルールブックアクティベーションの数が多い場合は、各ルールブックアクティベーションが処理できるイベントの最大数は少なくなります。非常に高いレートでの受信イベントが多すぎる場合、コンテナーはイベントを処理しようとしてメモリー不足になる可能性があります。これによりコンテナーが強制終了され、ルールブックアクティベーションはステータスコード 137 で失敗します。
この状態を軽減するには、インストール 中 またはインストール 後 に、各ルールブックのアクティブ化のデフォルトメモリー制限を変更できます。
手順
インストール 中 にルールブックのアクティブ化のデフォルトメモリー制限を変更するには、次の手順を実行します。
- セットアップインベントリーファイルに移動します。
-
[all:vars] セクションに
automationedacontroller_podman_mem_limitを追加します。たとえば、automationedacontroller_podman_mem_limit='400m'などです。 - セットアップを実行します。
インストール 後 にルールブックのアクティベーションのデフォルトのメモリー制限を変更するには、次の手順を実行します。
-
/etc/ansible-automation-platform/eda/settings.yamlにある環境ファイルに移動します。 -
デフォルトのコンテナーのメモリー制限を変更します。たとえば、
PODMAN_MEM_LIMIT = '300m'です。 -
automation-eda-controller-service restartを使用して、Event-Driven Ansible Controller サービスを再起動します。
-
11.3. 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 が実行しているルールブックアクティベーションが多すぎるか、または個々のルールブックアクティベーションの一部で大量のリソースを使用していることを示しています。このような場合は、ワークロードをサポートするためにシステムレベルのリソースを増やす必要があります。
第12章 イベントフィルタープラグイン リンクのコピーリンクがクリップボードにコピーされました!
イベントには、ルールエンジンに過度の負荷をかける余分なデータが含まれている場合があります。イベントフィルターを使用して余分なデータを削除することで、ルールにとって重要なものに絞り込むことができます。イベントフィルターは、ルール条件とデータの照合をより適切に行うために、データの形式を変更することもあります。
イベントは Python コードとして定義され、コレクションとして提供されます。デフォルトの eda コレクション には次のフィルターがあります。
| 名前 | 説明 |
|---|---|
| json_filter | このフィルターは、イベントオブジェクトからキーを追加または除外します。 |
| dashes_to_underscores | このフィルターは、ペイロード内のすべてのキーのダッシュをアンダースコアに変更します。 |
| ansible.eda.insert_hosts_to_meta | このフィルターは、ansible-rulebook がイベントを検出して使用できるように、イベントにホスト情報を追加するために使用されます。 |
| ansible.eda.normalize_keys | このフィルターは、英数字以外のキーをアンダースコアに変更する場合に使用します。 |
イベントフィルターは次々と連結することができます。その場合、更新されたデータが、フィルターから次のフィルターに送信されます。イベントフィルターは、ソースを定義した後にルールブックで定義します。ルールブックがソースプラグインを起動すると、正しいフィルターが関連付けられ、データがキューに追加される前に変換されます。
sources:
- name: azure_service_bus
ansible.eda.azure_service_bus:
conn_str: "{{connection_str}}"
queue_name: "{{queue_name}}"
filters:
- json_filter:
include_keys: ['clone_url']
exclude_keys: ['*_url', '_links', 'base', 'sender', 'owner', 'user']
- dashes_to_underscores:
この例では、データがまず json_filter を通過し、次に dashes_to_underscores フィルターを通過します。イベントペイロードでは、キーに文字、数字、アンダースコアのみを含めることができます。ネストされたキーにアクセスするには、ピリオド (.) を使用します。
すべてのイベントはイベントの発生元を記録する必要があるため、source name、type、および received_at を追加するために、フィルター eda.builtin.insert_meta_info が ansible-rulebook によって自動的に追加されます。received_at には、日付時刻が UTC ISO8601 形式で格納され、マイクロ秒が含まれます。uuid には、イベントの一意の ID が格納されます。meta key は、イベントに関するメタデータを格納するために使用されます。これは、aap サーバー内のイベントを正確に報告するために必要です。
12.1. イベントフィルターの作成 リンクのコピーリンクがクリップボードにコピーされました!
イベントフィルターは、イベントデータに対して変換を実行する Python モジュール内の関数です。イベントフィルターを使用すると、イベントデータ構造内の任意のデータを削除、追加、変更、または移動できます。イベントフィルターは、イベントを最初の引数として受け取ります。ルールブックの設定によって、追加のキーワード引数が提供されます。
基本的な構造は次のとおりです。
# my_namespace.my_collection/extensions/eda/plugins/event_filter/my_filter.py
def main(event: dict, arg1, arg2):
# Process event data here
return event
このフィルターをルールブックで使用するには、イベントソースのフィルターリストに追加します。
sources:
- name: azure_service_bus
ansible.eda.azure_service_bus:
conn_str: "{{connection_str}}"
queue_name: "{{queue_name}}"
filters:
- my_namespace.my_collection.my_filter:
arg1: hello
arg2: world
関連情報
第13章 Event-Driven Ansible ロギングストラテジー リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible は、リソースに対する監査ログソリューションを提供します。サポートされている作成、読み取り、更新、削除 (CRUD) 操作が、ルールブックアクティベーション、イベントストリーム、決定環境、プロジェクト、アクティベーションに対してそれぞれ記録されます。これらのリソースの一部は、同期、有効化、無効化、再起動、起動、停止などの追加の操作をサポートしており、これらの操作のログ記録もサポートされています。これらのログは、関連付けられているコンテナーのライフサイクル期間中のみ保持されます。サポートされている各ログ操作は、次のサンプルログを参照してください。
13.1. ロギングのサンプル リンクのコピーリンクがクリップボードにコピーされました!
各操作に対して次の API が呼び出されると、次の監査ログが表示されます。
- ルールブックアクティベーション
1. Create
1. 2024-08-15 14:13:20,384 aap_eda.api.views.activation INFO Action: Create / ResourceType: RulebookActivation / ResourceName: quick_start_project / ResourceID: 53 / Organization: Default
2. Read
1. 2024-08-15 14:21:26,844 aap_eda.api.views.activation INFO Action: Read / ResourceType: RulebookActivation / ResourceName: quick_start_activation / ResourceID: 1 / Organization: Default
3. Disable
1. 2024-08-15 14:23:57,798 aap_eda.api.views.activation INFO Action: Disable / ResourceType: RulebookActivation / ResourceName: quick_start_activation / ResourceID: 1 / Organization: Default
4. Enable
1. 2024-08-15 14:24:16,472 aap_eda.api.views.activation INFO Action: Enable / ResourceType: RulebookActivation / ResourceName: quick_start_activation / ResourceID: 1 / Organization: Default
5. Delete
1. 2024-08-15 14:24:53,847 aap_eda.api.views.activation INFO Action: Delete / ResourceType: RulebookActivation / ResourceName: quick_start_activation / ResourceID: 1 / Organization: Default
6. Restart
2024-08-15 14:24:34,169 aap_eda.api.views.activation INFO Action: Restart / ResourceType: RulebookActivation / ResourceName: quick_start_activation / ResourceID: 1 / Organization: Default
- EventStream ログ
1. Create
1. 2024-08-15 13:46:26,903 aap_eda.api.views.webhook INFO Action: Create / ResourceType: EventStream / ResourceName: ZackTest / ResourceID: 1 / Organization: Default
2. Update
1. 2024-08-15 13:56:17,440 aap_eda.api.views.webhook INFO Action: Update / ResourceType: EventStream / ResourceName: ZackTest / ResourceID: 1 / Organization: Default
3. Read
1. 2024-08-15 13:56:56,271 aap_eda.api.views.webhook INFO Action: Read / ResourceType: EventStream / ResourceName: ZackTest / ResourceID: 1 / Organization: Default
4. List
1. 2024-08-15 13:56:17,492 aap_eda.api.views.webhook INFO Action: List / ResourceType: EventStream / ResourceName: * / ResourceID: * / Organization: *
5. Delete
1. 2024-08-15 13:57:13,124 aap_eda.api.views.webhook INFO Action: Delete / ResourceType: EventStream / ResourceName: ZackTest / ResourceID: None / Organization: Default
- 決定環境
1. Create
1. 2024-08-15 14:10:53,311 aap_eda.api.views.decision_environment INFO Action: Create / ResourceType: DecisionEnvironment / ResourceName: quick_start_de / ResourceID: 86 / Organization: Default
2. Read
1. 2024-08-15 14:10:53,349 aap_eda.api.views.decision_environment INFO Action: Read / ResourceType: DecisionEnvironment / ResourceName: quick_start_de / ResourceID: 86 / Organization: Default
3. Update
2024-08-15 14:11:20,970 aap_eda.api.views.decision_environment INFO Action: Update / ResourceType: DecisionEnvironment / ResourceName: quick_start_de / ResourceID: 86 / Organization: Default
4. Delete
2024-08-15 14:11:42,369 aap_eda.api.views.decision_environment INFO Action: Delete / ResourceType: DecisionEnvironment / ResourceName: quick_start_de / ResourceID: None / Organization: Default
- プロジェクト
1. Create
1. 2024-08-15 14:05:26,874 aap_eda.api.views.project INFO Action: Create / ResourceType: Project / ResourceName: quick_start_project / ResourceID: 86 / Organization: Default
2. Read
1. 2024-08-15 14:05:26,913 aap_eda.api.views.project INFO Action: Read / ResourceType: Project / ResourceName: quick_start_project / ResourceID: 86 / Organization: Default
3. Update
1. 2024-08-15 14:06:08,255 aap_eda.api.views.project INFO Action: Update / ResourceType: Project / ResourceName: quick_start_project / ResourceID: 86 / Organization: Default
4. Sync
1. 2024-08-15 14:06:30,580 aap_eda.api.views.project INFO Action: Sync / ResourceType: Project / ResourceName: quick_start_project / ResourceID: 86 / Organization: Default
5. Delete
1. 2024-08-15 14:06:49,481 aap_eda.api.views.project INFO Action: Delete / ResourceType: Project / ResourceName: quick_start_project / ResourceID: 86 / Organization: Default
- アクティベーションの開始/停止
1. Start
1. 2024-08-15 14:21:29,076 aap_eda.services.activation.activation_manager INFO Requested to start activation 1, starting.
2024-08-15 14:21:29,093 aap_eda.services.activation.activation_manager INFO Creating a new activation instance for activation: 1
2024-08-15 14:21:29,104 aap_eda.services.activation.activation_manager INFO Starting container for activation instance: 1
2. Stop
1. eda-activation-worker-1 | 2024-08-15 14:40:52,547 aap_eda.services.activation.activation_manager INFO Stop operation requested for activation id: 2 Stopping activation.
eda-activation-worker-1 | 2024-08-15 14:40:52,550 aap_eda.services.activation.activation_manager INFO Activation 2 is already stopped.
eda-activation-worker-1 | 2024-08-15 14:40:52,550 aap_eda.services.activation.activation_manager INFO Activation manager activation id: 2 Activation restart scheduled for 1 second.
eda-activation-worker-1 | 2024-08-15 14:40:52,562 rq.worker INFO activation: Job OK (activation-2)