Ansible Automation Platform のトラブルシューティング
Ansible Automation Platform の問題のトラブルシューティング
概要
はじめに
Ansible Automation Platform のインストールのトラブルシューティングを行うには、Ansible Automation Platform のトラブルシューティングガイドを使用します。
Red Hat ドキュメントへのフィードバック (英語のみ)
このドキュメントの改善に関するご意見がある場合や、エラーを発見した場合は、https://access.redhat.com から Technical Support チームに連絡してください。
第1章 問題の診断
Ansible Automation Platform のトラブルシューティングを開始するには、OpenShift Container Platform の must-gather
コマンドまたは仮想マシンベースのインストールの sos
ユーティリティーを使用して、設定と診断情報を収集します。これらのユーティリティーの出力をサポートケースに添付できます。
1.1. must-gather コマンドを使用した OpenShift Container Platform 上の Ansible Automation Platform のトラブルシューティング
oc adm must-gather
コマンドラインインターフェイス (CLI) コマンドは、OpenShift Container Platform にデプロイされた Ansible Automation Platform インストールから情報を収集します。リソース定義やサービスログなど、問題のデバッグに必要となることが多い情報を収集します。
oc adm must-gather
CLI コマンドを実行すると、収集されたデータを含む新しいディレクトリーが作成され、トラブルシューティングやサポートケースへの添付に使用できます。
OpenShift 環境が registry.redhat.io
にアクセスできず、must-gather
コマンドを実行できない場合は、代わりに oc adm inspect
コマンドを実行します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。
手順
クラスターにログインします。
oc login <openshift_url>
クラスター内のアクセスレベルに基づいて、次のいずれかのコマンドを実行します。
クラスター全体で
must-gather
を実行します。oc adm must-gather --image=registry.redhat.io/ansible-automation-platform-24/aap-must-gather-rhel8 --dest-dir <dest_dir>
-
--image
はデータを収集するイメージを指定する -
--dest-dir
は出力先のディレクトリーを指定する
-
クラスター内の特定の namespace に対して
must-gather
を実行します。oc adm must-gather --image=registry.redhat.io/ansible-automation-platform-24/aap-must-gather-rhel8 --dest-dir <dest_dir> – /usr/bin/ns-gather <namespace>
-
– /usr/bin/ns-gather
は、must-gather
データ収集を指定された namespace に制限する
-
must-gather
アーカイブをサポートケースに添付するには、以前に作成したmust-gather
ディレクトリーから圧縮ファイルを作成し、サポートケースに添付します。たとえば、Linux オペレーティングシステムを使用するコンピューターでは、
<must-gather-local.5421342344627712289/>
をmust-gather
ディレクトリー名に置き換えて、次のコマンドを実行します。$ tar cvaf must-gather.tar.gz <must-gather.local.5421342344627712289/>
関連情報
-
OpenShift CLI (
oc
) のインストールは、OpenShift Container Platform ドキュメントの OpenShift CLI のインストール を参照してください。 -
oc adm inspect
コマンドの実行は、OpenShift Container Platform ドキュメントの ocm adm inspect セクションを参照してください。
1.2. SOS レポートを生成した仮想マシンベースのインストールで Ansible Automation Platform のトラブルシューティング
sos
ユーティリティーは、仮想マシンベースのインストール上の Ansible Automation Platform から設定、診断、およびトラブルシューティングのデータを収集します。
sos
ユーティリティーのインストールと使用の詳細は、テクニカルサポート用の sos レポートの生成 を参照してください。
第2章 Automation Controller のトラブルシューティング関連情報
- Automation Controller のトラブルシューティングの詳細は、Automation Controller 管理ガイドの Automation Controller のトラブルシューティング を参照してください。
- Automation Controller のパフォーマンスのトラブルシューティングは、Automation Controller 管理ガイドの Automation Controller のパフォーマンスのトラブルシューティング を参照してください。
第3章 バックアップおよび復元
- Ansible Automation Platform のバックアップと復元の実行は、Automation Controller 管理ガイドの バックアップと復元 を参照してください。
- OpenShift Container Platform 上の Ansible Automation Platform Operator のインストールのバックアップと復元のトラブルシューティンは、Red Hat Ansible Automation Platform Operator バックアップおよび復元ガイドの トラブルシューティング セクションを参照してください。
第4章 実行環境
実行環境に関する問題をトラブルシュートします。
4.1. 問題 - Private Automation Hub 上の実行環境イメージに対して「コントローラーで使用」オプションを選択できない
Private Automation Hub 上の実行環境イメージには、Use in Controller オプションは使用できません。エラーメッセージ “No Controllers available” も表示されます。
この問題を解決するには、Automation Controller を Private Automation Hub インスタンスに接続します。
手順
Private Automation Hub の
/etc/pulp/settings.py
ファイルを変更し、設定に応じて次のいずれかのパラメーターを追加します。シングルコントローラー
CONNECTED_ANSIBLE_CONTROLLERS = ['<https://my.controller.node>']
ロードバランサーの背後に多数のコントローラー
CONNECTED_ANSIBLE_CONTROLLERS = ['<https://my.controller.loadbalancer>']
ロードバランサーのないコントローラーが多数
CONNECTED_ANSIBLE_CONTROLLERS = ['<https://my.controller.node1>', '<https://my.controller2.node2>']
すべての Private Automation Hub サービスを停止します。
# systemctl stop pulpcore.service pulpcore-api.service pulpcore-content.service pulpcore-worker@1.service pulpcore-worker@2.service nginx.service redis.service
すべての Private Automation Hub サービスを再起動します。
# systemctl start pulpcore.service pulpcore-api.service pulpcore-content.service pulpcore-worker@1.service pulpcore-worker@2.service nginx.service redis.service
検証
- Private Automation Hub で Use in Controller オプションが使用できるようになったことを確認します。
第5章 インストール
インストールに関する問題をトラブルシューティングします。
5.1. 問題 - Ansible Automation Platform インストーラーにバンドルされている特定のパッケージが見つからない
Ansible Automation Platform インストーラーにバンドルされている特定のパッケージが見つからないか、"Repositories disabled by configuration" メッセージが表示されます。
この問題を解決するには、コマンドラインで subscription-manager
コマンドを使用してリポジトリーを有効にします。この問題の解決方法の詳細は、Red Hat Ansible Automation Platform 計画ガイドの Red Hat Ansible Automation Platform サブスクリプションの割り当て の トラブルシューティング セクションを参照してください。
第6章 ジョブ
ジョブに関する問題をトラブルシューティングします。
6.1. 問題 - ローカルホストに対してジョブを実行すると失敗する
Ansible Automation Platform 2 とそのコンテナー化された実行環境では、localhost の使用方法が変更されました。詳細は、Red Hat Ansible Automation Platform アップグレードおよび移行ガイドの AAP 2 用の Playbook の変換 を参照してください。
6.2. 問題 - ジョブがエラーメッセージ “ERROR! couldn’t resolve module/action” で失敗する
ジョブが失敗し、エラーメッセージ “ERROR! couldn’t resolve module/action 'module name'. This often indicates a misspelling, missing collection, or incorrect module path” が表示されます。
このエラーは、モジュールに関連付けられたコレクションが実行環境にない場合に発生する可能性があります。
推奨される解決策は、カスタム実行環境を作成し、その実行環境内に必要なコレクションを追加することです。実行環境の作成の詳細は、「実行環境の作成および消費」の Ansible Builder の使用 を参照してください。
または、次の手順を実行することもできます。
手順
-
プロジェクトリポジトリー内に
collections
フォルダーを作成します。 collections
フォルダー内にrequirements.yml
ファイルを追加し、コレクションを追加します。collections: - <collection_name>
6.3. 問題 - エラーメッセージ “Timeout (12s) waiting for privilege escalation prompt” が表示され、ジョブが失敗する
このエラーは、タイムアウト値が小さすぎる場合に発生し、ジョブが完了する前に停止する可能性があります。接続プラグインのデフォルトのタイムアウト値は 10
です。
この問題を解決するには、次のいずれかの手順を実行してタイムアウト値を増やします。
以下の変更は、Automation Controller 内のすべてのジョブに影響します。特定のプロジェクトにタイムアウト値を使用するには、プロジェクトディレクトリーのルートに ansible.cfg
ファイルを追加し、その ansible.cfg
ファイルに timeout
パラメーター値を追加します。
Automation Controller UI に環境変数として ANSIBLE_TIMEOUT を追加する
- Automation Controller に移動します。
- ナビゲーションパネルから、 → を選択します。
Extra Environment Variables の下に以下を追加します。
{ "ANSIBLE_TIMEOUT": 60 }
CLI を使用して、ansible.cfg ファイルの [defaults] セクションにタイムアウト値を追加します。
/etc/ansible/ansible.cfg
ファイルを編集し、以下を追加します。[defaults] timeout = 60
タイムアウト付きのアドホックコマンドの実行
コマンドラインでアドホック Playbook を実行するには、
ansible-playbook
コマンドに--timeout
フラグを追加します。次に例を示します。# ansible-playbook --timeout=60 <your_playbook.yml>
関連情報
-
DEFAULT_TIMEOUT
設定の詳細は、Ansible コミュニティードキュメントの DEFAULT_TIMEOUT を参照してください。
6.4. 問題 - Automation Controller のジョブが保留状態のままになる
Automation Controller でジョブを起動した後、ジョブは保留状態のままになり、開始されません。
ジョブが保留状態のままになる理由はいくつかあります。この問題のトラブルシューティングの詳細は、Automation Controller 管理ガイドの Playbook が保留中のままになる を参照してください。
保留中のジョブをすべてキャンセルする
保留中のジョブをすべてリスト表示するには、次のコマンドを実行します。
# awx-manage shell_plus
>>> UnifiedJob.objects.filter(status='pending')
保留中のジョブをすべてキャンセルするには、次のコマンドを実行します。
>>> UnifiedJob.objects.filter(status='pending').update(status='canceled')
ジョブ ID を使用して単一のジョブをキャンセルする
特定のジョブをキャンセルするには、
<job_id>
をキャンセルするジョブ ID に置き換えて、次のコマンドを実行します。# awx-manage shell_plus
>>> UnifiedJob.objects.filter(id=_<job_id>_).update(status='canceled')
6.5. 問題 - Private Automation Hub のジョブがエラーメッセージ "denied: requested access to the resource is denied, unauthorized: Insufficient permissions" で失敗する
Private Automation Hub で実行環境を使用するとジョブが失敗し、エラーメッセージ "denied: requested access to the resource is denied, unauthorized: Insufficient permissions" が表示されます。
この問題は、Private Automation Hub がパスワードまたはトークンで保護されており、レジストリー認証情報が実行環境に割り当てられていない場合に発生します。
手順
- Automation Controller に移動します。
- ナビゲーションパネルから、 → を選択します。
- 失敗しているジョブテンプレートに割り当てられている実行環境をクリックします。
- をクリックします。
- プライベート Private Automation Hub から適切な レジストリー認証情報 を実行環境に割り当てます。
関連情報
- Automation Controller で新しい認証情報を作成する方法は、Automation Controller ユーザーガイドの 新しい認証情報の作成 を参照してください。
第7章 ログイン
ログインの問題をトラブルシューティングします。
7.1. 問題 - Automation Controller UI にログインすると、“Invalid username or password. Please try again.” というメッセージが表示される
Automation Controller UI にログインしようとすると、ログインが失敗し、“Invalid username or password. Please try again.” というメッセージが表示されます。
これが発生する理由の 1 つは、同時ログインセッションの最大数 の値が 0
である場合です。同時ログインセッションの最大数の値 は、デバイスごとに各ユーザーに許可されるセッションの最大数を決定します。この値が 0
の場合は、どのユーザーも Automation Controller にログインできません。
デフォルト値は -1
で、許可される最大セッション数の上限が無効になります。これは、制限を課されることなく、いくつでもセッションを実行できることを意味します。
手順
root ユーザーとして、コマンドラインから次のコマンドを実行して、
SESSIONS_PER_USER
変数を-1
に設定し、許可される最大セッション数を無効にします。# echo "settings.SESSIONS_PER_USER = -1" | awx-manage shell_plus --quiet
検証
- Automation Controller に正常にログインできることを確認します。
関連情報
- コントローラーノード CLI のインストールと使用の詳細は、AWX コマンドラインインターフェイス および AWX 管理ユーティリティー を参照してください。
- セッション制限の詳細は、Automation Controller 管理ガイドの セッション制限 を参照してください。
第8章 ネットワーク
ネットワークの問題をトラブルシューティングします。
8.1. 問題 - Ansible Automation Platform コンテナーで使用されるデフォルトのサブネットが内部ネットワークと競合する
Ansible Automation Platform コンテナーで使用されるデフォルトのサブネットが内部ネットワークと競合し、"No route to host" エラーが発生します。
この問題を解決するには、デフォルトの Classless Inter-Domain Routing (CIDR) 値を更新して、デフォルトの Podman ネットワークプラグインで使用される CIDR と競合しないようにします。
手順
すべてのコントローラーノードとハイブリッドノードで、次のコマンドを実行して
custom.py
というファイルを作成します。# touch /etc/tower/conf.d/custom.py
# chmod 640 /etc/tower/conf.d/custom.py
# chown root:awx /etc/tower/conf.d/custom.py
/etc/tower/conf.d/custom.py
ファイルに以下を追加します。DEFAULT_CONTAINER_RUN_OPTIONS = ['--network', 'slirp4netns:enable_ipv6=true,cidr=192.0.2.0/24']
-
この例では、新しい CIDR の値は
192.0.2.0/24
です。
-
この例では、新しい CIDR の値は
すべてのコントローラーノードとハイブリッドノードで Automation Controller サービスを停止して開始します。
# automation-controller-service stop
# automation-controller-service start
すべてのコンテナーは新しい CIDR で起動します。
第9章 Playbook
Automation content navigator を使用して、Playbook をインタラクティブにトラブルシューティングできます。Automation content navigator を使用した Playbook のトラブルシューティングの詳細は、Automation content navigator 作成者ガイドの Automation content navigator を使用した Ansible コンテンツのトラブルシューティング を参照してください。
第10章 サブスクリプション
Automation Controller サブスクリプションのコンプライアンスを維持する方法は、Automation Controller ユーザーガイドの トラブルシューティング: サブスクリプションのコンプライアンスの維持 を参照してください。