Ansible Automation Platform のトラブルシューティング


Red Hat Ansible Automation Platform 2.4

Ansible Automation Platform の問題のトラブルシューティング

Red Hat Customer Content Services

概要

このガイドでは、Red Hat 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) がインストールされている。

手順

  1. クラスターにログインします。

    oc login <openshift_url>
  2. クラスター内のアクセスレベルに基づいて、次のいずれかのコマンドを実行します。

    • クラスター全体で 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 に制限する
  3. 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 のトラブルシューティング関連情報

第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 インスタンスに接続します。

手順

  1. 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>']
  2. すべての 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
  3. すべての 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 の使用 を参照してください。

または、次の手順を実行することもできます。

手順

  1. プロジェクトリポジトリー内に collections フォルダーを作成します。
  2. 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 を追加する

  1. Automation Controller に移動します。
  2. ナビゲーションパネルから、SettingsJobs settings を選択します。
  3. 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 が保留中のままになる を参照してください。

保留中のジョブをすべてキャンセルする

  1. 保留中のジョブをすべてリスト表示するには、次のコマンドを実行します。

    # awx-manage shell_plus
    >>> UnifiedJob.objects.filter(status='pending')
  2. 保留中のジョブをすべてキャンセルするには、次のコマンドを実行します。

    >>> 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 がパスワードまたはトークンで保護されており、レジストリー認証情報が実行環境に割り当てられていない場合に発生します。

手順

  1. Automation Controller に移動します。
  2. ナビゲーションパネルから、AdministrationExecution Environments を選択します。
  3. 失敗しているジョブテンプレートに割り当てられている実行環境をクリックします。
  4. Edit をクリックします。
  5. プライベート 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 に正常にログインできることを確認します。

関連情報

第8章 ネットワーク

ネットワークの問題をトラブルシューティングします。

8.1. 問題 - Ansible Automation Platform コンテナーで使用されるデフォルトのサブネットが内部ネットワークと競合する

Ansible Automation Platform コンテナーで使用されるデフォルトのサブネットが内部ネットワークと競合し、"No route to host" エラーが発生します。

この問題を解決するには、デフォルトの Classless Inter-Domain Routing (CIDR) 値を更新して、デフォルトの Podman ネットワークプラグインで使用される CIDR と競合しないようにします。

手順

  1. すべてのコントローラーノードとハイブリッドノードで、次のコマンドを実行して 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
  2. /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 です。
  3. すべてのコントローラーノードとハイブリッドノードで 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 ユーザーガイドの トラブルシューティング: サブスクリプションのコンプライアンスの維持 を参照してください。

法律上の通知

Copyright © 2025 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.
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.