Event-Driven Ansible Controller ユーザーガイド

Red Hat Ansible Automation Platform 2.4

Event-Driven Ansible Controller を設定して使用し、自動化を強化および拡張する方法

Red Hat Customer Content Services

概要

このガイドは、Event-Driven Ansible Controller を設定して、新しいプロジェクト、意思決定環境、Ansible Automation Platform Controller に対して認証するためのトークン、およびルールブックアクティベーションを設定するのに役立ちます。

はじめに

Event-Driven Ansible Controller は、一貫性と復元力を実現しながら IT の速度と俊敏性を向上させることで、自動化を強化および拡張する新しい方法です。Red Hat によって開発されたこの機能は、シンプルさと柔軟性を考慮して設計されています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。

Red Hat ドキュメントへのフィードバック (英語のみ)

技術的な内容に関するフィードバックをお寄せいただきありがとうございます。皆様のご意見をお待ちしています。コメントの追加、Insights の提供、誤字の修正、および質問を行う必要がある場合は、ドキュメントで直接行うこともできます。

注記

Red Hat アカウントがあり、カスタマーポータルにログインしている必要があります。

カスタマーポータルからドキュメントのフィードバックを送信するには、以下の手順を実施します。

  1. Multi-page HTML 形式を選択します。
  2. ドキュメントの右上にある Feedback ボタンをクリックします。
  3. フィードバックを提供するテキストのセクションを強調表示します。
  4. 強調表示されたテキストの横にある Add Feedback ダイアログをクリックします。
  5. ページの右側のテキストボックスにフィードバックを入力し、Submit をクリックします。

フィードバックを送信すると、自動的に問題の追跡が作成されます。Submit をクリックすると表示されるリンクを開き、問題の監視を開始するか、さらにコメントを追加します。

第1章 Event-Driven Ansible Controller の概要

Event-Driven Ansible は、他のソフトウェアベンダーのモニタリングツールなどのイベントソースと連携する、拡張性が高く柔軟な自動化機能です。このようなツールは、IT ソリューションを監視してイベントを特定し、ルールブックに記述された変更や対応を自動的に実装して、そのイベントを処理します。

ユーザー設定は次の手順で行います。

第2章 プロジェクト

プロジェクトはルールブックの論理的なコレクションです。これは git リポジトリーである必要があり、http プロトコルのみがサポートされます。プロジェクトのルールブックは、プロジェクトのルートの /rulebooks フォルダー、または Ansible コレクション内の Event-Driven Ansible コンテンツ用に定義されたパス /extensions/eda/rulebooks に配置する必要があります。

2.1. 新しいプロジェクトの設定

前提条件

  • Event-Driven Ansible Controller ダッシュボードに Content Consumer としてログインしている。
  • 必要に応じて、認証情報が設定されている。詳細は、Automation Controller ドキュメントの Credentials セクションを参照してください。
  • Automation Controller が使用する、リポジトリーに含まれている Playbook と統合されたルールブックを含む既存のリポジトリーがある。

手順

  1. Event-Driven Ansible Controller ダッシュボードにログインします。
  2. ナビゲーションパネルから、ProjectsCreate project を選択します。
  3. 以下を入力します。

    Name
    プロジェクト名を入力します。
    Description
    このフィールドは任意です。
    SCM type
    Git のみ使用できます。
    SCM URL

    GitHub や GitLab などのリポジトリーの HTTPS プロトコルアドレス。

    注記

    プロジェクトの作成後に SCM URL を編集することはできません。

    Credential
    このフィールドは任意です。これは、SCM URL を利用するために必要なトークンです。
  4. Create Project を選択します。

プロジェクトが作成され、Projects 画面で管理できるようになります。

新しいプロジェクトを保存すると、プロジェクトの詳細ページが表示されます。詳細ページまたは Projects リストビューから、プロジェクトを編集または削除できます。

2.2. Projects リストビュー

Projects ページでは、作成したプロジェクトを ステータス および Git ハッシュ とともに確認できます。

注記

ソース管理でルールブックが変更された場合は、Projects リストビューでプロジェクトの横にある同期アイコンを選択することで、プロジェクトを再同期できます。Git ハッシュ の更新は、そのリポジトリー上の最新のコミットを表します。更新されたプロジェクトを使用する場合は、アクティベーションを再開または再作成する必要があります。

2.3. プロジェクトの編集

手順

  1. Projects リストビューで、目的のプロジェクトの横にある More Actions アイコン を選択します。
  2. Edit project を選択します。
  3. 必要な変更を入力し、Save project を選択します。
Edit project

2.4. プロジェクトの削除

手順

  1. Projects リストビューで、目的のプロジェクトの横にある More Actions アイコン を選択します。
  2. Delete project を選択します。
  3. ポップアップウィンドウで、Yes, I confirm to delete this project を選択します。
  4. Delete project を選択します。

第3章 意思決定環境

意思決定環境は、Ansible ルールブックを実行するためのコンテナーイメージです。意思決定環境は、自動化の依存関係を伝達するための共通言語を作成し、自動化環境をビルドおよび配布するための標準的な方法を提供します。デフォルトの意思決定環境は Ansible-Rulebook にあります。

独自の意思決定環境を作成するには、Ansible Automation Platform 内での Event-Driven Ansible のカスタム意思決定環境のビルド を参照してください。

3.1. 新しい意思決定環境の設定

次の手順では、Event-Driven Ansible Controller ダッシュボードに意思決定環境をインポートする方法を説明します。

前提条件

  • Event-Driven Ansible Controller ダッシュボードに Content Consumer としてログインしている。
  • 必要に応じて、認証情報が設定されている。詳細は、Automation Controller ドキュメントの Credentials セクションを参照してください。
  • 意思決定環境イメージをイメージリポジトリーにプッシュしたか、registry.redhat.io で提供されている de-supported イメージを使用することを選択した。

手順

  1. Event-Driven Ansible Controller ダッシュボードに移動します。
  2. ナビゲーションパネルから、Decision EnvironmentsCreate decision environment を選択します。
  3. 以下を入力します。

    Name
    名前を入力します。
    Description
    このフィールドは任意です。
    Image
    これは、コンテナーレジストリー、イメージ名、およびバージョンタグを含む完全なイメージの場所です。
    Credential
    このフィールドは任意です。これは、意思決定環境イメージを利用するために必要なトークンです。
  4. Create decision environment を選択します。

これで意思決定環境が作成され、Decision Environments 画面で管理できるようになります。

新しい意思決定環境を保存すると、意思決定環境の詳細ページが表示されます。詳細ページまたは Decision Environment リストビューから、意思決定環境を編集または削除できます。

3.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 定義ファイルの例です。

version: 3

images:
  base_image:
    name: 'registry.redhat.io/ansible-automation-platform-24/de-minimal-rhel8: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-24/de-minimal-rhel8: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

第4章 トークンの設定

Automation Controller には、Event-Driven Ansible ルールブックと連携するように設計された Playbook を含むリポジトリーをベースとしたプロジェクトが含まれている必要があります。Automation Controller には、そのプロジェクト内の Playbook に基づいて設定された対応するジョブテンプレートも必要です。

4.1. Ansible Automation Platform Controller に対して認証するためのトークンの設定

前提条件

  • Event-Driven Ansible Controller ダッシュボードに Content Consumer としてログインしている。
  • ユーザーを作成している。
  • Event-Driven Ansible Controller ダッシュボードにログインできるか、組織内のユーザーとして追加されている。

手順

  1. Event-Driven Ansible Controller ダッシュボードに移動します。
  2. 上部のナビゲーションパネルからプロファイルを選択します。
  3. User details に移動します。
  4. Controller TokensCreate controller token を選択します。
  5. 以下を入力します。

    Name
    名前を入力します。
    Description
    このフィールドは任意です。
    Token

    Automation Controller でトークンを作成します。トークンの作成に関する詳細は、Automation Controller ユーザーガイドの Users - Tokens のセクションを参照してください。

    注記

    トークンは write-scope である必要があります。

  6. Create controller token を選択します。

新しいトークンを保存すると、Controller Tokens タブが表示され、そこでトークンを削除できます。

第5章 ルールブックアクティベーション

ルールブックアクティベーションは、特定のルールブックを実行する意思決定環境によって定義されるバックグラウンドで実行されるプロセスです。

5.1. ルールブックアクティベーションの設定

前提条件

  • Event-Driven Ansible Controller ダッシュボードに Content Consumer としてログインしている。
  • プロジェクトを設定している。
  • 意思決定環境を設定している。
  • Automation Controller のトークンを設定している。

手順

  1. Event-Driven Ansible Controller ダッシュボードに移動します。
  2. ナビゲーションパネルから、Rulebook ActivationsCreate rulebook activation を選択します。
  3. 以下を入力します。

    Name
    名前を入力します。
    Description
    このフィールドは任意です。
    Project
    プロジェクトはルールブックの論理的なコレクションです。
    Rulebook
    選択したプロジェクトに応じてルールブックが表示されます。
    Decision environment
    意思決定環境は、Ansible ルールブックを実行するためのコンテナーイメージです。
    Restart policy

    これは、ルールブックを再起動する条件を決定するためのポリシーです。

    • Policies:

      1. Always: ルールブック終了時に再起動します。
      2. Never: 終了時にルールブックを再起動しません。
      3. On failure: 失敗した場合にのみ再起動します。
    Rulebook activation enabled?
    これを選択すると、ルールブックアクティベーションが自動的に有効になります。
    Variables
    ルールブックの変数は JSON/YAML 形式です。内容は、ansible-rulebook コマンドの --vars フラグによって渡されるファイルと同等です。
  4. Create rulebook activation を選択します。

ルールブックアクティベーションが作成され、Rulebook Activations 画面で管理できるようになります。

新しいルールブックアクティベーションを保存すると、ルールブックアクティベーションの詳細ページが表示されます。詳細ページまたは Rulebook Activations リストビューから、ルールブックアクティベーションを編集または削除できます。

5.2. ルールブックアクティベーションのリストビュー

Rulebook Activations ページでは、作成したルールブックアクティベーションを、アクティベーションステータス、ルールブックに 関連付けられたルールの数起動数、および 再起動数 とともに確認できます。

Activation StatusRunning の場合、ルールブックのアクティベーションがバックグラウンドで実行されており、ルールブックで宣言されたルールに従って必要なアクションが実行されていることを意味します。

Rulebook Activations リストビューからアクティベーションを選択すると、詳細を確認できます。

Rulebook activation][width=25px

実行されたすべてのアクティベーションについて、Details タブと History タブを表示して、実行結果に関する詳細情報を取得できます。

5.2.1. アクティベーションの出力の表示

アクティベーションの出力は History タブで確認できます。

手順

  1. History タブを選択して、すべてのアクティベーションインスタンスのリストにアクセスします。1 つのアクティベーションインスタンスは、1 回のアクティベーションの実行を表します。
  2. 対象のアクティベーションインスタンスを選択すると、その特定の実行によって生成された Output が表示されます。
ルールブックアクティベーションの履歴

アクションをトリガーした受信イベントを表示するには、Event-Driven Ansible コントローラーダッシュボードの Rule Audit セクションを使用できます。

5.3. ルールブックアクティベーションの有効化および無効化

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

5.4. ルールブックアクティベーションの再起動

注記

ルールブックアクティベーションが現在有効であり、作成時に再起動ポリシーが Always に設定されていた場合にのみ、ルールブックアクティベーションを再起動できます。

  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 を選択します。

5.5. ルールブックアクティベーションの削除

  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 を選択します。

5.6. Webhook ルールブックのアクティブ化

Openshift 環境では、ルールブックアクティベーションの Kubernetes サービスを公開するルートを作成することで、Webhook が特定のポートを介して activation-job-pod に到達できるようにすることが可能です。

前提条件

  • Event-Driven Ansible Controller ダッシュボードでルールブックアクティベーションを作成している。
注記

特定の 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

手順

  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
    spec:
      host: test-sync-bug-dynatrace.apps.aap-dt.ocp4.testing.ansible.com
      to:
        kind: Service
        name: activation-job-1
        weight: 100
      port:
        targetPort: 5000
      wildcardPolicy: None
  2. ルートを作成したら、ルート URL へのポスト を使用してテストします。

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

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

5.7. Kubernetes を使用したテスト

Kubernetes を使用すると、Ingress の作成やポートの公開を行うことができます。ただし、これは実稼働環境用のものではありません。

手順

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

    kubectl port-forward svc/<ACTIVATION_SVC_NAME> 5000:5000
  2. localhost:5000 に対して HTTP リクエストを実行して、ルールブックをトリガーします。

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

第6章 ルール監査

ルール監査では、ある時点においてアクティブ化されたすべてのルールによってトリガーされたルールを監査できます。

Rule Audit リストビューには、ルールブック内の条件と一致してアクションをトリガーしたイベントを受信した各タイミングのリストが表示されます。リストにはルールブック内のルールが表示され、各見出しに実行されたルール名が表示されます。

6.1. ルール監査の詳細の表示

Rule Audit リストビューから、特定のアクションをトリガーしたイベントを確認できます。

Rule Audit リストビュー

手順

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

ここから、作成日時、最後に起動した日時、および対応するルールブックアクティベーションを確認できます。

6.2. ルール監査イベントの表示

手順

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

6.3. ルール監査アクションの表示

手順

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

ここから、実行されたアクションを確認できます。一部のアクションは Automation Controller にリンクされています。そこで出力を確認できます。

法律上の通知

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.