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

29.1. エラーログ¶

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

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

29.2. sosreport¶

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

Install the sosreport ユーティリティーのインストール。
Generate an sosreport。
sosreport を RedHat サポートに提供します。

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

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

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

29.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

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

automation controller はコントローラーサーバー上のポート 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 をインポートする際に、コントローラーがホストの定義を管理しており、ホスト定義が 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/ パーティションに十分な容量がない場合にはジョブは完了しません。
コントローラーサーバーで automation-controller-service restart を実行します。

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

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

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

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

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

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

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

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

29.11.1. Isolation functionality and variables¶

Automation controller uses container technology to isolate jobs from each other. By default, only the current project is exposed to the container running a job template.

You may find that you need to customize your playbook runs to expose additional directories. To fine tune your usage of job isolation, there are certain variables that can be set.

By default, automation controller will use the system's tmp directory (/tmp by default) as its staging area. This can be changed in the Job Execution Path field of the Jobs settings screen, or in the REST API at /api/v2/settings/jobs:

AWX_ISOLATION_BASE_PATH = "/opt/tmp"

If there are any additional directories that should specifically be exposed from the host to the container that playbooks run in, you can specify those in the Paths to Expose to Isolated Jobs field of the Jobs setting scren, or in the REST API at /api/v2/settings/jobs:

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

注釈

The primary file you may want to add to AWX_ISOLATION_SHOW_PATHS is /var/lib/awx/.ssh, if your playbooks need to use keys or settings defined there.

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

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

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

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

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

vpc_destination_variable: private_ip_address

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

注釈

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

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

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

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

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