Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

16.3. クラスター管理

<<<<<< HEAD awx-manage provision_instance コマンドおよび awx-manage deprovision_instance コマンドの詳細は、クラスタリング を参照してください。

このセクションでは、クラスターインスタンスをプロビジョニングおよびプロビジョニング解除して、Automation Controller クラスターを管理する方法を説明します。Automation Controller は、awx-manage コマンドラインツールを使用してクラスターインスタンスを管理します。

awx-manage provision_instance コマンドおよび awx-manage deprovision_instance コマンドの詳細は、Clustering.>>>>> 2fea2f7c (DITA によるコントローラーガイドの変更(#4778))を参照してください。

重要

Ansible サポートからの指示がない限り、他の awx-manage コマンドは実行しないようにしてください。

= 解析の収集

以下のコマンドを使用して、事前定義の時間枠 (デフォルトは 4 時間) 以外で、オンデマンドでアナリティクスを収集します。

$ awx-manage gather_analytics --ship

切断された環境を使用し、一定期間にわたって、自動化された一意のホストに関する使用情報を収集する場合は、次のコマンドを使用します。

awx-manage host_metric --since YYYY-MM-DD --json

--since パラメーターは任意です。

--json フラグは出力形式を指定するもので、指定は任意です。

= バックアップおよびリストア

Ansible Automation Platform セットアップ Playbook を使用して、システムをバックアップおよび復元できます。

詳細は、クラスター環境のバックアップおよび復元 セクションを参照してください。

注記

Ansible Automation Platform をバックアップする場合は、現在インストールされている Ansible Automation Platform のバージョンと同じバージョンのインストールプログラムを使用してください。

Ansible Automation Platform を復元する場合は、復元時に利用可能な最新のインストールプログラムを使用してください。たとえば、バージョン 2.6-1 から作成したバックアップを復元する場合は、復元時に利用可能な最新の 2.6-x インストールプログラムを使用してください。

バックアップおよび復元機能は、現在お使いの Ansible Automation Platform バージョンでサポートされている PostgreSQL バージョンでのみ機能します。詳細は、インストール計画 の システム要件 を参照してください。

Ansible Automation Platform の設定用 Playbook は、プラットフォームインストーラーの tar ファイルを展開したパスから setup.sh として呼び出します。インストール Playbook で使用されるものと同じインベントリーファイルを使用します。セットアップスクリプトでは、バックアップと復元用に以下の引数を指定できます。

  • -b: データベースのインストールではなくバックアップを実行します。
  • -r: データベースのインストールではなく復元を実行します。

root ユーザーとして、適切なパラメーターを指定して setup.sh を呼び出し、設定どおりに Ansible Automation Platform をバックアップまたは復元します。 

root@localhost:~# ./setup.sh -b
root@localhost:~# ./setup.sh -r
Copy to Clipboard Toggle word wrap

バックアップファイルは、setup.sh スクリプトと同じパスに作成されます。パスは、次の EXTRA_VARS を指定することで変更できます。 

root@localhost:~# ./setup.sh -e 'backup_dest=/path/to/backup_dir/' -b
Copy to Clipboard Toggle word wrap

次の例に示すように、EXTRA_VARS にデフォルト以外のパスを指定しない限り、デフォルトの復元パスが使用されます。 

root@localhost:~# ./setup.sh -e 'restore_backup_file=/path/to/nondefault/backup.tar.gz' -r
Copy to Clipboard Toggle word wrap

オプションで、セットアップスクリプトに引数として渡すことで、使用したインベントリーファイルをオーバーライドすることができます。 

setup.sh -i <inventory file>
Copy to Clipboard Toggle word wrap

= Playbook のバックアップおよび復元

Automation Controller には、インストールをバックアップおよび復元するための Playbook が含まれています。

setup.sh セットアップ Playbook に含まれる install.yml ファイルに加えて、backup.yml ファイルと restore.yml ファイルもあります。

これらの Playbook はバックアップと復元に役立ちます。

  • システム全体のバックアップでは、以下をバックアップします。

    • データベース
    • SECRET_KEY ファイル

  • システム毎のバックアップには以下が含まれます。

    • カスタム設定ファイル
    • 手動のプロジェクト
  • バックアップの復元では、バックアップされたファイルとデータが、新しくインストールして動作中の Automation Controller の 2 番目のインスタンスに復元されます。

システムを復元する場合、インストールプログラムは復元を開始する前にバックアップファイルが存在するかどうかを確認します。バックアップファイルがない場合には、復元に失敗します。

注記

Automation Controller ホストが SSH キー、ホストファイル内のユーザー変数またはパスワード変数で適切にセットアップされていること、そしてユーザーが sudo アクセス権を持っていることを確認してください。

= バックアップと復元に関する考慮事項

システムをバックアップおよび復元するときは、次の点を考慮してください。

ディスク領域
ディスク領域の要件を確認して、設定ファイル、キー、その他の関連ファイル、および Ansible Automation Platform インストールのデータベースをバックアップするのに十分な領域があることを確認します。
システム認証情報

ローカルデータベースまたはリモートデータベースを操作する場合は、必要なシステム認証情報があることを確認します。ローカルシステムでは、認証情報のセットアップ方法に応じて、root または sudo アクセスが必要になる場合があります。リモートシステムでは、バックアップまたは復元しようとしているリモートシステムへのアクセス権を取得するためには別の認証情報が必要になる場合があります。

注記

Ansible Automation Platform データベースのバックアップは、変数 backup_dir を使用して各ノードの /var/backups/automation-platform に一時的に保存されます。場合によっては、ディスク領域の問題を防ぐために、./setup.sh -b スクリプトを実行する前に、新しいボリュームを /var/backups にマウントするか、変数 backup_dir を使用して一時保存場所を変更する必要があります。

バージョン
Ansible Automation Platform インストールバージョンをバックアップまたは復元する際は、常にリリースの最新のマイナーバージョンを使用する必要があります。たとえば、現行のプラットフォームバージョンが 2.0.x の場合は、最新の 2.0 インストーラーのみを使用します。
ファイルパス
setup.sh を使用してデフォルトの復元ファイルパス /var/lib/awx から復元する場合、復元を実行するには依然として -r が必要ですが、このオプションは引数を受け入れなくなりました。デフォルト以外の復元ファイルパスが必要な場合は、extra_var (root@localhost:~# ./setup.sh -e 'restore_backup_file=/path/to/nondefault/backup.tar.gz' -r) として指定する必要があります。
ディレクトリー
バックアップファイルが setup.sh インストーラーと同じディレクトリーに配置されている場合、復元 Playbook は復元ファイルを自動的に見つけます。この場合、バックアップファイルの場所を指定するために、restore_backup_file 追加変数を使用する必要はありません。

クラスター化された環境のバックアップと復元

クラスター環境のバックアップと復元の手順は、次のいくつかの留意事項を除き、単一インストールと同様です。

注記

クラスター環境のインストールの詳細は、インストールと設定 セクションを参照してください。

  • 新規クラスターに復元する場合は、データベースにアクセスする際にはクラスター間で競合状態になる可能性があるので、以前のクラスターをシャットダウンしてから続行するようにしてください。
  • ノードごとのバックアップは、バックアップと同じホスト名のノードにのみ復元されます。

  • 既存のクラスターに復元する場合、復元には次の処理が含まれます。

    • PostgreSQL データベースのダンプ
    • データベースダンプに含まれる UI アーティファクト
    • Automation Controller 設定 (/etc/tower から取得)
    • Automation Controller シークレットキー
    • 手動のプロジェクト

= 別のクラスターへの復元

バックアップを別のインスタンスまたはクラスターに復元する場合、/etc/tower 配下の手動プロジェクトとカスタム設定は保持されます。ジョブ出力とジョブイベントはデータベースに保存されるため、影響を受けません。

復元プロセスでは、復元前に存在していたインスタンスグループは変更されません。新しいインスタンスグループが導入されることもありません。インスタンスグループに関連付けられた Automation Controller リソースを復元した場合、新しい Automation Controller クラスターのインスタンスグループに当該リソースを再度割り当てることが必要な可能性があります。

= 使いやすさアナリティクスおよびデータ収集

Automation Controller にはユーザビリティーデータ収集が含まれており、ユーザーがどのように Automation Controller と対話するかをよりよく理解するためのデータを収集します。

試用版をインストールしたユーザーまたは新規にインストールしたユーザーのみが、このデータ収集にオプトインされます。

Automation Controller は、製品の改善に役立てるためにユーザーデータを自動的に収集します。

Automation Analytics の設定方法は、Automation Analytics の設定 を参照してください。

= Automation Analytics

ライセンスの初回インポート時に、Automation Analytics (Ansible Automation Platform サブスクリプションに含まれるクラウドサービス) を強化するデータの収集が自動的にオプトインされます。

重要

Automation Analytics のオプトインを有効にするには、Automation Controller のインスタンスが Red Hat Enterprise Linux 上で実行されている必要があります。

Red Hat Lightspeed と同様に、自動化アナリティクスは、必要最小限の量のデータを収集するように構築されています。認証情報のシークレット、個人データ、自動化変数、またはタスク出力は収集されません。

ライセンスを初めてインポートしたときに、Automation Analytics に自動的にオプトインされます。この機能を設定または無効にするには、Automation Analytics の設定 を参照してください。

デフォルトでは、データは 4 時間ごとに収集されます。この機能を有効にすると、最大 1 カ月 (または前回の収集まで) 遡ってデータが収集されます。このデータ収集は、システム設定ウィンドウの Miscellaneous System settings でいつでもオフにできます。

この設定は、次のエンドポイントのいずれかで INSIGHTS_TRACKING_STATE = true を指定し、API 経由で有効にすることもできます。

  • api/v2/settings/all
  • api/v2/settings/system

このデータ収集から生成された Automation Analytics は、Red Hat Cloud Services ポータルで確認できます。

デフォルトのビューは Clusters データです。このグラフは、一定期間における Automation Controller クラスター全体のジョブ実行数を表します。上記の例では、1 週間分の積み上げ棒グラフが表示されています。グラフは、正常に実行されたジョブの数 (緑色) と失敗したジョブの数 (赤色) で構成されています。

クラスターを 1 つ選択して、そのジョブステータス情報を表示することもできます。

Job run status

この複数の折れ線グラフは、指定した期間における単一の Automation Controller クラスターのジョブ実行数を表します。上記の例では 1 週間分が示されており、正常に実行されたジョブの数 (緑色) と失敗したジョブの数 (赤色) で構成されています。選択したクラスターの成功したジョブ実行数と失敗したジョブ実行数を、1 週間単位、2 週間単位、および月次単位で表示するように指定できます。

クラウドナビゲーションパネルで Organization Statistics を選択し、次の情報を表示します。

注記

組織の統計情報ページは、今後のリリースで非推奨になる予定です。

= 組織による使用

次のグラフは、特定の組織がすべてのジョブ内で実行したタスクの数を表します。

Tasks by organization

= 組織によるジョブ実行

このグラフは、組織ごとのすべての Automation Controller クラスターでの Automation Controller の使用状況を表します。これは、組織が実行したジョブの数に基づいて計算されます。

Jobs by organization

= 組織ステータス

この棒グラフは、組織および日付別の Automation Controller の使用状況を表します。これは、組織が特定の日に実行したジョブの数に基づいて計算されます。

あるいは、組織ごとのジョブ実行数を 1 週間単位、2 週間単位、および月次単位で表示するように指定することもできます。

Organization status

= データ収集の詳細

Automation Analytics は、Automation Controller から次の種類のデータを収集します。

  • 有効になっている機能や使用されているオペレーティングシステムなどの基本設定
  • 容量と健全性など、Automation Controller 環境とホストのトポロジーおよびステータス

  • 自動化リソースの数:

    • 組織、チーム、ユーザー
    • インベントリーとホスト
    • 認証情報 (タイプで索引付け)
    • プロジェクト (タイプで索引付け)
    • テンプレート
    • スケジュール
    • アクティブセッション
    • 実行中および保留中のジョブ
  • ジョブ実行の詳細 (開始時間、終了時間、起動タイプ、成功)
  • 自動化タスクの詳細 (成功、ホスト ID、Playbook/ロール、タスク名、使用モジュール)

awx-manage gather_analytics (--ship なし) を使用して Automation Controller が送信するデータを検査できるため、データ収集に関する懸念に対応できます。これにより、Red Hat に送信される分析データを含む tar ファイルが作成されます。

このファイルには、複数の JSON ファイルと CSV ファイルが含まれています。各ファイルには、異なる分析データのセットが含まれています。

= manifest.json

manifest.json は、分析データのマニフェストです。これは、コレクションに含まれる各ファイルと、ファイルのスキーマのバージョンを記述しています。

以下は、manifest.json ファイルの例です。 

  "config.json": "1.1",
  "counts.json": "1.0",
  "cred_type_counts.json": "1.0",
  "events_table.csv": "1.1",
  "instance_info.json": "1.0",
  "inventory_counts.json": "1.2",
  "job_counts.json": "1.0",
  "job_instance_counts.json": "1.0",
  "org_counts.json": "1.0",
  "projects_by_scm_type.json": "1.0",
  "query_info.json": "1.0",
  "unified_job_template_table.csv": "1.0",
  "unified_jobs_table.csv": "1.0",
  "workflow_job_node_table.csv": "1.0",
  "workflow_job_template_node_table.csv": "1.0"
}
Copy to Clipboard Toggle word wrap

= config.json

config.json ファイルには、クラスターの設定エンドポイント /api/v2/config のサブセットが含まれています。config.json の例は次のとおりです。 

{
    "ansible_version": "2.9.1",
    "authentication_backends": [
        "social_core.backends.azuread.AzureADOAuth2",
        "django.contrib.auth.backends.ModelBackend"
    ],
    "external_logger_enabled": true,
    "external_logger_type": "splunk",
    "free_instances": 1234,
    "install_uuid": "d3d497f7-9d07-43ab-b8de-9d5cc9752b7c",
    "instance_uuid": "bed08c6b-19cc-4a49-bc9e-82c33936e91b",
    "license_expiry": 34937373,
    "license_type": "enterprise",
    "logging_aggregators": [
        "awx",
        "activity_stream",
        "job_events",
        "system_tracking"
    ],
    "pendo_tracking": "detailed",
    "platform": {
        "dist": [
            "redhat",
            "7.4",
            "Maipo"
        ],
        "release": "3.10.0-693.el7.x86_64",
        "system": "Linux",
        "type": "traditional"
    },
    "total_licensed_instances": 2500,
    "controller_url_base": "https://ansible.rhdemo.io",
    "controller_version": "3.6.3"
}
Copy to Clipboard Toggle word wrap

これには次のフィールドが含まれます。

  • ansible_version: ホスト上のシステム Ansible バージョン
  • authentication_backends: 使用可能なユーザー認証バックエンド。詳細は、認証タイプの設定 を参照してください。
  • external_logger_enabled: 外部ロギングが有効かどうか
  • external_logger_type: 有効になっている場合に使用されているロギングバックエンド。詳細は、ロギングおよびアグリゲーション を参照してください。
  • logging_aggregators: 外部ロギングに送信されるロギングカテゴリー。詳細は、ロギングおよびアグリゲーション を参照してください。
  • free_instances: ライセンスで使用できるホストの数。値がゼロの場合は、クラスターがライセンスを完全に消費していることを意味します。
  • install_uuid: インストールの UUID (すべてのクラスターノードで同一)
  • instance_uuid: インスタンスの UUID (クラスターノードごとに異なる)
  • license_expiry: ライセンスの有効期限が切れるまでの時間 (秒単位)
  • license_type: ライセンスのタイプ (ほとんどの場合は 'enterprise')
  • pendo_tracking: usability_data_collection の状態
  • platform: クラスターが実行されているオペレーティングシステム
  • total_licensed_instances: ライセンス内のホストの合計数
  • controller_url_base: クライアントが使用するクラスターのベース URL (Automation Analytics に表示)
  • controller_version: クラスター上のソフトウェアのバージョン

= instance_info.json

Automation Controller は、クラスター内の各インスタンスに関する詳細情報を提供する instance_info.json ファイルを生成します。このファイルは通常、コントローラーノードの /var/lib/<controller_service_name>/instance_info.json パスにあります。

instance_info.json ファイルには、クラスターを構成するインスタンスに関する詳細情報がインスタンスの UUID ごとにまとめられています。

以下は、instance_info.json ファイルの例です。 

{
    "bed08c6b-19cc-4a49-bc9e-82c33936e91b": {
        "capacity": 57,
        "cpu": 2,
        "enabled": true,
        "last_isolated_check": "2019-08-15T14:48:58.553005+00:00",
        "managed_by_policy": true,
        "memory": 8201400320,
        "uuid": "bed08c6b-19cc-4a49-bc9e-82c33936e91b",
        "version": "3.6.3"
    }
    "c0a2a215-0e33-419a-92f5-e3a0f59bfaee": {
        "capacity": 57,
        "cpu": 2,
        "enabled": true,
        "last_isolated_check": "2019-08-15T14:48:58.553005+00:00",
        "managed_by_policy": true,
        "memory": 8201400320,
        "uuid": "c0a2a215-0e33-419a-92f5-e3a0f59bfaee",
        "version": "3.6.3"
    }
}
Copy to Clipboard Toggle word wrap

これには次のフィールドが含まれます。

  • capacity: タスクを実行するためのインスタンスの容量
  • cpu: インスタンスのプロセッサーコア
  • memory: インスタンスのメモリー
  • enabled: インスタンスが有効でタスクを受け付けているかどうか
  • managed_by_policy: インスタンスグループ内のインスタンスのメンバーシップがポリシーによって管理されているか、手動で管理されているか
  • version: インスタンス上のソフトウェアのバージョン

= counts.json

counts.json ファイルには、クラスター内の関連するカテゴリーごとの合計オブジェクト数が含まれています。

以下は、counts.json ファイルの例です。 

{
    "active_anonymous_sessions": 1,
    "active_host_count": 682,
    "active_sessions": 2,
    "active_user_sessions": 1,
    "credential": 38,
    "custom_inventory_script": 2,
    "custom_virtualenvs": 4,
    "host": 697,
    "inventories": {
        "normal": 20,
        "smart": 1
    },
    "inventory": 21,
    "job_template": 78,
    "notification_template": 5,
    "organization": 10,
    "pending_jobs": 0,
    "project": 20,
    "running_jobs": 0,
    "schedule": 16,
    "team": 5,
    "unified_job": 7073,
    "user": 28,
    "workflow_job_template": 15
}
Copy to Clipboard Toggle word wrap

このファイルの各エントリーは、アクティブセッション数を除いて、/api/v2 の対応する API オブジェクトに関するものです。

= org_counts.json

org_counts.json ファイルには、クラスター内の各組織に関する情報と、その組織に関連付けられているユーザーとチームの数が含まれています。

以下は、org_counts.json ファイルの例です。 

{
    "1": {
        "name": "Operations",
        "teams": 5,
        "users": 17
    },
    "2": {
        "name": "Development",
        "teams": 27,
        "users": 154
    },
    "3": {
        "name": "Networking",
        "teams": 3,
        "users": 28
    }
}
Copy to Clipboard Toggle word wrap

= cred_type_counts.json

Automation Controller は、クラスター内の認証情報タイプとそれらのカウントの概要を提供する cred_type_counts.json ファイルを生成します。このファイルは通常、コントローラーノードの /var/lib/<controller_service_name>/cred_type_counts.json パスにあります。

cred_type_counts.json ファイルには、クラスター内のさまざまな認証情報の種類と、各種類に存在する認証情報の数に関する情報が含まれています。

以下は、cred_type_counts.json ファイルの例です。 

{
    "1": {
        "credential_count": 15,
        "managed_by_controller": true,
        "name": "Machine"
    },
    "2": {
        "credential_count": 2,
        "managed_by_controller": true,
        "name": "Source Control"
    },
    "3": {
        "credential_count": 3,
        "managed_by_controller": true,
        "name": "Vault"
    },
    "4": {
        "credential_count": 0,
        "managed_by_controller": true,
        "name": "Network"
    },
    "5": {
        "credential_count": 6,
        "managed_by_controller": true,
        "name": "Amazon Web Services"
    },
    "6": {
        "credential_count": 0,
        "managed_by_controller": true,
        "name": "OpenStack"
    },
Copy to Clipboard Toggle word wrap

= inventory_counts.json

inventory_counts.json ファイルには、クラスター内のさまざまなインベントリーに関する情報が含まれています。

以下は、inventory_counts.json ファイルの例です。 

{
    "1": {
        "hosts": 211,
        "kind": "",
        "name": "AWS Inventory",
        "source_list": [
            {
                "name": "AWS",
                "num_hosts": 211,
                "source": "ec2"
            }
        ],
        "sources": 1
    },
    "2": {
        "hosts": 15,
        "kind": "",
        "name": "Manual inventory",
        "source_list": [],
        "sources": 0
    },
    "3": {
        "hosts": 25,
        "kind": "",
        "name": "SCM inventory - test repo",
        "source_list": [
            {
                "name": "Git source",
                "num_hosts": 25,
                "source": "scm"
            }
        ],
        "sources": 1
    }
    "4": {
        "num_hosts": 5,
        "kind": "smart",
        "name": "Filtered AWS inventory",
        "source_list": [],
        "sources": 0
    }
}
Copy to Clipboard Toggle word wrap

= projects_by_scm_type.json

projects_by_scm_type.json ファイルには、クラスター内の全プロジェクトの内訳がソースコントロールタイプ別に記載されています。

以下は、projects_by_scm_type.json ファイルの例です。 

{
    "git": 27,
    "hg": 0,
    "insights": 1,
    "manual": 0,
    "svn": 0
}
Copy to Clipboard Toggle word wrap

= query_info.json

query_info.json ファイルには、データ収集がいつどのように行われたかに関する詳細が記載されています。

以下は、query_info.json ファイルの例です。 

{
    "collection_type": "manual",
    "current_time": "2019-11-22 20:10:27.751267+00:00",
    "last_run": "2019-11-22 20:03:40.361225+00:00"
}
Copy to Clipboard Toggle word wrap

collection_type は、manual または automatic のいずれかです。

= job_counts.json

job_counts.json ファイルは、クラスターのジョブ履歴の詳細を提供し、ジョブの起動方法とジョブの終了ステータスの両方を記述します。

以下は、job_counts.json ファイルの例です。 

    "launch_type": {
        "dependency": 3628,
        "manual": 799,
        "relaunch": 6,
        "scheduled": 1286,
        "scm": 6,
        "workflow": 1348
    },
    "status": {
        "canceled": 7,
        "failed": 108,
        "successful": 6958
    },
    "total_jobs": 7073
}
Copy to Clipboard Toggle word wrap

= job_instance_counts.json

job_instance_counts.json ファイルは、job_counts.json と同じ詳細をインスタンスごとに分類して記載します。

以下は、job_instance_counts.json ファイルの例です。 

{
    "localhost": {
        "launch_type": {
            "dependency": 3628,
            "manual": 770,
            "relaunch": 3,
            "scheduled": 1009,
            "scm": 6,
            "workflow": 1336
        },
        "status": {
            "canceled": 2,
            "failed": 60,
            "successful": 6690
        }
    }
}
Copy to Clipboard Toggle word wrap

このファイルのインスタンスは、instance_info のように UUID ごとに記載されているのではなく、ホスト名ごとに記載されていることに注意してください。

= unified_job_template_table.csv

unified_job_template_table.csv ファイルは、システム内のジョブテンプレートに関する情報を提供します。各行には、ジョブテンプレートに関する次のフィールドが含まれます。

  • id: ジョブテンプレート ID。
  • name: ジョブテンプレート名。
  • polymorphic_ctype_id: テンプレートのタイプの ID。
  • model: テンプレートの polymorphic_ctype_id の名前。例として、project、systemjobtemplate、jobtemplate、inventorysource、workflowjobtemplate などがあります。
  • created: テンプレートが作成された日時。
  • updated: テンプレートが最後に更新された日時。
  • created_by_id: テンプレートを作成した userid。システムが作成した場合は空白です。
  • modified_by_id: テンプレートを最後に変更した userid。システムが作成した場合は空白です。
  • current_job_id: テンプレートの現在実行中のジョブ ID (該当する場合)。
  • last_job_id: ジョブの最後の実行。
  • last_job_run: ジョブが最後に実行された時刻。
  • last_job_failed: last_job_id が失敗したかどうか。
  • status: last_job_id のステータス。
  • next_job_run: テンプレートで次にスケジュールされている実行 (該当する場合)。
  • next_schedule_id: next_job_run のスケジュール ID (該当する場合)。

= unified_jobs_table.csv

unified_jobs_table.csv ファイルは、システムによって実行されるジョブに関する情報を提供します。

各行には、ジョブに関する次のフィールドが含まれます。

  • id: ジョブ ID。
  • name: ジョブ名 (テンプレートから)。
  • polymorphic_ctype_id: ジョブのタイプの ID。
  • model: ジョブの polymorphic_ctype_id の名前。例として、job や workflow などがあります。
  • organization_id: ジョブの組織 ID。
  • organization_name: organization_id の名前。
  • created: ジョブレコードが作成された日時。
  • started: ジョブの実行が開始した日時。
  • finished: ジョブが終了した日時。
  • elapsed: ジョブの経過時間 (秒単位)。
  • unified_job_template_id: このジョブのテンプレート。
  • launch_type: manual、scheduled、relaunched、scm、workflow、dependency のいずれか。
  • schedule_id: ジョブを起動したスケジュールの ID (該当する場合)
  • instance_group_id: ジョブを実行したインスタンスグループ。
  • execution_node: ジョブを実行したノード (UUID ではなくホスト名)。
  • controller_node: ジョブの Automation Controller ノード (分離ジョブとして実行される場合、またはコンテナーグループ内で実行される場合)。
  • cancel_flag: ジョブがキャンセルされたかどうか。
  • status: ジョブのステータス。
  • failed: ジョブが失敗したかどうか。
  • job_explanation: 適切に実行できなかったジョブの追加の詳細。
  • forks: ジョブに対して実行されたフォークの数。

= workflow_job_template_node_table.csv

workflow_job_template_node_table.csv は、システムのワークフロージョブテンプレートで定義されるノードの情報を提供します。

各行には、ワークフローのジョブテンプレートノードに以下のフィールドが含まれます。

  • id: ノード ID。
  • created: ノードが作成された日時。
  • modified: ノードが最後に更新された日時。
  • unified_job_template_id: このノードのジョブテンプレート、プロジェクト、インベントリー、またはその他の親リソースの ID。
  • workflow_job_template_id: このノードを含むワークフローのジョブテンプレート。
  • inventory_id: このノードによって使用されるインベントリー。
  • success_nodes: このノードが成功した後にトリガーされるノード。
  • failure_nodes: このノードが失敗した後にトリガーされるノード。
  • always_nodes: このノードの終了後に常にトリガーされるノード。
  • all_parents_must_converge: このノードを起動するためにすべての親条件が満たされる必要があるかどうか。

= workflow_job_node_table.csv

workflow_job_node_table.csv は、システム上のワークフローの一部として実行されたジョブに関する情報を提供します。

各行には、ワークフローの一部として実行されるジョブに次のフィールドが含まれています。

  • id: ノード ID。
  • created: ノードが作成された日時。
  • modified: ノードが最後に更新された日時。
  • job_id: このノードで実行されるジョブのジョブ ID。
  • unified_job_template_id: このノードのジョブテンプレート、プロジェクト、インベントリー、またはその他の親リソースの ID。
  • workflow_job_template_id: このノードを含むワークフローのジョブテンプレート。
  • inventory_id: このノードによって使用されるインベントリー。
  • success_nodes: このノードが成功した後にトリガーされるノード。
  • failure_nodes: このノードが失敗した後にトリガーされるノード。
  • always_nodes: このノードの終了後に常にトリガーされるノード。
  • do_not_run: 開始条件がトリガーされなかったためにワークフローで実行されなかったノード。
  • all_parents_must_converge: このノードを起動するためにすべての親条件が満たされる必要があるかどうか。

= events_table.csv

events_table.csv ファイルは、システム内のすべてのジョブ実行からのすべてのジョブイベントに関する情報を提供します。

各行には、ジョブイベントに関する次のフィールドが含まれます。

  • id: イベント ID。
  • uuid: イベント UUID。
  • created: イベントが作成された日時。
  • parent_uuid: このイベントの親 UUID (存在する場合)。
  • event: Ansible イベントタイプ。
  • task_action: このイベントに関連付けられたモジュール (存在する場合) (command や yum など)。
  • failed: イベントが failed を返したかどうか。
  • changed: イベントが changed を返したかどうか。
  • playbook: イベントに関連付けられた Playbook。
  • play: Playbook のプレイ名。
  • task: Playbook のタスク名。
  • role: Playbook のロール名。
  • job_id: このイベントが発生したジョブの ID。
  • host_id: このイベントが関連付けられているホストの ID (存在する場合)。
  • host_name: このイベントが関連付けられているホストの名前 (存在する場合)。
  • start: タスクの開始時刻。
  • end: タスクの終了時刻。
  • duration: タスクの期間。
  • warnings: タスクまたはモジュールからの警告。
  • deprecations: タスクまたはモジュールからの非推奨の警告。

= 解析レポート

収集されたデータのレポートを console.redhat.com から利用できます。

現在、プラットフォーム UI から利用およびアクセス可能なその他の Automation Analytics データには、次のものがあります。

Automation Calculator: Automation Calculator ユーティリティーの表示専用バージョンです。サブスクライバーの (可能な) 節約額を示すレポートを表示します。

Automation calculator

Host Metrics: ホストが最初に自動化された日時、ホストが最後に自動化された日時、ホストが自動化された回数、各ホストが削除された回数など、ホストのデータを収集した分析レポートです。

Subscription Usage: サブスクリプションの過去の使用状況をレポートします。サブスクリプション容量と月ごとの消費ライセンス数が表示されます。過去 1 年、2 年、または 3 年でフィルタリングできます。

= Automation Controller のトラブルシューティング

以下に、Automation Controller に関する有用なトラブルシューティング情報を示します。

= HTTP 経由で Automation Controller にログインできない

Automation Controller へのアクセスは、セキュアなプロトコル (HTTPS) を使用して意図的に制限されています。

Automation Controller ノードをロードバランサーやプロキシーの背後で「HTTP のみ」として実行するようにセットアップしており、SSL を使用せずに当該ノードにアクセスしたい場合 (トラブルシューティングのためなど)、Automation Controller インスタンスの /etc/tower/conf.d にある custom.py ファイルに次の設定を追加する必要があります。 

SESSION_COOKIE_SECURE = False
CSRF_COOKIE_SECURE = False
Copy to Clipboard Toggle word wrap

これらの設定を false に変更すると、HTTP プロトコルの使用時に Automation Controller がクッキーとログインセッションを管理できるようになります。この変更は、クラスターインストールのすべてのノードで行う必要があります。

変更を適用するには、以下を実行します。 

automation-controller-service restart
Copy to Clipboard Toggle word wrap

= ジョブを実行できない

Playbook からジョブを実行できない場合は、Playbook の YAML ファイルを確認します。手動またはソースコントロールメカニズムによって Playbook をインポートする場合、ホスト定義は Automation Controller によって制御され、hosts:all に設定する必要があることに注意してください。

= Playbook がジョブテンプレート一覧に表示されない

Playbook が ジョブテンプレート リストに表示されない場合は、次の点を確認してください。

  • Playbook が有効な YML で、Ansible で解析できることを確認してください。
  • プロジェクトパス (/var/lib/awx/projects) のパーミッションと所有権が、"awx" システムユーザーにファイルが表示されるようにセットアップされていることを確認してください。次のコマンドを実行して所有権を変更します。 
chown awx -R /var/lib/awx/projects/
Copy to Clipboard Toggle word wrap

= Playbook は保留中のままになります

Playbook のジョブを実行しようとした際に、ジョブが Pending のままになる場合、以下の操作を試行してください。

  • supervisorctl status を使用して、すべてのスーパーバイザーサービスが実行されていることを確認してください。
  • /var/ パーティションに 1 GB を超える空き領域があることを確認してください。/var/ パーティションの領域が不十分な場合、ジョブは完了しません。
  • Automation Controller サーバーで automation-controller-service restart を実行します。

問題が継続する場合には、Automation Controller サーバーで root として sosreport を実行し、その結果を添付した サポートリクエスト を提出してください。

= 外部データベースを再利用すると、インストールが失敗します

クラスターインストール用に外部データベースを再利用する場合は、後続のインストールを実行する前に手動でデータベースをクリアする必要があります。

2 回目以降のノードのインストール中に外部データベースを再利用すると、インストールが失敗してしまう件が報告されています。

例

クラスターインストールを実行したとします。もう一度インストールを行う必要があり、2 回目のクラスターインストールは同じ外部データベースを再利用して実行するとします。その場合、この 2 回目のインストールだけが失敗します。

以前のインストールで使用した外部データベースをセットアップする場合、追加のインストールを成功させるには、クラスターノードで使用するデータベースを手動で消去する必要があります。

= Automation Controller インベントリーでのプライベート EC2 VPC インスタンスの表示

デフォルトでは、Automation Controller は、Elastic IP (EIP) が関連付けられている VPC のインスタンスのみを表示します。

手順

  1. ナビゲーションパネルから Automation Execution Infrastructure Inventories を選択します。

  2. Source が Amazon EC2 に設定されているインベントリーを選択し、Source タブをクリックします。Source Variables フィールドに次のように入力します。 

    vpc_destination_variable: private_ip_address
    Copy to Clipboard Toggle word wrap
  3. Save をクリックして、グループの更新をトリガーします。

検証

これらの手順を完了すると、VPC インスタンスが表示されます。

注記

インスタンスを設定する場合には、Automation Controller が、インスタンスへのアクセス権がある VPC 内で実行されている必要があります。

= Automation Controller のヒントとコツ

= Automation Controller の CLI ツール

Automation Controller は、フル機能のコマンドラインインターフェイスを備えています。

設定および使用の詳細は、AWX コマンドラインインターフェイス および AWX 管理ユーティリティー の項を参照してください。

= Automation Controller の管理者パスワードの変更

インストールプロセス中に、Automation Controller によって作成された admin スーパーユーザーまたはシステム管理者用の管理者パスワードを入力するように求められます。SSH を使用してインスタンスにログインすると、プロンプトにデフォルトの管理者パスワードが表示されます。

このパスワードを変更する必要がある場合は、Automation Controller サーバーで root として次のコマンドを実行します。 

awx-manage changepassword admin
Copy to Clipboard Toggle word wrap

次に、新しいパスワードを入力します。その後は入力したパスワードが Web UI の管理者パスワードとして機能します。

Django を使用して作成時にパスワード検証のポリシーを設定するには、Django パスワードポリシー を参照してください。

= コマンドラインから Automation Controller 管理者を作成する

場合によっては、コマンドラインからシステム管理者 (スーパーユーザー) アカウントを作成すると便利な場合があります。

スーパーユーザーを作成するには、Automation Controller サーバーで root として次のコマンドを実行し、プロンプトに従って管理者の情報を入力します。 

awx-manage createsuperuser
Copy to Clipboard Toggle word wrap

= 管理対象ノードに接続しているジャンプホストを使用するように Automation Controller を設定

Automation Controller が提供する認証情報は、ProxyCommand によってジャンプホストに送信されることはありません。認証情報は、トンネル接続がセットアップされている場合に、エンドノードにのみ使用されます。

= SSH 設定ファイルで固定ユーザー/キーファイルを設定する

ジャンプホスト経由で接続を設定する ProxyCommand 定義の SSH 設定ファイルで、固定のユーザー/キーファイルを設定できます。

前提条件

  • 管理対象ノードへの SSH 接続を確立するノード (Hybrid Controller や実行ノードなど) からすべてのジャンプホストに到達できるかどうかを確認する。

手順

  1. 各ノードに、次の詳細を含む SSH 設定ファイル /var/lib/awx .ssh/config を作成します。 

    Host jumphost.example.com
    Hostname jumphost.example.com
    User <jumphostuser>
    Port <jumphostport>
    IdentityFile ~.ssh/id_rsa
    StrictHostKeyChecking no
    ProxyCommand ssh -W %h:%p jumphost.example.com
    Copy to Clipboard Toggle word wrap
    • このコードは、ジャンプホスト 'jumphost.example.com' に接続するために必要な設定を指定します。
    • Automation Controller は各ノードから管理対象ノードへの SSH 接続を確立します。
    • 例の値 jumphost.example.com、jumphostuser、jumphostport、~/.ssh/id_rsa は、環境に応じて変更する必要があります。

    • ノード上にすでに作成されている SSH 設定ファイル /var/lib/awx/.ssh/config` にホストマッチングブロックを追加します。次に例を示します。 

      Host 192.0.*
   ...
      Copy to Clipboard Toggle word wrap
      • Host 192.0.* 行は、該当するサブネット内のすべてのホストがそのブロックで定義された設定を使用することを指定します。具体的には、該当するサブネット内のすべてのホストは、ProxyCommand 設定を使用してアクセスされ、jumphost.example.com を介して接続されます。

      • すべてのホストが指定のプロキシーを介して接続することを示すために Host * を使用する場合は、必ず jumphost.example.com をそのマッチングの対象から除外してください。次に例を示します。 

        Host * !jumphost.example.com
    ...
        Copy to Clipboard Toggle word wrap

        Red Hat Ansible Automation Platform UI の使用

  2. ナビゲーションパネルで、Settings Automation Execution Job を選択します。
  3. Edit をクリックし、Paths to expose isolated jobs に /var/lib/awx .ssh:/home/runner/.ssh:0 を追加します。
  4. Save をクリックして変更を保存します。

= Ansible インベントリー変数を使用したジャンプホストの設定

インベントリー変数を使用して、Automation Controller インスタンスにジャンプホストを追加できます。

これらの変数は、インベントリー、グループ、またはホストレベルのいずれかで設定できます。インベントリーを使用して Automation Controller 内のジャンプホストの使用を制御する場合は、この方法を使用します。

手順

  • インベントリーに移動し、選択したレベルの variables フィールドに次の変数を追加します。 

    ansible_user: <user_name>
ansible_connection: ssh
ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q <user_name>@<jump_server_name>"'
    Copy to Clipboard Toggle word wrap

= 自動化コントローラーの使用時に JSON コマンドの Ansible 出力を表示する

Automation Controller の使用時には、API を使用して JSON 形式のコマンド用の Ansible 出力を取得できます。

Ansible の出力を確認するには、https://<controller server name>/api/v2/jobs/<job_id>/job_events/ を参照します。

= Ansible 設定ファイルの場所および設定

本セクションでは、Automation Controller が Ansible 設定ファイル(ansible.cfg)を使用する方法と、カスタムの設定方法を説明します。

Ansible には設定ファイルは必要ありませんが、OS パッケージには多くの場合、カスタマイズできるようにデフォルトで /etc/ansible/ansible.cfg が含まれています。

カスタムの ansible.cfg ファイルを使用するには、それをプロジェクトの root に配置します。Automation Controller は、プロジェクトディレクトリーの root から ansible-playbook を実行し、そこでカスタムの ansible.cfg ファイルを見つけます。

注記

プロジェクトの他の場所にある ansible.cfg ファイルは無視されます。

このファイルで使用できる値は、Ansible ドキュメントの Generating a sample ansible.cfg file を参照してください。

最初はデフォルトを使用することもできますが、デフォルトのモジュールパスや接続タイプなどをここで設定することも可能です。

Automation Controller は、いくつかの ansible.cfg のオプションをオーバーライドします。たとえば、Automation Controller は、SSH ControlMaster ソケット、SSH エージェントソケット、およびその他のジョブ実行ごとのアイテムを、ジョブごとの一時ディレクトリーに保存します。この一時ディレクトリーは、ジョブ実行に使用するコンテナーに渡されます。

= すべての ansible_ 変数の一覧を表示する

Automation Controller が管理対象ホストについて収集するすべての ansible_ 変数の一覧を表示できます。

Ansible は、管理下のマシンに関する「ファクト」をデフォルトで収集します。ファクトには、Playbook やテンプレートでアクセス可能です。

マシンに関するすべての使用可能なファクトを表示するには、setup モジュールを ad hoc アクションとして実行します。 

ansible -m setup hostname
Copy to Clipboard Toggle word wrap

これにより、その特定のホストで使用可能なすべてのファクトのディクショナリーが出力されます。詳細は、Ansible ドキュメントの information-discovered-from-systems-facts を参照してください。

= ALLOW_JINJA_IN_EXTRA_VARS 変数

ALLOW_JINJA_IN_EXTRA_VARS = template 設定は、保存されたジョブテンプレートの追加変数に対してのみ機能します。

プロンプト変数と調査変数は 'template' の対象外です。

このパラメーターには 3 つの値があります。

  • Only On Template Definitions: ジョブテンプレート定義に直接保存された Jinja の使用を許可します (デフォルト)。
  • Never すべての Jinja の使用を無効化します (推奨)。
  • Always 常に Jinja を許可します (極力避けてください。以前の互換性のためのオプションになります)。

このパラメーターは、Automation Controller UI の Jobs Settings ページで設定できます。

= 通知用の コントローラーホストホスト 名の設定

System settings ページから、Base URL of the Service フィールドの https://controller.example.com を希望のホスト名に置き換えて、通知のホスト名を変更できます。

Automation Controller のライセンスを更新すると、通知ホスト名も変更されます。Automation Controller の新規インストールでは、通知用のホスト名を設定する必要はありません。

curl を使用したジョブの起動

Automation Controller API を使用してジョブを起動するのは簡単です。

以下に、curl ツールを使用したわかりやすい例をいくつか示します。

ジョブテンプレート ID が '1' で、コントローラーの IP が 192.168.42.100、有効なログイン認証情報が admin および awxsecret である場合、以下のように新規ジョブを作成できます。 

curl -f -k -H 'Content-Type: application/json' -XPOST \
    --user admin:awxsecret \
    https://192.168.42.100/api/v2/job_templates/1/launch/
Copy to Clipboard Toggle word wrap

これにより JSON オブジェクトが返されるので、解析し、新規作成したジョブの ID を 'id' フィールドから展開するのに使用してください。次の例のように、追加の変数をジョブテンプレートの呼び出しに渡すこともできます。 

curl -f -k -H 'Content-Type: application/json' -XPOST \
    -d '{"extra_vars": "{\"foo\": \"bar\"}"}' \
    --user admin:awxsecret https://192.168.42.100/api/v2/job_templates/1/launch/
Copy to Clipboard Toggle word wrap
注記

extra_vars パラメーターは、単なる JSON ディクショナリーではなく、JSON を含む文字列である必要があります。引用符などをエスケープする場合は注意してください。

= コントローラーの動的インベントリーソースによって返されるインスタンスのフィルタリング

デフォルトでは、Automation Controller の動的インベントリーソース (AWS や Google など) は、使用するクラウド認証情報で利用可能なすべてのインスタンスを返します。インスタンスは、さまざまな属性に基づいて自動的にグループに参加します。たとえば、AWS インスタンスは、リージョン、タグ名、値、セキュリティーグループごとにグループ化されます。お使いの環境で特定のインスタンスを対象にするには、生成されたグループ名が対象となるように Playbook を記述します。

以下に例を示します。 

---
- hosts: tag_Name_webserver
  tasks:
  ...
Copy to Clipboard Toggle word wrap

ジョブテンプレート設定の Limit フィールドを使用して、特定のグループ、ホスト、またはグループとホストの組み合わせのみを対象に Playbook を実行するように制限することもできます。構文は、ansible-playbook コマンドラインの --limit パラメーターと同じです。

自動生成されたグループをカスタムグループにコピーして、独自のグループを作成することもできます。動的インベントリーソースで Overwrite オプションが無効になっていることを確認してください。無効になっていないと、後から同期操作を行った際にカスタムグループが削除され、置き換えられます。

= Automation Controller で Ansible ソースからのリリースされていないモジュールの使用

最新の Ansible Core ブランチで利用可能な機能を、Automation Controller システムに活用するのは非常に簡単です。

まず、利用可能な Ansible Core Modules または Ansible Extra Modules GitHub リポジトリーから、使用する更新済みのモジュールを決定します。

次に、Ansible のソース Playbook (/library) と同じディレクトリーレベルに新しいディレクトリーを作成します。

作成したら、使用するモジュールをコピーし、/library ディレクトリーにドロップします。このモジュールは、まずシステムモジュールによって消費され、通常のパッケージマネージャーで安定版を更新した後に削除できます。

= Automation Controller での callback プラグインの使用

Ansible は、callback プラグインと呼ばれる方法で、Playbook の実行中にアクションを柔軟に処理できます。これらのプラグインを Automation Controller で使用すると、Playbook の実行または失敗時にサービスに通知したり、Playbook の実行後に毎回メールを送信したりできます。

callback プラグインアーキテクチャーに関する公式ドキュメントは、Developing plugins を参照してください。

注記

Automation Controller は stdout callback プラグインをサポートしません。Ansible で許可されるのは 1 つだけであり、すでにイベントデータのストリーミングに使用されているためです。

https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/callback などでサンプルのプラグインも確認してみてください。これらは、各サイトの目的に合わせて変更する必要があります。

これらのプラグインを使用するには、Automation Controller プロジェクトの Playbook と併せて、callback プラグイン .py ファイルを /callback_plugins というディレクトリーに配置します。次に、ジョブ設定の Ansible Callback Plugins フィールドで、パス (1 行に 1 つのパス) を指定します。

Ansible Callback plugins

注記

Ansible に同梱されているコールバックの大半をシステム全体に適用するには、それらを ansible.cfg の callback_whitelist セクションに追加する必要があります。

カスタムのコールバックがある場合は、Enabling callback plugins を参照してください。

= winrm を使用して Windows に接続する

デフォルトでは、Automation Controller はホストへの ssh 接続を試みます。

Windows ホストが属するグループ変数には、winrm 接続情報を追加する必要があります。

まず、ホストが属する Windows グループを編集し、グループのソース画面または編集画面に変数を配置します。

winrm 接続情報を追加するには、以下を実行します。

  • Windows サーバーを含むグループ名の編集アイコン Edit をクリックして、選択したグループのプロパティーを編集します。"variables" セクションで、ansible_connection: winrm という接続情報を追加します。

完了したら、編集内容を保存します。Ansible が以前に SSH 接続を試みて失敗している場合は、ジョブテンプレートを再実行する必要があります。

= 既存のインベントリーファイルおよびホスト/グループ変数を自動化コントローラーにインポートします。

既存の静的インベントリーと付随のホスト変数およびグループ変数を Automation Controller にインポートするには、インベントリーが次のような構造になっている必要があります。 

inventory/
|-- group_vars
|   `-- mygroup
|-- host_vars
|   `-- myhost
`-- hosts
Copy to Clipboard Toggle word wrap

これらのホストおよび変数をインポートするには awx-manage コマンドを実行します。 

awx-manage inventory_import --source=inventory/ \
  --inventory-name="My Controller Inventory"
Copy to Clipboard Toggle word wrap

たとえば、ansible-hosts という名前のインベントリーのファイルがフラットファイルで 1 つしかない場合には、以下のようにインポートします。 

awx-manage inventory_import --source=./ansible-hosts \
  --inventory-name="My Controller Inventory"
Copy to Clipboard Toggle word wrap

競合がある場合や、"My Controller Inventory" という名前のインベントリーを上書きする場合には、以下を実行します。 

awx-manage inventory_import --source=inventory/ \
  --inventory-name="My Controller Inventory" \
  --overwrite --overwrite-vars
Copy to Clipboard Toggle word wrap

以下のようなエラーを受信した場合: 

ValueError: need more than 1 value to unpack
Copy to Clipboard Toggle word wrap

ホストファイルおよび group_vars を保持するディレクトリーを作成します。 

mkdir -p inventory-directory/group_vars
Copy to Clipboard Toggle word wrap

次に、:vars のリストが含まれるグループごとに、inventory-directory/group_vars/<groupname> という名前のファイルを作成して、変数を YAML 形式にフォーマットします。

これにより、インポーターは変換を正しく処理するようになります。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat