Documentation

27. コントローラーのトラブルシューティング

27.1. エラーログ

コントローラーサーバーのエラーは /var/log/tower にロギングされます。supervisor ログは /var/log/supervisor/ に、Nginx web サーバーのエラーは httpd エラーログに記録されます。その他のコントローラーロギングの設定は /etc/tower/conf.d/ で行うようにしてください。

大半のブラウザーに組み込まれている JavaScript コンソールを使用してクライアント側の問題をチェックし、Red Hat カスタマーポータル (https://access.redhat.com/) 経由で Ansible にエラーを報告してください。

27.2. sosreport

sosreport は、サポートの診断情報を収集して、報告する問題の分析と調査に使用できるようにするユーティリティーです。この情報をテクニカルサポートに適切に提供するには、Red Hat カスタマーポータルの Knowledgebase article for sosreport から、次の手順を実行します。

  1. Install the sosreport ユーティリティーのインストール。

  2. Generate an sosreport。

  3. sosreport を RedHat サポートに提供します。

27.3. ホストへの接続に関する問題

ホストの接続エラーが原因で、クイックスタートガイドからの helloworld.yml のサンプルの Playbook やその他の Playbook を実行できない場合は、以下をお試しください。

  • ホストに ssh 接続できますか? Ansible では、管理するサーバーに SSH でアクセスできる必要があります。

  • ホスト名と IP がインベントリーファイルに正しく追加されていますか? (タイプミスがないか確認してください)

27.4. HTTP 経由でコントローラーにログインできない

コントローラーへのアクセスはセキュアなプロトコル (HTTPS) を使用して、意図的に制限しています。ロードバランサーやプロキシーの背後にコントローラーノードの実行が「HTTP のみ」として設定されている場合や、SSL (トラブルシューティングのためなど) なしにアクセスする場合に、コントローラーインスタンスの /etc/tower/conf.d にある custom.py ファイルで以下の設定を調整する必要があります。

SESSION_COOKIE_SECURE = False
CSRF_COOKIE_SECURE = False

これらの設定を False に変更すると、HTTP プロトコルの使用時にコントローラーが Cookie とログインセッションを管理します。変更を正しく適用するには、この設定は、クラスターインストールの全ノードで行う必要があります。

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

automation-controller-service restart

27.5. ライブイベント用の WebSockets ポートが機能しない

automation controller はコントローラーサーバー上のポート 80/443 を使用して Playbook アクティビティーやその他のライブ更新をクライアントのブラウザーにストリーミングします。これらのポートは、デフォルトで 80/443 に設定されていますが、これらのポートがファイアウォールでブロックされている場合には、以前の Websocket ポート用に開放または追加するファイアウォールルールを削除してください。削除することで、ファイアウォールでこのポートへのトラフィックが許可されます。

27.6. Playbook の実行に関する問題

Playbook のエラーが原因で、クイックスタートガイドからの helloworld.yml のサンプルの Playbook やその他の Playbook を実行できない場合は、以下をお試しください。

  • 現在コマンドを実行しているユーザーを認証していますか? そうでない場合には、ユーザー名の設定方法を確認して、--user=username または -u username コマンドを指定してユーザーを指定してください。

  • YAML ファイルで正しくインデントされていますか? 正しくホワイトスペースを揃える必要がある場合があります。YAML ではインデントのレベルは重要です。yamlint を使用して Playbook を確認してください。詳しい情報は、http://docs.ansible.com/YAMLSyntax.html で YAML 入門を参照してください。

  • - で始まるアイテムは、リストアイテムまたはプレイとみなされます。key: value 形式のアイテムは、ハッシュまたはディクショナリーとして機能します。- プレイが多すぎたり、抜けていたりしないように確認してください。

27.7. ジョブ実行時に関する問題

Playbook からのジョブの実行で問題がある場合は、Playbook の YAML ファイルを確認するようにしてください。ソース管理メカニズムを使用するか手動で Playbook をインポートする際に、コントローラーがホストの定義を管理しており、ホスト定義が hosts: all に設定されている必要があります。

27.8. Playbook が「ジョブテンプレート」のドロップダウンリストに表示されない

Playbook がジョブテンプレートのドロップダウンリストに表示されない場合は、以下に記載の内容を複数確認してください。

  • Playbook が有効な YML で、Ansible で解析できることを確認してください。

  • "awx" ユーザーにファイルが表示されるように、プロジェクトパス (/var/lib/awx/projects) が設定されていることを確認してください。以下のコマンドを実行して所有者を変更できます。

chown awx -R /var/lib/awx/projects/

27.9. Playbook が保留状態で止まる

Playbook のジョブの実行を試行して、「保留中で」止まる場合、以下を試行してください。

  • すべてのスパーバイザーサービスが supervisorctl status 経由で実行されていることを確認します。

  • /var/ のパーティションに 1 GB 以上の空き容量があることを確認します。/var/ パーティションに十分な容量がない場合にはジョブは完了しません。

  • コントローラーサーバーで automation-controller-service restart を実行します。

問題が継続する場合には、コントローラーサーバーで root として sosreport を実行してから、その結果を添付して support request をしてください。

27.10. コントローラージョブをキャンセルします。

実行中のコントローラージョブに cancel 要求を発行すると、コントローラーは ansible-playbook プロセスに SIGINT を発行します。多くの場合にはこの要求で Ansible は新規タスクのディスパッチを停止して終了しますが、すでにディスパッチされたモジュールタスクは完了するまで実行されます。この動作は、Ansible のコマンドラインを実行中に Ctrl-C を押す操作とよく似ています。

ソフトウェアの依存関係に関しては、実行中のジョブがキャンセルされた場合、そのジョブは基本的には削除されますが、依存関係は残ります。

27.11. 外部のデータベースを再利用するとインストールに失敗する

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

たとえば、クラスターインストールを実行して、もう一度インストールし直し、同じ外部データベースを再利用して 2 つ目の HA インストールを実行したとします。その場合に、この 2 回目のインストールのみが失敗します。

以前のインストールで使用した外部データベースを設定する場合は、追加のインストールを正常に完了できるように、クラスターノードで使用するデータベースを手動で消去する必要があります。

Automation controller は、コンテナテクノロジーを使用して、ジョブを相互に分離します。デフォルトでは、現在のプロジェクトのみがジョブテンプレートを実行しているコンテナに公開されます。

追加のディレクトリーを公開するには、Playbook の実行をカスタマイズする必要がある場合があります。ジョブ分離の使用法を微調整するために、設定できる特定の変数があります。

デフォルトでは、automation controller はシステムの tmp ディレクトリー (デフォルトは /tmp) をステージング領域として使用します。これは、ジョブ設定画面の Job Execution Path (ジョブの実行パス) フィールドから、または /api/v2/settings/jobs の REST API で以下を変更できます。

AWX_ISOLATION_BASE_PATH = "/opt/tmp"

The host trusted cert store is exposed to execution environments by default:

AWX_ISOLATION_SHOW_PATHS = [
   '/etc/pki/ca-trust:/etc/pki/ca-trust:O',
   '/usr/share/pki:/usr/share/pki:O',
]

ホストから Playbook が実行するコンテナーに具体的に公開する必要のある追加のディレクトリーがある場合は、ジョブ設定画面の Paths to Expose to Isolated Jobs (分離されたジョブに公開するパス) フィールド、または /api/v2/settings/jobs のREST API で指定できます。

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

注釈

Playbook が /var/lib/awx/.ssh で定義した鍵や設定を使用する必要がある場合には、このファイルを主要ファイルとして、AWX_ISOLATION_SHOW_PATHS に追加してください。

上記のフィールドは、ジョブ設定ウィンドウで確認できます。

_images/configure-tower-jobs-isolated-jobs-fields.png

27.12. コントローラーインベントリーのプライベート EC2 VPC インスタンス

デフォルトでは、コントローラーは Elastic IP (EIP) が関連付けられた VPC にだけインスタンスを表示します。VPC インスタンスをすべて表示するには、以下の手順を実行してください。

  1. コントローラーのインターフェースでインベントリーを選択します。

  2. ソースが AWS に設定されたグループをクリックして、ソースタブをクリックします。

  3. Source Variables ボックスに以下を入力します。

vpc_destination_variable: private_ip_address

次に、保存して、グループの更新をトリガーします。これが完了したら、すべての VPC インスタンスを表示できるはずです。

注釈

インスタンスを設定する場合には、コントローラーが、インスタンスへのアクセス権がある VPC 内で実行している必要があります。

27.13. "Error: provided hosts list is empty" のトラブルシューティング

コントローラーで Playbook を実行しようとしたときに「Skipping: No Hosts Matched」のメッセージが表示された場合は、以下のように確認する点が複数あります。

  • Playbook のホスト宣言の行がインベントリーのグループ/ホストと完全に一致しているようにしてください (大文字、小文字の区別があります)。

  • これらが一致しておらず、Ansible Core 2.0 以降を使用している場合には、グループ名にスペースが含まれていないかを確認し、アンダースコアに変更するか、スペースを消して、グループが認識されるようにします。

  • ジョブテンプレートに制限を指定している場合に有効な制限値であるかを確認し、インベントリーに含まれるものと一致するかをチェックします。http://docs.ansible.com/intro_patterns.html で説明されているように、制限フィールドには、パターン引数を使用できます。

これらのオプションを確認した後にも問題が継続する場合には、サポートチケットを起票してください。