Documentation

29. Tower のトラブルシューティング

29.1. エラーログ

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

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

29.2. sosreport

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

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

  2. Generate an sosreport。

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

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

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

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

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

29.4. HTTP 経由で Tower にログインできない

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

SESSION_COOKIE_SECURE = False
CSRF_COOKIE_SECURE = False

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

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

ansible-tower-service restart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Tower サーバーで ansible-tower-service restart を実行します。

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

29.10. Towr ジョブのキャンセル

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

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

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

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

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

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

29.11.1. Bubblewrap 機能および変数

Ansible Tower の bubblewrap 機能により、Tower ファイルシステムのどのディレクトリーが Playbook に表示され、また Playbook の実行時に使用できるかを制限します。場合によっては bubblewrap 設定をカスタマイズする必要がある場合もあります。bubblewrap の使用を微調整するために、いくつかの変数を設定することができます。

bubblewrap がジョブの実行をサポートしないように無効化または有効化するには (Playbook の実行のみ)、管理ユーザーとしてログインしていることを確認してください。

  1. 左のナビゲーションバーから設定 (settings) アイコンをクリックします。

  2. ジョブ タブをクリックします。

  3. 「ジョブの分離の有効化」で、トグルボタンの選択を OFF に変更すると、bubblewrap サポートを無効にするか、ON を選択して有効にします。

_images/configure-tower-jobs-disable-proot-job-isolation.png

デフォルトでは、Tower はシステムの tmp ディレクトリー (デフォルトは /tmp) をステージング領域として使用します。これは、「Configure Tower (Tower の設定)」画面の Job Execution Path (ジョブの実行パス) フィールドからか、または設定ファイルで以下のエントリーを更新して変更できます。

AWX_PROOT_BASE_PATH = "/opt/tmp"

システム上に機密で非表示にすべきその他の情報がある場合には、「Configure Tower (Tower の設定)」画面の 分離されたジョブから非表示にするパス で指定するか、または設定ファイルで以下のエントリーを更新して指定することができます。

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

とくに公開する必要のあるディレクトリーがある場合には、「Configure Tower (Tower の設定)」画面の 分離されたジョブの公開するパス に指定するか、または設定ファイルで以下のエントリーを更新して指定することができます。

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

注釈

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

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

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

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

29.12. Tower インベントリーのプライベート EC2 VPC インスタンス

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

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

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

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

vpc_destination_variable: private_ip_address

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

注釈

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

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

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

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

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

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

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