Automation Controller ユーザーガイド

Automation controller を使用すると、Playbook の実行をリアルタイムで監視し、各ホストがチェックインするときに確認できます。特定のタスクとホストの結果を確認し、詳細に調査できます。特定のプレイまたはホストを検索して、該当する結果だけを表示したり、修正が必要なエラーを特定したりできます。

Automation controller を使用すると、Web インターフェイスからお気に入りのプロジェクトにアクセスし、実行を再トリガーできます。Automation controller は入力変数を要求し、認証情報の入力を求め、ジョブを開始および監視し、結果とホスト履歴を表示します。

Automation controller を使用すると、次のことが可能になります。

Automation Controller は、編集されたオブジェクトや起動されたジョブなど、操作の履歴と操作の実行者を記録します。

ユーザーまたはチームにジョブテンプレートを使用するパーミッションを付与する場合は、ジョブテンプレートにパーミッションを直接割り当てることができます。認証情報は Automation controller の RBAC システム内の完全なオブジェクトであり、複数のユーザーまたはチームに割り当てて使用できます。

Automation Controller には 監査者 タイプが用意されています。システムレベルの監査者は、システム自動化のすべての側面を確認できますが、自動化を実行または変更する権限はありません。監査者は、REST API から自動化情報を収集するサービスアカウントに役立ちます。

Automation Controller には、ノードがオンデマンドで設定を要求できるようにする強力なオプションのプロビジョニングコールバック機能が組み込まれています。これはクラウドの自動スケーリングシナリオに最適なソリューションであり、次の機能が含まれています。

Automation Controller REST API は、システム管理アプリケーションにとって理想的な RESTful API であり、すべてのリソースが完全に検出可能でページ分割され、検索可能で、適切にモデル化されています。スタイル付きの API ブラウザーを使用すると http://<server name>/api/ にある API ルートから API を探索でき、すべてのリソースとの関係が表示されます。ユーザーインターフェイスで実行できることはすべて API で実行できます。

Ansible Automation Platform はシステムのバックアップと復元ができるため、必要に応じてインスタンスのバックアップとレプリケーションを簡単に行うことができます。

Ansible Galaxy requirements.yml ファイルをプロジェクトディレクトリーに追加することで、Automation Controller は Playbook に必要なロールを Galaxy、GitHub、またはローカルのソースコントロールから自動的に取得します。詳細は、Ansible Galaxy サポート を参照してください。

動的インベントリーのサポートは OpenStack で利用できます。これにより、OpenStack クラウドで実行されている任意の仮想マシンまたはイメージをターゲットにすることができます。

詳細は、Openstack を参照してください。

リモートコマンド実行を使用して、1 人のユーザーの追加、1 つのセキュリティー脆弱性の更新、障害が発生したサービスの再起動など、単純なタスクを実行します。単一の Ansible プレイとして記述できるタスクはすべて、インベントリー内のホストまたはホストのグループで実行できるため、システムを迅速かつ簡単に管理できます。RBAC エンジンと詳細な監査ログにより、どのユーザーが特定のタスクを完了したかがわかります。

ファクトキャッシュ機能を使用してファクトを収集できます。詳細は、ファクトキャッシュ を参照してください。

自動化のステータスを追跡します。

次の通知を設定できます。

次の通知ソースがサポートされています。

前述の通知タイプごとに通知メッセージをカスタマイズすることもできます。

Automation Controller は次の統合をサポートしています。

詳細は、Red Hat Satellite 6 を参照してください。

詳細は、Insights 修復のセットアップ を参照してください。

カスタムの Ansible 環境サポートでは、さまざまなチームやジョブに対して、各種 Ansible 環境を設定し、カスタムのパスを指定できるようになりました。

Automation Controller は以下をサポートしています。

LDAP および SAML のサポートにより、エンタープライズアカウント情報をより柔軟な方法で統合できます。

トークンベースの認証では、統合された OAuth 2 トークンのサポートを通じて、Automation controller を使用したサードパーティーのツールとサービスの認証が可能になります。

クラスターグループのランタイム管理により、スケーリングの設定操作が可能になります。

複雑なプロビジョニング、デプロイメント、およびオーケストレーションのワークフローをモデル化するには、Automation Controller 拡張ワークフローをいくつかの方法で使用できます。

詳細は、Automation controller のワークフロー を参照してください。

数千台のマシンで実行されているファクト収集または設定ジョブを取得して、Automation Controller クラスター全体に分散できるスライスに分割し、信頼性の向上、ジョブ完了の高速化、およびクラスターの使用率の向上を実現します。

たとえば、大きなスケールで 15,000 台のスイッチすべてのパラメーターを変更したり、数千ノードの RHEL 環境全体の情報を収集したりできます。

詳細は、ジョブのスライス を参照してください。

Automation Controller は、FIPS などの限定的なモードでデプロイメントおよび実行されます。

多くの大規模組織では、多くの組織間でインスタンスを共有しています。この機能を使用するとスーパーユーザーは、各組織に割り当て可能なライセンス付きのホストの上限を指定でき、ライセンス付きのホストすべてが 1 つの組織で使用されないようにします。Automation controller アルゴリズムでは、組織の上限および全組織の合計ホスト数の変更について考慮します。インベントリーの同期により組織がポリシーに準拠しなくなる場合、インベントリーの更新は失敗します。さらに、スーパーユーザーは、警告を付けてライセンスを余分に割り当てることができます。

アップストリームコレクションからの次のインベントリープラグインが使用されます。

シークレット管理システムを使用すると、Automation Controller で使用するために外部認証情報が保存され、提供されるため、外部認証情報を直接提供する必要はありません。

Automation Controller を実行するにはライセンスが必要です。まずは無料試用版ライセンスから始めることができます。

Automation Controller に含まれるコンポーネントのライセンス情報を表示するには、/usr/share/doc/automation-controller-<version>/README を参照してください。

ここで、<version> はインストールした Automation Controller のバージョンです。

特定のライセンスを表示するには、/usr/share/doc/automation-controller-<version>/*.txt を参照してください。

ここで、* は参照するライセンスファイル名です。

Automation Controller ライセンスでは、Red Hat Ansible Automation Platform サブスクリプション契約の一部として管理可能な管理対象ノードの数が定義されます。

通常のライセンスでは「ライセンス数: 500」と記載され、最大管理対象ノード数が 500 に設定されます。

管理対象ノードのライセンス要件に関する詳細は https://access.redhat.com/articles/3331481 を参照してください。

Red Hat Ansible Automation Platform は、年間サブスクリプション契約をベースに、さまざまなサポートレベルおよびマシン数で提供されます。

すべてのサブスクリプションレベルには、Automation Controller、Ansible、および同プラットフォームの他のコンポーネントの通常の更新とリリースが含まれます。

詳細は、Red Hat カスタマーポータル または http://www.ansible.com/contact-us/ 経由で Ansible までお問い合わせください。

すでに Red Hat 製品のサブスクリプションをお持ちの場合は、そのサブスクリプションを通じて Automation Controller サブスクリプションを取得できます。Red Hat Ansible Automation Platform および Red Hat Satellite のサブスクリプションをお持ちでない場合は、試用版サブスクリプションをリクエストできます。

サブスクリプションマニフェストをアップロードするには、まずサブスクリプションの割り当てを設定します。

正式な Ansible Automation Platform サブスクリプションを取得したら、Automation Controller を使用する前に、サブスクリプションを Automation Controller システムにインポートする必要があります。前提条件

"Error fetching licenses" というメッセージが表示された場合は、Satellite ユーザーに必要な適切なアクセス権があることを確認してください。サブスクリプションを適用するには、Automation Controller 管理者にこのアクセス権が必要です。

Satellite のユーザー名とパスワードは、既存のサブスクリプションについて Satellite API をクエリーするために使用されます。Automation Controller は、Satellite API からそれらのサブスクリプションに関するメタデータを受信し、フィルタリングして、適用できる有効なサブスクリプションを検出します。このサブスクリプションは、有効なサブスクリプションオプションとして UI に表示されます。

以下の Satellite ロールが、適切なアクセス権を付与します。

Automation Controller との統合には、最も制限が厳しい Custom ロールを使用します。詳細は、ユーザーとロールの管理に関する Satellite ドキュメント を参照してください。

Automation Controller ユーザーインターフェイスを使用してサブスクリプション情報を適用または更新できない場合は、Ansible Playbook でサブスクリプションマニフェストを手動でアップロードできます。

ansible.controller コレクション内のライセンスモジュールを使用します。

- name: Set the license using a file
  license:
  manifest: "/tmp/my_manifest.zip"

詳細は、Automation Controller ライセンスモジュール を参照してください。

Ansible Automation Platform をインストールする前に、有効な Ansible Automation Platform サブスクリプションを割り当てる 必要があります。

サブスクリプションには、次の 2 つのステータスがあります。

コンプライアンスは次のように計算されます。

managed > manifest_limit    =>  non-compliant
managed =< manifest_limit   =>  compliant

ここで、managed は、削除されていない一意のマネージドホストの数、manifest_limit はサブスクリプションマニフェスト内のマネージドホストの数に置き換えます。

表示されるその他の重要な情報は次のとおりです。

たとえば、ホスト 10 台分のサブスクリプションがあるとします。

Automation Controller は、コマンドラインインターフェイス (CLI) を通じて、ホストメトリクスデータとホストメトリクス概要の CSV 出力を生成する方法を提供します。API を介してホストを一括して論理削除することもできます。

awx-manage host_metric --csv

awx-manage host_metric --tarball

awx-manage host_metric --tarball --rows_per_file <n>

api/v2/host_metric <n> DELETE

Automation controller UI には、情報を表示するためのいくつかのオプションが用意されています。

5.1.1. ダッシュボードビュー

ナビゲーションメニューを使用して、次のタスクを実行します。

• さまざまなビューを表示する
• リソースに移動する
• ユーザーにアクセスを許可する
• UI で Automation Controller の機能を管理する

手順

• ナビゲーションパネルから Views を選択して、Views オプションを非表示または表示します。

• ダッシュボードには、現在の Job status の概要が表示されます。

  • ジョブのステータスは、期間またはジョブの種類でフィルタリングできます。

• Recent Jobs や Recent Templates の概要を表示することもできます。

Recent Jobs タブには、最近実行されたジョブ、そのステータス、および実行時間が表示されます。

Recent Templates タブには、最近使用したテンプレートの概要が表示されます。ナビゲーションパネルから Resources → Templates を選択して、この概要にアクセスすることもできます。

注記

ナビゲーションパネルの Views → Dashboard をクリックするか、Ansible Automation Platform のロゴをクリックすると、いつでもダッシュボードに戻ることができます。

Resources メニューでは、Automation controller の次のコンポーネントにアクセスできます。

Access メニューを使用すると、Automation controller リソースに対するパーミッションがあるユーザーを設定できます。

Administration メニューでは、Automation Controller の管理オプションにアクセスできます。ここから、以下を作成、表示、編集できます。

Settings メニューを使用して、グローバルおよびシステムレベルの設定を設定します。Settings メニューでは、Automation controller 設定にアクセスできます。

Settings ページでは、管理者は次の項目を設定できます。

これらの検索のヒントは、ホストの検索を前提にはしていません。このセクションの大部分は、ホストにも適用できますが、いくつか違いがあります。

以下は、検索に使用される構文の例です。

固有名の検索は、API 名に対して検索を行います。例: ユーザーインターフェイスの Management job は API の system_job と同じです。Organization:Default この例は、関連フィールドの検索を示していますが、組織に関連するフィールドは指定されていません。これは API でサポートされており、単純な文字列検索に似ていますが、組織に対して実行されます (icontains は名前と説明の両方に対する検索が含まれます)。

"related_search_fields": [
       "modified_by__search",
       "project__search",
       "project_update__search",
       "credentials__search",
       "unified_job_template__search",
       "created_by__search",
       "inventory__search",
       "labels__search",
       "schedule__search",
       "webhook_credential__search",
       "job_template__search",
       "job_events__search",
       "dependent_jobs__search",
       "launch_config__search",
       "unifiedjob_ptr__search",
       "notifications__search",
       "unified_job_node__search",
       "instance_group__search",
       "hosts__search",
       "job_host_summaries__search"

必要に応じて、各列の矢印を使用して昇順で並べ替えます。以下はスケジュールリストの例です。

矢印の方向は、列の並べ替え順序を示します。

組織が作成されると、Automation controller に組織の詳細が表示され、組織のアクセス環境と実行環境を管理できるようになります。

Details タブでは、組織の編集や削除を行うことができます。

以下はそのようなメッセージの例です。

このページを使用して、次のタスクを完了します。

ユーザーをクリックすると、そのユーザーの詳細が表示されます。そのユーザーに関連付けられたパーミッションを確認、付与、編集、削除できます。詳細は、ユーザー を参照してください。

Automation Controller で新しいユーザーを作成し、ロールを割り当てます。

自分自身としてログインし、ユーザープロファイルの詳細を表示すると、ユーザープロファイルからトークンを管理できます。

詳細は、ユーザートークンの追加 を参照してください。

ユーザーを削除するには、ユーザーパーミッションが必要です。ユーザーアカウントを削除すると、ユーザーの名前とメールが Automation Controller から完全に削除されます。

特定のユーザーを選択すると、Details ページが表示されます。Organizations タブを選択すると、そのユーザーがメンバーとなっている組織のリストが表示されます。

Users > Details ページからTeams タブを選択して、ユーザーが所属するチームの一覧を表示します。

チームを作成してそのチームにユーザーを割り当てるまで、そのユーザーに割り当てられたチームの詳細が表示されます。

Users > Details ページから Roles タブを選択して、このユーザーに割り当てられているユーザーのセットを表示します。ロールにより、プロジェクト、インベントリー、ジョブテンプレートおよびその他の要素の読み取り、変更、および管理が可能になります。

Tokens タブは、自分用に作成したユーザーに対してのみ表示されます。

ユーザーのトークンを追加する前に、トークンをアプリケーションに関連付ける場合は、アプリケーションを作成する ことを推奨します。

アプリケーションに関連付けずに Personal Access Token (PAT) を作成することもできます。

組織に必要な数のユーザーチームを作成できます。ユーザーと同様に、各チームに権限を割り当てることができます。チームには認証情報の所有権を割り当てることもできるため、同じ認証情報を同じユーザーに割り当てる手順が最小限に抑えられます。

Automation Controller は SSH を使用してリモートホストに接続します。鍵を Automation Controller から SSH に渡すには、鍵を復号化してから名前付きパイプに書き込む必要があります。Automation Controller はそのパイプを使用して鍵を SSH に送信します。そのため、鍵がディスクに書き込まれることはありません。パスワードが使用されている場合、Automation Controller はパスワードプロンプトに直接応答し、パスワードを復号化してからプロンプトに書き込むことでパスワードを処理します。

チームに追加された認証情報は、チームのすべてのメンバーが利用できるようになります。個々のユーザーに認証情報を追加することもできます。

初期設定の一環として、デモ認証情報と Ansible Galaxy の 2 つの認証情報を使用できます。Ansible Galaxy 認証情報は、テンプレートとして使用してください。この認証情報はコピーできますが、編集することはできません。必要に応じて認証情報を追加してください。

Automation Controller は次の種類の認証情報をサポートしています。

Centrify、CyberArk、HashiCorp Vault、Microsoft Azure Key Vault、および Thycotic に関連付けられている認証情報タイプは、認証情報プラグイン機能の一部であり、外部システムによるシークレット情報の検索を可能にするものです。

詳細は、シークレット管理システム を参照してください。

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SECURITY_TOKEN

vars:
  aws:
    access_key: '{{ lookup("env", "AWS_ACCESS_KEY_ID") }}'
    secret_key: '{{ lookup("env", "AWS_SECRET_ACCESS_KEY") }}'
    security_token: '{{ lookup("env", "AWS_SECURITY_TOKEN") }}'

GCE_EMAIL
GCE_PROJECT
GCE_CREDENTIALS_FILE_PATH

vars:
  gce:
    email: '{{ lookup("env", "GCE_EMAIL") }}'
    project: '{{ lookup("env", "GCE_PROJECT") }}'
    pem_file_path: '{{ lookup("env", "GCE_PEM_FILE_PATH") }}'

ManagedCredentialType(
    namespace='insights',
....
....
....

injectors={
        'extra_vars': {
            "scm_username": "{{username}}",
            "scm_password": "{{password}}",
        },
        'env': {
            'INSIGHTS_USER': '{{username}}',
            'INSIGHTS_PASSWORD': '{{password}}',
        },

vars:
  machine:
    username: '{{ ansible_user }}'
    password: '{{ ansible_password }}'

AZURE_CLIENT_ID
AZURE_SECRET
AZURE_SUBSCRIPTION_ID
AZURE_TENANT
AZURE_CLOUD_ENVIRONMENT

AZURE_AD_USER
AZURE_PASSWORD
AZURE_SUBSCRIPTION_ID

client_id
secret
subscription_id
tenant
azure_cloud_environment

ad_user
password
subscription_id

vars:
  azure:
    client_id: '{{ lookup("env", "AZURE_CLIENT_ID") }}'
    secret: '{{ lookup("env", "AZURE_SECRET") }}'
    tenant: '{{ lookup("env", "AZURE_TENANT") }}'
    subscription_id: '{{ lookup("env", "AZURE_SUBSCRIPTION_ID") }}'

ANSIBLE_NET_USERNAME
ANSIBLE_NET_PASSWORD

vars:
  network:
    username: '{{ lookup("env", "ANSIBLE_NET_USERNAME") }}'
    password: '{{ lookup("env", "ANSIBLE_NET_PASSWORD") }}'

ManagedCredentialType(
    namespace='controller',

....
....
....

injectors={
        'env': {
            'TOWER_HOST': '{{host}}',
            'TOWER_USERNAME': '{{username}}',
            'TOWER_PASSWORD': '{{password}}',
            'TOWER_VERIFY_SSL': '{{verify_ssl}}',
            'TOWER_OAUTH_TOKEN': '{{oauth_token}}',
            'CONTROLLER_HOST': '{{host}}',
            'CONTROLLER_USERNAME': '{{username}}',
            'CONTROLLER_PASSWORD': '{{password}}',
            'CONTROLLER_VERIFY_SSL': '{{verify_ssl}}',
            'CONTROLLER_OAUTH_TOKEN': '{{oauth_token}}',
        }

vars:
  controller:
    host: '{{ lookup("env", "CONTROLLER_HOST") }}'
    username: '{{ lookup("env", "CONTROLLER_USERNAME") }}'
    password: '{{ lookup("env", "CONTROLLER_PASSWORD") }}'

FOREMAN_INI_PATH

OVIRT_URL
OVIRT_USERNAME
OVIRT_PASSWORD

vars:
  ovirt:
    ovirt_url: '{{ lookup("env", "OVIRT_URL") }}'
    ovirt_username: '{{ lookup("env", "OVIRT_USERNAME") }}'
    ovirt_password: '{{ lookup("env", "OVIRT_PASSWORD") }}'

ManagedCredentialType(
    namespace='rhv',

....
....
....

injectors={
        # The duplication here is intentional; the ovirt4 inventory plugin
        # writes a .ini file for authentication, while the ansible modules for
        # ovirt4 use a separate authentication process that support
        # environment variables; by injecting both, we support both
        'file': {
            'template': '\n'.join(
                [
                    '[ovirt]',
                    'ovirt_url={{host}}',
                    'ovirt_username={{username}}',
                    'ovirt_password={{password}}',
                    '{% if ca_file %}ovirt_ca_file={{ca_file}}{% endif %}',
                ]
            )
        },
        'env': {'OVIRT_INI_PATH': '{{tower.filename}}', 'OVIRT_URL': '{{host}}', 'OVIRT_USERNAME': '{{username}}', 'OVIRT_PASSWORD': '{{password}}'},
    },
)

VMWARE_HOST
VMWARE_USER
VMWARE_PASSWORD
VMWARE_VALIDATE_CERTS

vars:
  vmware:
    host: '{{ lookup("env", "VMWARE_HOST") }}'
    username: '{{ lookup("env", "VMWARE_USER") }}'
    password: '{{ lookup("env", "VMWARE_PASSWORD") }}'

次の Playbook は、Playbook で Automation Controller 認証情報を使用する方法の例です。

- hosts: all

  vars:
    machine:
      username: '{{ ansible_user }}'
      password: '{{ ansible_password }}'
    controller:
      host: '{{ lookup("env", "CONTROLLER_HOST") }}'
      username: '{{ lookup("env", "CONTROLLER_USERNAME") }}'
      password: '{{ lookup("env", "CONTROLLER_PASSWORD") }}'
    network:
      username: '{{ lookup("env", "ANSIBLE_NET_USERNAME") }}'
      password: '{{ lookup("env", "ANSIBLE_NET_PASSWORD") }}'
    aws:
      access_key: '{{ lookup("env", "AWS_ACCESS_KEY_ID") }}'
      secret_key: '{{ lookup("env", "AWS_SECRET_ACCESS_KEY") }}'
      security_token: '{{ lookup("env", "AWS_SECURITY_TOKEN") }}'
    vmware:
      host: '{{ lookup("env", "VMWARE_HOST") }}'
      username: '{{ lookup("env", "VMWARE_USER") }}'
      password: '{{ lookup("env", "VMWARE_PASSWORD") }}'
    gce:
      email: '{{ lookup("env", "GCE_EMAIL") }}'
      project: '{{ lookup("env", "GCE_PROJECT") }}'
    azure:
      client_id: '{{ lookup("env", "AZURE_CLIENT_ID") }}'
      secret: '{{ lookup("env", "AZURE_SECRET") }}'
      tenant: '{{ lookup("env", "AZURE_TENANT") }}'
      subscription_id: '{{ lookup("env", "AZURE_SUBSCRIPTION_ID") }}'

  tasks:
    - debug:
        var: machine

    - debug:
        var: controller

    - debug:
        var: network

    - debug:
        var: aws

    - debug:
        var: vmware

    - debug:
        var: gce

    - shell: 'cat {{ gce.pem_file_path }}'
      delegate_to: localhost

    - debug:
        var: azure

'delegate_to' と任意の検索変数の使用

- command: somecommand
  environment:
    USERNAME: '{{ lookup("env", "USERNAME") }}'
    PASSWORD: '{{ lookup("env", "PASSWORD") }}'
  delegate_to: somehost

「マネージド」認証情報タイプである kind=galaxy は、プロジェクトの更新を実行するときに requirements.yml で定義されたコレクションを取得するためのコンテンツソースを表します。コンテンツソースの例としては、galaxy.ansible.com、console.redhat.com、オンプレミス Automation Hub などがあります。この新しい認証情報タイプは、Ansible ドキュメントの Configuring the ansible-galaxy client で説明されているように、プロジェクトの更新で ansible-galaxy collection install 実行時に環境変数を構築するために必要な URL と (オプションの) 認証の詳細を表します。この認証情報タイプには、Ansible Galaxy CLI に公開される設定オプション (サーバーごとなど) に直接マップするフィールドがあります。

API のエンドポイントは、組織レベルでのこれらの認証情報の順序付きリストを反映します。

/api/v2/organizations/N/galaxy_credentials/

Automation Controller のインストールで既存の Galaxy 指向の設定値が移行されると、アップグレード後の適切な認証情報が作成され、すべての組織にアタッチされます。最新バージョンにアップグレードすると、アップグレード前に存在していたすべての組織に、関連付けられた 1 つ以上の"Galaxy" 認証情報のリストが作成されます。

さらに、アップグレード後は、これらの設定は /api/v2/settings/jobs/ エンドポイントから表示 (または編集) できなくなります。

Automation Controller は、galaxy.ansible.com が組織のリストの最初の認証情報でない場合でも、パブリック Galaxy から直接ロールを取得し続けます。グローバルな Galaxy 設定は、ジョブレベルではなく、ユーザーインターフェイスの組織レベルで設定されます。

組織の Add および Edit ウィンドウに、kind=galaxy の認証情報用のオプションの Credential 検索フィールドがあります。

順序によりコンテンツの同期と検索の優先順位が設定されるため、これらの認証情報の順序を指定することが重要です。詳細は、組織の作成 を参照してください。

コレクションを使用してプロジェクトを設定する方法の詳細は、Automation Hub でのコレクションの使用 を参照してください。

バージョン 2 の API (api/v2/) がサポートされている場合、ジョブテンプレートと認証情報の一対多の関係を使用できます (マルチクラウドサポートを含む)。

v2 の API では、認証情報をフィルタリングできます。

curl "https://controller.example.org/api/v2/credentials/?credential_type__namespace=aws"

V2 Credential Type モデルでは、リレーションシップは以下のように定義されます。

Automation Controller は GNU Privacy Guard (GPG) を使用してコンテンツを検証します。

詳細は、GNU プライバシーハンドブック を参照してください。

ナビゲーションパネルから、Administration → Credential Types を選択します。カスタム認証情報タイプが作成されていない場合は、Credential Types を追加するように求められます。

認証情報タイプが作成されていると、このページには、既存および利用可能な認証情報タイプのリストが表示されます。

認証情報タイプに関する詳細情報を表示するには、認証情報の名前または編集アイコン をクリックします。

各認証情報タイプでは、該当する場合、Input Configuration フィールドと Injector Configuration フィールドに独自の固有の設定が表示されます。YAML 形式と JSON 形式の両方が設定フィールドでサポートされています。

新規の認証情報タイプを作成するには、以下を実行します。

サードパーティーシステムからシークレットを取得する場合、認証情報フィールドを外部システムにリンクすることになります。認証情報フィールドを外部システムに保存されている値にリンクするには、そのシステムに対応する外部認証情報を選択し、必要な値を検索するための メタデータ を指定します。メタデータ入力フィールドは、ソース認証情報の外部認証情報タイプ定義の一部です。

Automation Controller は、開発者、インテグレーター、システム管理者、パワーユーザー向けの認証情報プラグインインターフェイスを備えています。このインターフェイスから、新しい外部認証情報タイプを追加して、他のシークレット管理システムをサポートするように拡張できます。

Automation Controller で、サポート対象の各サードパーティーのシークレット管理システムを設定して使用するには、次の手順を実行します。

12.1.2. AWS Secrets Manager Lookup

このプラグインにより、Amazon Web Services を認証情報入力ソースとして使用し、Amazon Web Services Secrets Manager からシークレットを取得できるようになります。AWS Secrets Manager は、Microsoft Azure Key Vault と同様のサービスを提供しており、AWS コレクションでそのためのルックアッププラグインが提供されています。

Credential Type に AWS Secrets Manager Lookup を選択した場合は、ルックアップを設定するために次のメタデータを指定します。

• AWS Access Key (必須): AWS キー管理システムとの通信に使用するアクセスキーを入力します。
• AWS Secret Key (必須): AWS IAM コンソールで取得したシークレットを入力します。

以下は、設定された AWS Secret Manager 認証情報の例です。

ナビゲーションパネルから、Administration → Applications を選択します。Applications ページには、現在 Automation controller によって管理されているすべての利用可能なアプリケーションの検索可能なリストが表示され、名前 で並べ替えることができます。

アプリケーションが存在しない場合は、アプリケーションを追加するように求められます。

外部 Web アプリケーションを Automation controller と統合する場合、Web アプリケーションは、Web アプリケーションのユーザーに代わって OAuth2 トークンを作成する必要がある場合があります。次の理由で、認証コード付与タイプを使用してアプリケーションを作成することは、推奨されます。

Ansible コンテンツがデフォルトの環境ではなくカスタム仮想環境に依存している場合は、追加の手順を実行する必要があります。各ノードにパッケージをインストールし、ホストシステムにインストールされている他のソフトウェアと適切に連携させ、パッケージの同期を維持する必要があります。

このプロセスを簡素化するために、Ansible コントロールノード として機能するコンテナーイメージをビルドできます。これらのコンテナーイメージは自動化実行環境と呼ばれ、ansible-builder を使用して作成できます。Ansible-runner は上記のようなイメージを利用できるようになります。

---
version: 3
dependencies:
  galaxy: requirements.yml

---
collections:
  - name: awx.awx

ansible-builder build
...
STEP 7: COMMIT my-awx-ee
--> 09c930f5f6a
09c930f5f6ac329b7ddb321b144a029dbbfcc83bdfc77103968b7f6cdfc7bea2
Complete! The build context can be found at: context

実行環境をジョブテンプレートに追加すると、それらのテンプレートは実行環境の Templates タブにリストされます。

実行環境のイメージをビルドするには、定義ファイルを作成する必要があります。ファイルは YAML 形式です。

定義ファイルで Ansible Builder のバージョンを指定する必要があります。デフォルトのバージョンは 1 です。

次の定義ファイルは Ansible Builder バージョン 3 を使用しています。

version: 3
build_arg_defaults:
  ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: '--pre'
dependencies:
  galaxy: requirements.yml
  python:
    - six
    - psutil
  system: bindep.txt
images:
  base_image:
    name: registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel8:latest
additional_build_files:
    - src: files/ansible.cfg
      dest: configs
additional_build_steps:
  prepend_galaxy:
    - ADD _build/configs/ansible.cfg /home/runner/.ansible.cfg
  prepend_final: |
    RUN whoami
    RUN cat /etc/os-release
  append_final:
    - RUN echo This is a post-install command!
    - RUN ls -la /etc

定義ファイルで次の設定 YAML キーを使用します。

Ansible Builder 3.x 実行環境定義ファイルは、次の 7 つの最上位セクションを受け入れます。

ansible_core:
    package_pip: ansible-core
ansible_core:
    package_pip: ansible-core==2.14.3
ansible_core:
    package_pip: https://github.com/example_user/ansible/archive/refs/heads/ansible.tar.gz

ansible_runner:
    package_pip: ansible-runner
ansible_runner:
    package_pip: ansible-runner==2.3.2
ansible_runner:
    package_pip: https://github.com/example_user/ansible-runner/archive/refs/heads/ansible-runner.tar.gz

dependencies:
  python: requirements.txt
  system: bindep.txt
  galaxy: requirements.yml
  ansible_core:
      package_pip: ansible-core==2.14.2
  ansible_runner:
      package_pip: ansible-runner==2.3.1
  python_interpreter:
      package_system: "python310"
      python_path: "/usr/bin/python3.10"

dependencies:
  python:
    - pywinrm
  system:
    - iputils [platform:rpm]
  galaxy:
    collections:
      - name: community.windows
      - name: ansible.utils
        version: 2.10.1
  ansible_core:
      package_pip: ansible-core==2.14.2
  ansible_runner:
      package_pip: ansible-runner==2.3.1
  python_interpreter:
      package_system: "python310"
      python_path: "/usr/bin/python3.10"

ansible-builder introspect --sanitize ~/.ansible/collections/

options:
    container_init:
        package_pip: dumb-init>=1.2.5
        entrypoint: '["dumb-init"]'
        cmd: '["csh"]'
    package_manager_path: /usr/bin/microdnf
    relax_password_permissions: false
    skip_ansible_check: true
    workdir: /myworkdir
    user: bob

test/data/pytz の例では、定義に awx.awx コレクションが必要です。ルックアッププラグイン awx.awx.tower_schedule_rrule が動作するには、PyPI pytz と別のライブラリーが必要です。test/data/pytz/execution-environment.yml ファイルが ansible-builder build コマンドに指定されている場合、イメージ内にコレクションがインストールされ、コレクション内の requirements.txt ファイルが読み取られて、pytz がイメージにインストールされます。。

これらの変数をプライベートデータディレクトリー内の env/settings ファイル内に配置して、生成されたイメージを ansible-runner プロジェクト内で使用できます。

---
container_image: image-name
process_isolation_executable: podman # or docker
process_isolation: true

awx.awx コレクションは、デフォルトの AWX に含まれるコンテンツのサブセットです。

詳細は、awx-ee repository を参照してください。

Automation Controller では、プロジェクトと呼ばれる Playbook の論理コレクションを作成できます。

プロジェクトに割り当てられており、プロジェクト、インベントリー、ジョブテンプレート、およびその他の要素の読み取り、変更、および管理を行う機能を提供する権限のセット (ロールベースのアクセス制御) は、特権とも呼ばれます。

プロジェクトの権限にアクセスするには、Projects ページの Access タブを選択します。この画面には、現在このプロジェクトに対する権限を持っているユーザーのリストが表示されます。

このリストは、Username、First Name、または Last Name で並べ替えおよび検索できます。

Automation Controller は、プロジェクトの更新の最後に、<project-top-level-directory>/roles/requirements.yml にある roles ディレクトリー内の requirements.yml ファイルを検索します。

このファイルが見つかると、次のコマンドが自動的に実行されます。

ansible-galaxy role install -r roles/requirements.yml -p <project-specific cache location>/requirements_roles -vvv

このファイルを使用すると、Ansible Galaxy ロール、または独自のプロジェクトと組み合わせてチェックアウトできる他のリポジトリー内のロールを参照できるようになります。Ansible Galaxy アクセスの追加により、この結果を得るために git サブモジュールを作成する必要がなくなります。SCM プロジェクトがロールまたはコレクションとともにプライベートジョブ環境に取り込まれ、そこから実行されることを考慮すると、デフォルトで /tmp 内にプロジェクトに固有の <private job directory> が作成されます。ただし、Settings ウィンドウの Jobs Settings タブでお使いの環境をもとに、別の Job Execution Path を指定できます。

キャッシュディレクトリーは、グローバルプロジェクトフォルダー内のサブディレクトリーです。コンテンツはキャッシュの場所から <job private directory>/requirements_roles にコピーできます。

デフォルトでは、Automation controller には、SCM プロジェクトの roles/requirements.yml ファイルからロールを動的にダウンロードできるようにするシステム全体の設定があります。Settings メニューの Jobs settings 画面で、Enable Role Download トグルボタンを Off に切り替えることで、この設定をオフにできます。

プロジェクトの同期が実行されるたびに、Automation controller は、プロジェクトソースおよび Galaxy または Collections のロールがプロジェクトに対して古くなっているかどうかを判断します。プロジェクトを更新すると、更新に含まれるロールがダウンロードされます。

アップストリームのロールに加えられた変更をジョブで取得する必要がある場合は、プロジェクトを更新すると取得されます。ロールの変更は、新しいコミットが provision-role のソースコントロールにプッシュされたことを意味します。

この変更をジョブで有効にするために、Playbook リポジトリーに新しいコミットをプッシュする必要はありません。プロジェクトの更新は行う必要があります。更新すると、ロールがローカルキャッシュにダウンロードされます。

たとえば、ソースコントロールに 2 つの git リポジトリーがあるとします。1 つ目は playbooks で、Automation Controller のプロジェクトがこの URL を参照します。2 つ目は provision-role で、playbooks git リポジトリー内の roles/requirements.yml ファイルによって参照されます。

ジョブは、すべてのジョブの実行前に最新のロールをダウンロードします。パフォーマンス上の理由から、ロールとコレクションはローカルにキャッシュされます。各ジョブの実行前にアップストリームロールを再ダウンロードするには、プロジェクトの SCM Update Options で Update Revision on Launch を選択する必要があります。

更新は同期よりもはるかに前のプロセスで行われるため、これによりエラーと詳細がより速く、より論理的な場所で詳細が表示されます。

requirements.yml ファイルの構文の詳細と例については、Ansible ドキュメントの ロール要件セクション を参照してください。

特に公開する必要があるディレクトリーがある場合は、Settings 画面の Jobs セクションの Paths to Expose to Isolated Jobs で指定できます。設定ファイル内の次のエントリーを更新することもできます。

AWX_ISOLATION_SHOW_PATHS = ['/list/of/', '/paths']

設定ファイルに変更を加えた場合には、変更の保存後に automation-controller-service restart コマンドを使用してサービスを再起動するようにしてください。

UI では、Jobs settings ウィンドウでこれらの設定を設定できます。

Automation Controller は、ジョブ実行でプロジェクト固有の Ansible コレクション をサポートします。collections/requirements.yml で SCM のコレクション要件ファイルを指定すると、Automation Controller はジョブの実行前にプロジェクトを暗黙的に同期するときに、そのファイルにコレクションをインストールします。

Automation controller には、SCM プロジェクトの collections/requirements.yml ファイルからコレクションを動的にダウンロードできるようにするシステム全体の設定があります。Settings メニューの Jobs settings タブで、Enable Collections Download トグルボタンを Off に切り替えることで、この設定をオフにできます。

ロールとコレクションはパフォーマンス上の理由からローカルにキャッシュされるため、以下を確実に行うためには、プロジェクトの SCM 更新オプションで Update Revision on Launch を選択する必要があります。

Automation controller でのコンテンツの署名と検証に GPG キーを使用するには、CLI で次のコマンドを実行して GPG キーを追加します。

$ gpg --list-keys
$ gpg --export --armour <key fingerprint> > my_public_key.asc

ansible-sign ユーティリティーを使用して、ユーザーが署名し、プロジェクトが署名されているかどうかを確認するためのオプションを提供します。

プロジェクトの署名には、Ansible プロジェクトディレクトリーが関係します。プロジェクトのディレクトリー構造の詳細は、Ansible ドキュメントの Sample Ansible setup を参照してください。

次のサンプルプロジェクトは、Playbook ディレクトリーの下にインベントリーファイルと、小規模な playbook が 2 つ含まれる非常に単純な構造となっています。

$ cd sample-project/
$ tree -a .
.
├── inventory
└── playbooks
    └── get_uptime.yml
    └── hello.yml

    1 directory, 3 files

ansible-sign は、プロジェクトに含まれるセキュリティーで保護された全ファイルのチェックサム (SHA256) を取得して、チェックサムマニフェストファイルにコンパイルし、そのマニフェストファイルに署名することでコンテンツを改ざんから保護します。

コンテンツに署名するには、保護するファイルを ansible-sign に指示する MANIFEST.in ファイルをプロジェクトのルートディレクトリーに作成します。

内部的には、ansible-sign は、Python の distlib ライブラリーの distlib.manifest モジュールを使用するため、MANIFEST.in はこのライブラリーが指定する構文に従う必要があります。'MANIFEST.in` ファイルディレクティブの説明は、Python Packaging User Guide を参照してください。

サンプルプロジェクトには 2 つのディレクティブが含まれており、最終的に次の MANIFEST.in ファイルになります。

include inventory
recursive-include playbooks *.yml

このファイルを配置したら、チェックサムマニフェストファイルを生成し、署名します。これらの手順は両方とも、ansible-sign コマンドで 1 つで実行できます。

$ ansible-sign project gpg-sign .

実行が成功すると、次のような出力が表示されます。

[OK   ] GPG signing successful!
[NOTE ] Checksum manifest: ./.ansible-sign/sha256sum.txt
[NOTE ] GPG summary: signature created

これでプロジェクトは署名されました。

gpg-sign サブコマンドは project サブコマンドの下にあることに注意してください。

プロジェクトのコンテンツに署名する場合、すべてのコマンドは ansible-sign project で始まります。

すべての ansible-sign project コマンドは、プロジェクトのルートディレクトリー . を最後の引数として受け取ります。

ansible-sign は、デフォルトのキーリングを使用し、最初に検出された利用可能な秘密鍵を探して、プロジェクトに署名します。--fingerprint オプションを使用して特定の秘密鍵を指定したり、--gnupg-home オプションを使用して完全に独立した GPG ホームディレクトリーを指定したりすることもできます。

.ansible-sign ディレクトリーがプロジェクトディレクトリーに作成されたことに注意してください。このディレクトリーには、チェックサムマニフェストとそのマニフェストの分離された GPG 署名が含まれています。

$ tree -a .
.
├── .ansible-sign
│   ├── sha256sum.txt
│   └── sha256sum.txt.sig
├── inventory
├── MANIFEST.in
└── playbooks
    ├── get_uptime.yml
    └── hello.yml

署名された Ansible プロジェクトが変更されていないことを確認するには、ansible-sign を使用して、署名が有効かどうか、またファイルのチェックサムがチェックサムマニフェストに記載されている内容と一致しているかどうかを確認できます。ansible-sign project gpg-verify コマンドを使用すると、これらの条件の両方を自動的に検証できます。

$ ansible-sign project gpg-verify .
[OK   ] GPG signature verification succeeded.
[OK   ] Checksum validation succeeded.

何らかの理由で検証が失敗した場合は、原因のデバッグに役立つ情報が表示されます。使用したコマンドの ansible-sign の直後にグローバルの --debug フラグを渡すことで、追加の冗長性を有効にできます。

OpenShift や Jenkins など、信頼性の高い 継続的インテグレーション (CI) 環境では、署名プロセスを自動化できます。

たとえば、GPG 秘密鍵を選択した CI プラットフォームにシークレットとして保存して CI 環境の GnuPG にインポートできます。その後、通常の CI 環境内で署名ワークフローを実行できます。

GPG を使用してプロジェクトに署名する場合、環境変数 ANSIBLE_SIGN_GPG_PASSPHRASE を署名鍵のパスフレーズに設定できます。これは、CI パイプラインで注入してマスクしたり、保護したりできます。

シナリオに応じて、ansible-sign は、署名中と検証中の両方で異なる終了コードを返します。CI 環境は障害に基づいて異なる動作を行うことができるため、CI と自動化のコンテキストでも役立ちます。たとえば、一部のエラーについてはアラートを送信できますが、他のエラーについては通知せずに失敗します。

以下は、ansible-sign で使用されている現在の終了コードであり、安定しているとみなされます。

スマートインベントリーは、保存された検索によって定義されたホストのコレクションであり、標準インベントリーと同様に表示でき、ジョブの実行で簡単に使用できます。組織管理者は組織内のインベントリーに対する管理者パーミッションを持っており、スマートインベントリーを作成できます。

スマートインベントリーは、KIND=smart で識別されます。

検索で使用されているのと同じ方法を使用して、スマートインベントリーを定義できます。InventorySource はインベントリーに直接関連付けられます。

Inventory モデルには、デフォルトで空白にされる以下の新規フィールドがありますが、スマートインベントリーについては以下のように設定されます。

ホスト モデルには、ホストが関連付けられているすべてのスマートインベントリーのセットを識別する関連エンドポイント、smart_inventories があります。メンバーシップテーブルは、スマートインベントリーに対してジョブが実行されるたびに更新されます。

編集できなくてもインベントリーを表示できます。

通常のインベントリーの場合のように、スマートインベントリーホストエンドポイント (/inventories/N/hosts/) からホストを作成できません。スマートインベントリーの管理者には、名前、説明、変数などのフィールドを編集するパーミッションと、削除するパーミッションがありますが、スマートインベントリーに含まれるホスト (別のインベントリーでプライマリーメンバーシップを持つホスト) が左右されるため、host_filter を変更するパーミッションはありません。

host_filter は、スマートインベントリーの組織に含まれるインベントリーのホストにのみ適用されます。

host_filter を変更するには、インベントリーの組織の組織管理者である必要があります。組織管理者は、組織内のすべてのインベントリーに対する暗黙的な "admin" アクセス権を持っているため、組織管理者がまだ所有していないパーミッションが継承されるわけではありません。

スマートインベントリーの管理者は、他のユーザー (組織の管理者ではないユーザー) に、スマートインベントリーに対する「使用」や「アドホック」などのアクセス許可を付与できます。これらは、他の標準インベントリーと同様に、ロールで指定されたアクションを許可します。ただし、これはホスト (別のインベントリーに存在する) に特別なパーミッションを付与するものではありません。ホストへの直接読み取りパーミッションは割り当てられず、/#/hosts/ の下にある追加のホストを表示することも許可されませんが、スマートインベントリーホストリストの下にあるホストは表示できます。

状況によっては、以下のものを変更できます。

スマートインベントリーに関連付けられたホストは表示される際に明示されます。スマートインベントリーの結果に同じホスト名を持つ複数のホストが含まれる場合、一致するホストの 1 つのみがスマートインベントリーの一部として組み込まれ、ホスト ID 別に並べ替えられます。

/api/v2/hosts?host_filter=ansible_facts__ansible_processor_vcpus=8

/api/v2/hosts/?host_filter=name=localhost
/api/v2/hosts/?host_filter=ansible_facts__ansible_date_time__weekday_number="3"
/api/v2/hosts/?host_filter=ansible_facts__ansible_processor[]="GenuineIntel"
/api/v2/hosts/?host_filter=ansible_facts__ansible_lo__ipv6[]__scope="host"
/api/v2/hosts/?host_filter=ansible_facts__ansible_processor_vcpus=8
/api/v2/hosts/?host_filter=ansible_facts__ansible_env__PYTHONUNBUFFERED="true"
/api/v2/hosts/?host_filter=(name=localhost or name=database) and (groups__name=east or groups__name="west coast") and ansible_facts__an

groups.name:groupA

ansible_facts.ansible_fips:false

host_filter=name=my_host

host_filter=ansible_facts__packages__dnsmasq[]__version="2.66"

入力インベントリーのリストから新しいインベントリー (構築されたインベントリーと呼ばれる) を作成できます。

構築されたインベントリーには、入力インベントリー内のホストとグループのコピーが含まれており、ジョブが複数のインベントリーにわたるサーバーのグループを対象にできます。グループとホスト変数をインベントリーのコンテンツに追加したり、ホストをフィルタリングして構築されたインベントリーのサイズを制限したりできます。

構築型インベントリーは、ansible.builtin.constructed inventory モデルを使用します。

構築型インベントリーの重要なポイントは次のとおりです。

構築型インベントリーは、source_vars と limit を入力として受け取り、その input_inventories を、グループを備えた新しいインベントリーに変換します。グループ (既存または構築された) を limit フィールドで参照して、生成されるホストの数を減らすことができます。

次のホストプロパティーに基づいてグループを構築できます。

以下は、構築されたインベントリー詳細ビューの例です。

後続のセクションで説明する例は、入力インベントリーの構造別に整理されています。

[account_1234]
host1
host2 state=shutdown

[account_4321]
host3
host4 state=shutdown

[account_1234:vars]
account_alias=product_dev

[account_4321:vars]
account_alias=sustaining

source_vars:

plugin: constructed
strict: true
groups:
  shutdown_in_product_dev: state | default("running") == "shutdown" and account_alias == "product_dev"
compose:
  resolved_state: state | default("running")
  is_in_product_dev: account_alias == "product_dev"

limit: ``

all:
  children:
    groupA:
      vars:
        filter_var: filter_val
      children:
        groupB:
          hosts:
            host1: {}
    ungrouped:
      hosts:
        host2: {}

`source_vars`:

plugin: constructed

`limit`: `groupA`

source_vars:

plugin: constructed
strict: true
groups:
  filter_var_is_filter_val: filter_var | default("") == "filter_val"

limit: filter_var_is_filter_val

source_vars:

plugin: constructed
strict: true
groups:
  hosts_using_xterm: ansible_env.TERM == "xterm"

limit: hosts_using_xterm

source_vars:

plugin: constructed
strict: true
groups:
  intel_hosts: "GenuineIntel" in ansible_processor

limit: intel_hosts

インベントリーの更新では、動的に生成された YAML ファイルが使用され、それぞれのインベントリープラグインによって解析されます。Automation controllerv4.4 では、次のインベントリーソースのインベントリーソース source_vars を使用して、インベントリープラグイン設定を Automation controller に直接提供できます。

インベントリーソース用に新しく作成された設定には、デフォルトのプラグイン設定値が含まれています。新しく作成したインベントリーソースを従来のソースの出力と一致させるには、そのソースに特定の設定値のセットを適用する必要があります。下位互換性を確保するために、Automation controller はこれらの各ソースに「テンプレート」を使用して、強制的にインベントリープラグインの出力をレガシー形式にします。

ソースとそれぞれのテンプレートの詳細は、サポートされているインベントリープラグインテンプレート を参照してください。

最上位キーとして plugin: foo.bar.baz を含む source_vars は、実行時に InventorySource ソースに基づいて完全修飾インベントリープラグイン名に置き換えられます。たとえば、InventorySource に ec2 が選択されている場合、実行時にプラグインは amazon.aws.aws_ec2 に設定されます。

新しいインベントリーの追加には、次のコンポーネントが含まれます。

インベントリーを作成するには、次の手順を使用します。

新規インベントリーが保存された後に、パーミッション、グループ、ホスト、およびソースの設定や、完了したジョブの表示に進みます (インベントリーのタイプに応じて適用可能な場合)。

$ awx-manage export_custom_scripts --filename=my_scripts.tar

Dump of old custom inventory scripts at my_scripts.tar

$ mkdir my_scripts
$ tar -xf my_scripts.tar -C my_scripts

$ ls my_scripts
10inventory_script_rawhook _19 _30inventory_script_listenhospital _11inventory_script_upperorder _1inventory_script_commercialinternet45 _4inventory_script_whitestring _12inventory_script_eastplant _22inventory_script_pinexchange _5inventory_script_literaturepossession _13inventory_script_governmentculture _23inventory_script_brainluck _6inventory_script_opportunitytelephone _14inventory_script_bottomguess _25inventory_script_buyerleague _7inventory_script_letjury _15inventory_script_wallisland _26inventory_script_lifesport _8random_inventory_script
16inventory_script_wallisland _27inventory_script_exchangesomewhere _9random_inventory_script _17inventory_script_bidstory            _28inventory_script_boxchild _18p                                    _29__inventory_script_wearstress

$ ./my_scripts/11__inventory_script_upperorder {"group\ud801\udcb0\uc20e\u7b0e\ud81c\udfeb\ub12b\ub4d0\u9ac6\ud81e\udf07\u6ff9\uc17b": {"hosts":
["host_\ud821\udcad\u68b6\u7a51\u93b4\u69cf\uc3c2\ud81f\uddbe\ud820\udc92\u3143\u62c7",
"host_\u6057\u3985\u1f60\ufefb\u1b22\ubd2d\ua90c\ud81a\udc69\u1344\u9d15",
"host_\u78a0\ud820\udef3\u925e\u69da\ua549\ud80c\ude7e\ud81e\udc91\ud808\uddd1\u57d6\ud801\ude57",
"host_\ud83a\udc2d\ud7f7\ua18a\u779a\ud800\udf8b\u7903\ud820\udead\u4154\ud808\ude15\u9711",
"host_\u18a1\u9d6f\u08ac\u74c2\u54e2\u740e\u5f02\ud81d\uddee\ufbd6\u4506"], "vars": {"ansible_host": "127.0.0.1", "ansible_connection":
"local"}}}

$ ansible-inventory -i ./my_scripts/_11__inventory_script_upperorder --list --export

インベントリーがジョブの実行に使用されている場合、このジョブの詳細は、インベントリーの Completed Jobs タブで確認できます。各ジョブの詳細を表示するには、Expanded をクリックします。

アドホック とは、オーケストレーション言語 (/usr/bin/ansible-playbook) ではなく、/usr/bin/ansible を使用して Ansible でクイックコマンドを実行することを指します。アドホックコマンドの例としては、インフラストラクチャー内の 50 台のマシンを再起動することが考えられます。アドホックで可能なことは、Playbook に記述して実現できます。Playbook では、他の多くの操作を結合することもできます。

アドホックコマンドを実行するには、次の手順を使用します。