自動化決定の使用

手順

1. Ansible Automation Platform ダッシュボードにログインします。
2. ナビゲーションパネルから、Automation Decisions → Infrastructure → Credentials を選択します。
3. Create credential をクリックします。

4. 以下を入力します。

   Name

   名前を入力します。

   Description

   このフィールドは任意です。

   Organization

   リストをクリックして組織を選択するか、Default を選択します。

   Credential type

   リストをクリックして認証情報タイプを選択します。

   注記

   認証情報タイプを選択すると、Type Details セクションと、選択した認証情報タイプに適用できるフィールドが表示されます。

5. 選択した認証情報タイプに該当するフィールドに入力します。
6. Create credential をクリックします。

手順

1. 以下のいずれかの方法を使用して、認証情報を編集します。

   • Credentials リストビューで、必要な認証情報の横にある Edit credential アイコンをクリックします。
   • Credentials リストビューで認証情報の名前を選択し、Edit credential をクリックします。
2. 適切な詳細を編集し、Save credential をクリックします。

手順

1. Credentials リストページで、複製する認証情報の名前をクリックします。認証情報の Details タブに移動します。

2. Details タブの右上にある Duplicate credential をクリックします。

   注記

   Credentials リストページで、目的の認証情報の横にある Duplicate credential アイコンをクリックすることもできます。

   選択した認証情報が複製されたことを確認するメッセージ ("<Name of credential> duplicated.") が表示されます。

3. Back to credentials タブをクリックして、複製した認証情報を表示します。

   複製した認証情報の名前は、元の認証情報名の後ろに 24 時間形式のタイムスタンプが付いたものになります (例: <認証情報の名前> @ 17:26:30)。

4. 複製した認証情報の希望する詳細を編集します。
5. Save credential をクリックします。

手順

1. 以下のいずれかの方法を使用して、認証情報を削除します。

   • Credentials リストビューで、必要な認証情報の横にある More Actions アイコン ⋮ をクリックし、Delete credential をクリックします。
   • Credentials リストビューで認証情報の名前を選択し、Edit credential の横にある More Actions アイコン ⋮ をクリックして、Delete credential をクリックします。

2. ポップアップウィンドウで、Yes, I confirm that I want to delete this credential を選択します。

   注記

   認証情報が組織内の他のリソースによってまだ使用されている場合は、認証情報を削除できないことを知らせる警告メッセージが表示されます。また、認証情報がイベントストリームで使用されている場合は、イベントストリームが削除されるか、別の認証情報に割り当てられるまで、認証情報を削除することはできません。一般に、使用中の認証情報を削除するとアクティベーションが壊れる可能性があるため、削除することは避けてください。

3. Delete credential をクリックします。

手順

1. Ansible Automation Platform ダッシュボードにログインします。
2. ナビゲーションパネルから、Automation Decisions → Infrastructure → Credential Types を選択します。
3. Create credential type をクリックします。

4. 以下を入力します。

   Name

   名前を入力します。

   Description

   このフィールドは任意です。

5. Input Configuration フィールドで、対象のタイプの順序付きフィールドのセットを定義する入力スキーマを指定します。形式は YAML または JSON です。

   YAML

   fields:
     - type: string
       id: username
       label: Username
     - type: string
       id: password
       label: Password
       secret: true
   required:
     - username
     - password

   Copy to Clipboard Toggle word wrap

   YAML ページ でさらに YAML の例をご覧ください。

   JSON

   {
   "fields": [
     {
     "type": "string",
     "id": "username",
     "label": "Username"
     },
     {
     "secret": true,
     "type": "string",
     "id": "password",
     "label": "Password"
      }
     ],
    "required": ["username", "password"]
   }

   Copy to Clipboard Toggle word wrap

   その他の JSON の例は、JSON Web サイト をご覧ください。

6. Injector Configuration フィールドに、認証情報タイプが注入できる値を指定する環境変数または追加変数を入力します。形式は YAML または JSON に指定できます (前の手順の例を参照)。

   JSON 形式の次の設定は、各フィールドとその使用方法を示しています。

   {
       "extra_vars": {
         "some_extra_var": "{{ username }}:{{ password }}"
     }
   }

   Copy to Clipboard Toggle word wrap

7. Create credential type をクリックします。

   新しく作成した認証情報タイプが、認証情報タイプのリストに表示されます。

8. Edit credential type アイコンをクリックして、認証情報タイプのオプションを変更します。

手順

1. Ansible Automation Platform ダッシュボードにログインします。
2. Automation Decisions → Projects に移動します。
3. Create project をクリックします。

4. 以下を入力します。

   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 モジュールに渡されます)。このパラメーターにより、他の方法では利用できないブランチフィールド経由の参照にアクセスできるようになります。このフィールドはオプションであり、編集可能です。このフィールドの編集がルールブックのアクティブ化に与える影響に関する詳細は、プロジェクトの編集 を参照してください。

   Source control credential

   これは、提供された Source control URL で認証するために使用されるオプションの認証情報です。

   Content signature validation credential

   コンテンツ署名を有効にして、プロジェクトの同期時にコンテンツがセキュアな状態に保たれていることを検証します。コンテンツが改ざんされている場合、ジョブは実行されません。このフィールドは任意です。

   オプション

   Verify SSL オプションはデフォルトで有効になっています。このオプションが有効になっていると、プロジェクトのインポート時に SSL が HTTPS で検証されます。

   注記

   自己署名付き証明書を使用するローカルリポジトリーがある場合は、このオプションを無効にできます。

5. Create project を選択します。

手順

1. Projects リストビューで、目的のプロジェクトの横にある More Actions アイコン ⋮ を選択します。Edit ページが表示されます。

2. 必要なフィールドを編集します。

   重要

   プロジェクトの Source control URL、Source control ブランチ/タグ/コミット、または Source control refspec を更新すると、Event-Driven Ansible によってプロジェクトの再同期が自動的にトリガーされます。このプロセスは、Event-Driven Ansible コントローラー内で利用可能なルールブックを更新し、既存のルールブックのアクティベーションに大きな影響を与える可能性があります。

   • ルールブックのコンテンツの更新: ルールブックのコンテンツが変更されても、実行中のアクティベーションでは古いコンテンツが引き続き使用されます。新しいコンテンツを適用するには、影響を受けるルールブックのアクティベーションを再起動する必要があります。更新するルールブックのコンテンツがイベントストリームを使用するアクティベーションにアタッチされている場合は、更新を適用した後でイベントストリームをそのアクティベーションに再度アタッチし、アクティベーションを再起動する必要があります。
   • 新しいルールブック: リポジトリーに追加された新しいルールブックは、同期後にデータベースで使用できるようになります。
   • 削除されたルールブック: 削除されたルールブックは、同期時にデータベースから削除されます。ただし、関連するアクティベーションは引き続き実行され、再起動できます。ソースルールブックから切り離されたアクティベーションを確認して更新します。
3. Save project を選択します。

手順

1. プロジェクトを削除するには、次のいずれかを実行します。

   • Projects リストビューで、目的のプロジェクトの横にあるチェックボックスをオンにし、ページメニューから More Actions アイコン ⋮ をクリックします。
   • Projects リストビューで、目的のプロジェクトの横にある More Actions アイコン ⋮ をクリックします。
2. Delete project を選択します。
3. Permanently delete projects ウィンドウで、Yes, I confirm that I want to delete this project を選択します。
4. Delete project を選択します。

手順

1. 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

   Copy to Clipboard Toggle word wrap

2. オプション：他の 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

   Copy to Clipboard Toggle word wrap

手順

1. Ansible Automation Platform にログインします。
2. Automation Decisions → Decision Environments に移動します。
3. Create decision environment をクリックします。

4. 以下を入力します。

   Name

   名前を入力します。

   Description

   このフィールドは任意です。

   Organization

   決定環境に関連付ける組織を選択します。

   Image

   これは、コンテナーレジストリー、イメージ名、およびバージョンタグを含む完全なイメージの場所です。

   Credential

   このフィールドは任意です。これは、決定環境イメージを使用するために必要な認証情報です。

5. Create decision environment を選択します。

手順

1. Ansible Automation Platform ダッシュボードにログインします。
2. ナビゲーションパネルから、Automation Decisions → Infrastructure → Credentials を選択します。
3. Create credential をクリックします。

4. 以下を入力します。

   Name

   名前を入力します。

   Description

   このフィールドは任意です。

   Organization

   リストをクリックして組織を選択するか、Default を選択します。

   Credential type

   リストをクリックして、Red Hat Ansible Automation Platform を選択します。

   注記

   認証情報タイプを選択すると、Type Details セクションと、選択した認証情報タイプに適用できるフィールドが表示されます。

   警告

   バックアップおよび復元操作を使用して Ansible Automation Platform インスタンスを別のクラスターまたは新しいホスト名セットに移行する予定がある場合は、Red Hat Ansible Automation Platform の認証情報が破損し、ルールブックのアクティベーションに失敗します。接続を復元するには、復元操作が完了した後、Automation Controller URL と関連する認証情報を手動で編集して更新する必要があります。

5. 必須の Red Hat Ansible Automation Platform フィールドに、Automation Controller URL を入力します。

   注記

   Event-Driven Ansible Controller 2.6 と Automation Controller 2.4 の場合は、https://<your_controller_host> などを使用してください。

   Ansible Automation Platform 2.6 の場合は、https://<your_gateway_host>/api/controller/ などを使用してください。

6. 有効な Username と Password または Oauth Token を入力します。
7. Create credential をクリックします。

手順

1. Ansible Automation Platform にログインします。
2. Automation Decisions → Rulebook Activations に移動します。
3. Create rulebook activation をクリックします。

4. 以下を入力します。

   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:

     1. Always: ルールブックアクティベーションが正常に終了したかどうかに関係なく、ルールブックアクティベーションを直ちに再開します。これは 5 回まで実行されます。
     2. Never: コンテナープロセスが終了したときに、ルールブックアクティベーションを再開しません。
     3. On failure: コンテナープロセスが失敗した場合にのみ、デフォルトで 60 秒後にルールブックアクティベーションを再開します。これは 5 回まで実行されます。

   Log level

   このフィールドでは、ログに記録するイベントの重大度とコンテンツのタイプを定義します。

   • Levels:

     1. Error: アクティベーションの History タブに表示されるエラーメッセージを含むログ。
     2. Info: 成功または失敗、トリガーされたアクション名と関連するアクションイベント、エラーなど、ルールブックアクティベーションに関する有用な情報を含むログ。
     3. 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 オプションをオンにします。

5. Create rulebook activation をクリックします。

手順

1. 行レベルのスイッチを選択して、選択したルールブックを有効または無効にします。
2. ウィンドウで、Yes, I confirm that I want to enable/disable these X rulebook activations を選択します。
3. Enable/Disable rulebook activation を選択します。

手順

1. Rulebook Activation enabled/disabled トグルの横にある More Actions アイコン ⋮ を選択します。
2. Restart rulebook activation を選択します。
3. ウィンドウで、Yes, I confirm that I want to restart these X rulebook activations を選択します。
4. Restart rulebook activations を選択します。

手順

1. Rulebook Activations ページで、編集するアクティベーションの横にある Rulebook Activation enabled ボタンをオフの位置に切り替えて、アクティベーションを無効にします。

   Disable rulebook activations というメッセージが表示され、アクティベーションを無効にするかどうかの確認を求められます。

2. Yes, I confirm that I want to disable these <1> rulebook activations チェックボックスをオンにし、Disable rulebook activations をクリックします。

3. ルールブックアクティベーションの横にある Edit アイコンをクリックします。Edit フォームに移動します。

   注記

   Edit 機能には別の方法でもアクセスできます。Rulebook Activations ページでルールブックアクティベーションをクリックし、Rulebook activation enabled ボタンをオフの位置に切り替えて、アクティベーションを無効にすることを確認してから、ページの右上にある Edit rulebook activation ボタンをクリックすると、Edit フォームにアクセスできます。

4. 必要なフィールドを編集します。

   注記

   アクティベーションをすぐに実行する場合は、Rulebook activation enabled ボタンをオンの位置に切り替えて、変更を保存してください。

5. Save rulebook activation をクリックします。

手順

1. Rulebook Activations ページで、複製するアクティベーションの行にある More Actions アイコン ⋮ をクリックします。More Actions リストには、次の 3 つのオプションが表示されます。

   • Restart rulebook activation
   • Duplicate rulebook activation
   • Delete rulebook activation

2. Duplicate rulebook activation を選択します。

   "<Name of rulebook activation 1> duplicated." というメッセージが表示されます。最初、新しく複製したアクティベーションは、無効な状態で Rulebook Activations ページに表示されます。その名前は、元のアクティベーション名の後ろに 24 時間形式のタイムスタンプが付いたものになります (例: <ルールブックアクティベーション 1 の名前> @ 18:43:27)。

   重要

   ルールブックを複製した後も、元のルールブックアクティベーションは引き続き実行されます。フィールド (Name フィールドを含む) を編集せずに複製したアクティベーションを有効にして、元のアクティベーションと区別しようとすると、ルールブックアクティベーションが元のアクティベーションから複製されたものであるため、有効化に失敗したり、ジョブの重複やその他の問題が発生する可能性があることを通知するメッセージが表示されます。

3. 複製したルールブックアクティベーションを実行する前に、次の手順を実行してフィールドを編集します。

   1. 複製したルールブックアクティベーションの横にある Edit アイコンをクリックします。Edit フォームに移動します。

   2. 必要なフィールドを編集します。

      注記

      新しく複製したアクティベーションに、元のアクティベーションと区別できる意味のある Name を必ず付けてください。

4. Enable rulebook activation ボタンをオンの位置に切り替えます。
5. すべての編集が完了したことを確認したら、Save rulebook activation をクリックします。

手順

1. Rulebook Activation enabled/disabled トグルの横にある More Actions アイコン ⋮ を選択します。
2. Delete rulebook activation を選択します。
3. ウィンドウで、Yes, I confirm that I want to delete these X rulebook activations を選択します。
4. Delete rulebook activations を選択します。

手順

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

   Copy to Clipboard Toggle word wrap

2. ルートを作成したら、ルート URL へのポスト を使用してテストします。

   注記

   ポートはルート (targetPort) で指定されているため、必要ありません。

   curl -H "Content-Type: application/json" -X POST
   test-sync-bug-dynatrace.apps.aap-dt.ocp4.testing.ansible.com -d
   '{}'

   Copy to Clipboard Toggle word wrap

手順

1. 次のコマンドを実行して、クラスター上の特定のサービスのポートを公開します。

   kubectl port-forward svc/<ACTIVATION_SVC_NAME> 5000:5000

   Copy to Clipboard Toggle word wrap

2. localhost:5000 に対して HTTP 要求を実行して、ルールブックをトリガーします。

   curl -H "Content-Type: application/json" -X POST test-sync-bug-dynatrace.apps.aap-dt.ocp4.testing.ansible.com -d '{}'

   Copy to Clipboard Toggle word wrap

手順

1. 他に実行中のアクティベーションがあるか、制限 (メモリーや CPU の制限など) に達していないかを確認します。

   1. 他のアクティベーションが実行中の場合は、可能であれば 1 つ以上のアクティベーションを終了します。
   2. そうでない場合は、デフォルトのワーカー、Redis、およびアクティベーションワーカーがすべて実行されていることを確認します。
   3. すべてのシステムが期待どおりに動作している場合は、ワーカー、スケジューラー、API、nginx コンテナーおよびサービス内の eda-server 内部ログをチェックして、問題を特定できるか確認します。これらのログは、コードが出力した例外、ネットワークの問題によるランタイムエラー、ルールブックコードのエラーなど、問題の原因を明らかにします。内部ログに解決につながる情報が含まれていない場合は、Red Hat サポートに問題を報告してください。

手順

1. Ansible Automation Platform にログインします。
2. ナビゲーションパネルから、Automation Decisions → Rulebook Activations を選択します。
3. Rulebook Activations ページで、再起動を繰り返すアクティベーションをリストから選択します。Details ページが表示されます。
4. 詳細は、History タブをクリックし、再起動を繰り返すルールブックアクティベーションを選択します。Details タブが表示され、出力情報が表示されます。

5. アクティベーションの Restart policy フィールドを確認します。

   ここでは、On failure (コンテナープロセスが失敗した場合にルールブックアクティベーションを再起動)、Always (成功または失敗にかかわらず常に再起動し、再起動は 5 回まで)、Never (コンテナープロセスが終了したら決して再起動しない) のいずれかを選択できます。

   1. ルールブックアクティベーションの再起動ポリシーが On failure に設定されていることを確認します。これは、何らかの問題が原因で失敗していることを示しています。
   2. ルールブックアクティベーションの YAML コードとインスタンスログでエラーを確認することで、問題を診断できる場合があります。
   3. 再起動ポリシーの値から解決策を判断できない場合は、ログレベル に関連する次の手順に進みます。

6. アクティベーションのログレベルを確認します。

   1. デフォルトのログレベルが Error の場合は、Rulebook Activation ページに戻り、ルールブックアクティベーションの設定 で説明されている手順を実行してアクティベーションを再作成します。
   2. Log level を Debug に変更します。
   3. アクティベーションを再度実行し、アクティベーションの詳細ページから History タブに移動します。
   4. History ページで、最近のアクティベーションの 1 つをクリックし、Output を表示します。

手順

1. ルールブックソースを確認する： ルールブック YAML で定義されたソースプラグインを確認します（例：ansible.eda.webhook、ansible.eda.kafka）。
2. イベント入力の確認：イベント駆動型 Ansible Controller に送信するイベントが、ルールブックで定義したソースプラグインと互換性があることを確認します。ルールブックが Kafka メッセージを想定している場合は、汎用 Webhook イベントを処理できません。
3. アクティベーションマッピングの確認： イベントストリームを使用している場合は、アクティベーションセットアップ中に正しいイベントストリームがルールブックにマッピングされていることを確認します。ここでの不一致により、アクティベーションがデータを受信しなくなります。

手順

1. Check rule conditions: ルールブック YAML を確認し、条件(when ステートメント)が正しく書き込まれ、受信イベントペイロードの構造と値と正確に一致していることを確認します。
2. インデントと構文：簡単なエラーにより、ルールエンジンが条件を評価できなくなるため、すべてのルールブック構文とインデントが正しいことを確認 します。
3. validate actions: 指定したアクションが認識され、正しく設定されたアクションであることを確認します（例：適切な引数を持つ run_job_template ）。

手順

1. 問題を解決するには、Red Hat Ansible Automation Platform の認証情報を設定し、正しい Automation Controller URL を取得していることを確認します。

   1. Red Hat Ansible Automation Platform の認証情報を設定していない場合は、Red Hat Ansible Automation Platform 認証情報の設定 の手順を実行します。この認証情報のホストが https://<your_gateway>/api/controller の URL 形式で設定されていることを確認します。
   2. このプロセスを完了したら、ルールブックアクティベーションを再度設定します。

手順

1. ナビゲーションパネルから Automation Decisions → Rule Audit を選択します。
2. 目的のルールを選択すると、Details タブが表示されます。

手順

1. ナビゲーションパネルから、Automation Decisions → Rule Audit を選択します。
2. 目的のルールを選択すると、Details タブが表示されます。アクションをトリガーしたすべてのイベントを表示するには、Events タブを選択します。選択すると、アクションをトリガーしたイベントが表示されます。
3. イベントを選択すると、Event log が Source type と Timestamp とともに表示されます。

手順

1. ナビゲーションパネルから Automation Decisions → Rule Audit を選択します。
2. 目的のルールを選択してから、Actions タブを選択します。

手順

1. Ansible Automation Platform ダッシュボードにログインします。
2. ナビゲーションパネルから、Automation Decisions → Infrastructure → Credentials を選択します。
3. Create credential をクリックします。

4. 以下を入力します。

   Name

   名前を入力します。

   Description

   このフィールドは任意です。

   Organization

   リストをクリックして組織を選択するか、Default を選択します。

   Credential type

   リストをクリックして認証情報タイプを選択します。

   注記

   認証情報タイプを選択すると、Type Details セクションと、選択した認証情報タイプに適用できるフィールドが表示されます。

   Type Details

   選択した認証情報タイプに応じて要求される情報を追加します。たとえば、GitHub Event Stream 認証情報タイプを選択した場合は、Event-Driven Ansible Controller とリモートサーバーの間に HMAC Secret (対称共有シークレット) を追加する必要があります。

5. Create credential をクリックします。

手順

1. Ansible Automation Platform にログインします。
2. ナビゲーションパネルから、Automation Decisions → Event Streams を選択します。
3. Create event stream をクリックします。

4. 以下を入力します。

   Name

   名前を入力します。

   Organization

   リストをクリックして組織を選択するか、Default を選択します。

   Event stream type

   目的のイベントストリームタイプを選択します。

   注記

   このリストには、リモートサーバーからの接続を認証するために使用できるデフォルトのイベントストリームタイプが少なくとも 10 種類表示されます。

   Credentials

   リストから認証情報を選択します。イベントストリーム用に作成した認証情報を選択することを推奨します。

   Headers

   イベントペイロードに含める HTTP ヘッダーキーをコンマで区切って入力します。

   重要

   自動化がイベントペイロードに存在する HTTP ヘッダーに依存している場合は、機密情報が意図しない公開を回避するために明示的に定義する必要があります。HTTP ヘッダーとその安全な設定方法については、HTTP ヘッダーおよび イベントストリームの HTTP ヘッダー を安全に設定 を参照してください。

   Forward events to rulebook activation

   このオプションは、ルールブックアクティベーションにイベントを転送する機能を有効または無効にするために使用します。

   注記

   イベントストリームのイベント転送は、接続を診断して受信データを評価する際に、テスト目的で無効にすることができます。Forward events to rulebook activation オプションを無効にすると、リモートシステムとイベントストリームの接続をテストし、ヘッダーとペイロードを分析し、必要に応じて認証情報の問題を診断できます。これにより、テスト中にイベントがルールブックアクティベーションに転送され、ルールや条件が誤ってトリガーされることがなくなります。企業によっては、機密情報やパスワードを定期的に変更するポリシーを設けている場合があります。このオプションは、イベントストリームの作成後、いつでも有効/無効にできます。

5. Create event stream をクリックします。

手順

1. GitHub リポジトリーにログインします。

2. Your profile name → Your repositories をクリックします。

   注記

   リポジトリーがない場合は、New をクリックして新しいリポジトリーを作成し、所有者を選択し、Repository name を追加して、Create repository をクリックします。

3. Settings (ツールバー) に移動します。
4. General ナビゲーションペインで、Webhooks を選択します。
5. Add webhook をクリックします。
6. Payload URL フィールドに、イベントストリームを作成したときに保存した URL を貼り付けます。
7. Content type リストで application/json を選択します。
8. Secret を入力します。
9. Add webhook をクリックします。

1. Ansible Automation Platform にログインします。
2. ナビゲーションパネルから、Automation Decisions → Event Streams を選択します。
3. 作成したイベントストリームを選択して接続を検証し、イベントストリームがルールブックアクティベーションにデータを送信することを確認します。

4. イベントが受信されたことを確認します。Events received の数が、イベントの詳細を含むヘッダーとともに表示されます。

   

   UI を下にスクロールすると、Webhook に関する詳細情報を含むペイロードのボディーも確認できます。

   イベントストリームの Header セクションと Body セクションが Details ページに表示されます。これらはイベントを送信するベンダーによって異なります。ヘッダーとボディーを使用してイベントペイロード内の属性を確認できます。この情報は、ルールブックに条件を記述する際に役立ちます。

5. Forward events to rulebook activation オプションを切り替えて、イベントをルールブックアクティベーションにプッシュできるようにします。

1. イベントストリームは、ルールブックソースの交換で 1 回だけ使用できます。ルールブックに複数のソースがある場合、各ソースを 1 回だけ置き換えることができます。
2. ソースマッピングは、現在のルールブックアクティベーションでのみ実行されます。同じルールブックを使用する他のアクティベーションがある場合は、そのアクティベーションに対してこのプロセスを繰り返す必要があります。
3. ソースマッピングは、ルールブックが変更されない場合に限り有効です。ソースマッピングプロセス中にルールブックが変更されると、ソースマッピングが失敗し、プロセスをやり直す必要があります。
4. ソースマッピングの作成後にルールブックが変更され、再起動 が発生すると、ルールブックアクティベーションが失敗します。

手順

1. Ansible Automation Platform にログインします。
2. ナビゲーションパネルから、Automation Decisions → Rulebook Activations を選択します。
3. Create rulebook activation をクリックします。

4. 以下を入力します。

   Name

   名前を入力します。

   Description

   このフィールドは任意です。

   Organization

   組織名を入力するか、リストから Default を選択します。

   Project

   プロジェクトはルールブックの論理的なコレクションです。このフィールドは任意です。

   注記

   このフィールドは任意ですが、プロジェクトを選択すると、ルールブックの選択肢のリストを絞り込むのに役立ちます。

   Rulebook

   選択したプロジェクトに応じてルールブックが表示されます。ルールブックを選択します。

   注記

   ルールブックを選択すると、Event streams フィールドが有効になります。歯車アイコンをクリックすると、イベントストリームマッピングのフォームが表示されます。

   Event streams

   イベントをルールブックアクティベーションに転送するように設定されている利用可能なイベントストリームがすべて表示されます。イベントストリームを作成していない場合、このフィールドは無効のままです。

   歯車アイコンをクリックすると、イベントストリームマッピングの UI が表示されます。

   

   以下のフィールドに入力します。

   Rulebook source

   ルールブックには、複数のルールセットにわたる複数のソースを含めることができます。複数のアクティベーションで、同じルールブックを複数のイベントストリームにマッピングできます。イベントストリームを管理する際、名前のないソースに、識別のために一時的な名前 (__SOURCE {n}) が割り当てられます。

   リストから __SOURCE_1 を選択します。

   Event stream

   リストからイベントストリーム名を選択します。

   Save をクリックします。

   イベントストリームは、ルールブック内の一致するソースを置き換えることができます。イベントストリームは、さまざまなイベントソースをルールブックアクティベーションに接続できるようにするサーバー側の 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:

     1. Always: ルールブックアクティベーションが正常に終了したかどうかに関係なく、ルールブックアクティベーションを直ちに再開します。これは 5 回まで実行されます。
     2. Never: コンテナープロセスが終了したときに、ルールブックアクティベーションを再開しません。
     3. On failure: コンテナープロセスが失敗した場合にのみ、デフォルトで 60 秒後にルールブックアクティベーションを再開します。これは 5 回まで実行されます。

   Log level

   このフィールドでは、ログに記録するイベントの重大度とコンテンツのタイプを定義します。

   • Levels:

     1. Error: アクティベーションの History タブに表示されるエラーメッセージを含むログ。
     2. Info: 成功または失敗、トリガーされたアクション名と関連するアクションイベント、エラーなど、ルールブックアクティベーションに関する有用な情報を含むログ。
     3. Debug: デバッグフェーズでのみ役立ち、運用時にはあまり有用でない可能性がある情報を含むログ。このログレベルでは、エラーデータとログレベルデータの両方が対象となります。

   Service name

   これは、アクティベーションによりポートが公開される場合に、Kubernetes が受信接続を設定するためのサービス名を定義します。このフィールドは任意です。

   Rulebook activation enabled?

   これを選択すると、ルールブックアクティベーションが自動的に有効になります。

   Variables

   ルールブックの変数は JSON または YAML 形式です。内容は、ansible-rulebook コマンドの --vars フラグによって渡されるファイルと同等です。

   Options

   ルール監査にイベントを表示しない場合は、Skip audit events オプションをオンにします。

5. Create rulebook activation をクリックします。

手順

1. GitHub Webhook / Manage webhook ページに戻ります。
2. Recent Deliveries タブをクリックします。
3. 省略記号 をクリックします。
4. Redeliver をクリックします。Redeliver payload? ウィンドウに送信に関するメッセージが表示されます。
5. Yes, redeliver this payload をクリックします。
6. Ansible Automation Platform に戻り、ルール監査を確認します。

手順

1. Ansible Automation Platform にログインします。
2. ナビゲーションパネルから、Automation Decisions → Rule Audit を選択します。

1. ルールブックアクティベーションの同時実行数
2. Event-Driven Ansible Controller が受信するイベントの数

手順

1. インストール 中 にルールブックアクティベーションのデフォルトのメモリー制限を変更するには、次の手順を実行します。

   1. セットアップインベントリーファイルに移動します。
   2. [all:vars] セクションに automationedacontroller_podman_mem_limit を追加します。たとえば、automationedacontroller_podman_mem_limit='400m' などです。
   3. セットアップを実行します。

2. インストール 後 にルールブックアクティベーションのデフォルトのメモリー制限を変更するには、次の手順を実行します。

   1. /etc/ansible-automation-platform/eda/settings.yaml にある環境ファイルに移動します。
   2. デフォルトのコンテナーのメモリー制限を変更します。たとえば、PODMAN_MEM_LIMIT = '300m' です。
   3. automation-eda-controller-service restart を使用して、Event-Driven Ansible Controller サービスを再起動します。