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

24.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 にエラーを報告してください。

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

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

ホストに ssh 接続できますか? Ansible では、管理するサーバーに SSH でアクセスできる必要があります。
ホスト名と IP がインベントリーファイルに正しく追加されていますか? (タイプミスがないか確認してください)

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

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

SESSION_COOKIE_SECURE = False
CSRF_COOKIE_SECURE = False

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

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

ansible-tower-service restart

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

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

24.5. Playbook の実行に関する問題¶

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

現在コマンドを実行しているユーザーを認証していますか? そうでない場合には、ユーザー名の設定方法を確認して、--user=username または -u username コマンドを指定してユーザーを指定してください。
YAML ファイルで正しくインデントされていますか? 正しくホワイトスペースを揃える必要がある場合があります。YAML ではインデントのレベルは重要です。yamlint を使用して Playbook を確認してください。詳しい情報は、http://docs.ansible.com/YAMLSyntax.html で YAML 入門を参照してください。
- で始まるアイテムは、リストアイテムまたはプレイとみなされます。key: value 形式のアイテムは、ハッシュまたはディクショナリーとして機能します。- プレイが多すぎたり、抜けていたりしないように確認してください。

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

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

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

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

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

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

24.8. Playbook が保留状態で止まる¶

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

すべてのスパーバイザーサービスが supervisorctl status 経由で実行されていることを確認します。
/var/ のパーティションに 1 GB 以上の空き容量があることを確認します。/var/ パーティションに十分な容量がない場合にはジョブは完了しません。
Tower サーバーで ansible-tower-service restart を実行します。

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

24.9. Towr ジョブのキャンセル¶

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

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

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

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

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

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

24.10.1. Bubblewrap 機能および変数¶

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

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

左のナビゲーションバーから設定 () アイコンをクリックします。
ジョブ タブをクリックします。
「ジョブの分離の有効化」が表示されるまで下方向にスクロールして、切り替えボタンの選択肢を OFF に変更して bubblewrap サポートを無効化するか、ON を選択して有効化します。

デフォルトでは、Tower はシステムの tmp ディレクトリー (デフォルト設定: /tmp) をステージングエリアとして使用します。これは、タワーの設定画面の Job Isolation Execution Path フィールドか、設定ファイルの以下のエントリーを更新することで変更できます。

AWX_PROOT_BASE_PATH = "/opt/tmp"

システム上に機密で非表示にすべきその他の情報がある場合には、Paths to Hide to Isolated Jobs の Tower の設定画面または、設定ファイルの以下のエントリーを更新して指定してください。

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

特に公開する必要のあるディレクトリーがある場合には、Paths to Expose to Isolated Job の Tower の設定画面または、設定ファイルの以下のエントリーを更新して指定してください。

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

注釈

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

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

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

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

Tower のインターフェースでインベントリーを選択します。
ソースが AWS に設定されたグループをクリックして、ソースタブをクリックします。
ソース変数 ボックスで以下を入力します。

vpc_destination_variable: private_ip_address

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

注釈

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

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

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

Playbook のホスト宣言の行がインベントリーのグループ/ホストと完全に一致しているようにしてください (大文字、小文字の区別があります)。
これらが一致しておらず、Ansible Core 2.0 以降を使用している場合には、グループ名にスペースが含まれていないかを確認し、アンダースコアに変更するか、スペースを消して、グループが認識されるようにします。
ジョブテンプレートに制限を指定している場合に有効な制限値であるかを確認し、インベントリーに含まれるものと一致するかをチェックします。http://docs.ansible.com/intro_patterns.html で説明されているように、制限フィールドには、パターン引数を使用できます。

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