既知の問題¶

特定の Ansible の機能と互換性なし¶

Tower が Playbook を実行する仕組みが原因で、特定の Ansible 機能が Ansible Tower で機能しません。これに関する詳細情報は、Ansible Tower User Guide の「ベストプラクティス」を参照してください。

HTTP 経由で Tower にログインするには回避策が必要¶

HTTP 経由でロードバランサーの背後にある Tower ノード (従来の Tower クラスターインストール) にアクセスする方法は、Ansible Tower Administration Guide の「トラブルシューティング」のセクションの説明手順を参照してください。

デフォルトの LDAP ディレクトリーは LDAP 認証を使用するように設定する必要あり¶

Tower 3.3 では、認証用に複数の LDAP ディレクトリー (最大 6 つ) を設定する機能が導入されました。LDAP の設定ページで、「デフォルト」の LDAP 設定の後に、番号付きの設定スロットが 5 つあります。「デフォルト」が生成されない場合には、Tower では、他のディレクトリー設定を使用した認証は試行されません。

分離されたジョブが失われる¶

分離されたジョブを開始した後にそれを管理するインスタンスを強制終了すると、Tower はジョブのステータスを判別できず、手作業による設定が必要になります。この状況についての詳細は、Red Hat カスタマーポータル (https://access.redhat.com/) 経由で Ansible までお問い合わせください。

REMOTE_HOST_HEADERS で X_FORWARDED_FOR を使用する場合にセキュリティー上の問題が生じる可能性¶

Tower ノードを一部のプロキシーの背後に置くと、セキュリティーの問題が生じる可能性があります。この方法ではトラフィックは常にロードバランサーを経由することが想定されるため、ロードバランサーを回避するトラフィックには X-Forwarded-For ヘッダーのスプーフィングの疑いがあります。 プロキシーのサポート を参照してください。

ホスト名を使って SAML メタデータにアクセスする際のサーバーエラー¶

Tower がホスト名のみを使ってアクセスされる場合 (例: https://my-little-tower)、/sso/metadata/saml/ から SAML メタデータを読み取ろうとすると sp_acs_url_invalid サーバーエラーが生成されます。

FQDN ではなくホスト名のみを使って Tower にアクセスする場合に SAML を使用する設定はサポートされていません。このアクセスを実行するとエラーが発生し、そのエラーは tower.log ファイルにキャプチャーされ、詳細なトレースバック情報と共にブラウザーに表示されます。

FIPS モードでの実行¶

本書の作成時点で、Tower はオペレーティングシステムが FIPS モードで動作するように設定されている場合の実行をサポートしていません。

ライブイベントのステータスインジケーター¶

ライブイベントのステータスドットは、何かの問題が生じると Tower ダッシュボードの上部に赤またはオレンジのドットで表示されます。システムが健全な状態の場合にはドットは表示されません。システムが適切に機能しているように見える場合でも赤またはオレンジのライブイベントのステータスインジケーターが表示される場合、以下の提案が解決に役立つ可能性があります。

• ブラウザーページのリフレッシュ/リロードを手動で試行する

• Firefox および Safari は自己署名証明書を信頼する際に問題が発生すると報告されているため Web ブラウザーを変更してみる

• DNS に一致する自己署名証明書を作成し、これを手動で信頼にインポートしてみる

• 匿名またはプライベートのブラウズセッションを使用してみる

• ブラウザープラグインを無効にしてサービスをブロックするものが何もなくなるようにする

ライブイベントのステータスドットは Tower インスタンスに関する問題のトラブルシューティングに使用され、socketio ログは問題点を指摘します。sosreport を実行してトラブルシューティングのヘルプを収集することができます。root でシステムから sosreport コマンドを実行し、診断 tar ファイルを自動生成し、収集した情報を基に追加のヘルプを得られるように Ansible のサポートチームに問い合わせます。

VMWare 自己署名証明書¶

自己署名証明書を使用する vmware インスタンスをお持ちの場合、以下をクラウドグループの「Source Vars (ソース変数)」設定に追加する必要があります。

"source_vars": "---\nvalidate_certs: False",

ディスクの Celery Beat データベースが破損する¶

celery が正常にシャットダウンされない場合、/var/lib/awx/beat.db ファイルがディスクに残ります。

初期のコメントにトレースバックが確認される場合、/var/lib/awx/beat.db ファイルを手動で削除して Tower を再起動する必要があります。

Firefox でジョブ詳細ページが表示できない¶

スピナーで「作業中...」のメッセージが表示されると、ジョブページからのジョブ実行の詳細を Firefox で無限に表示される場合には、Firefox のバージョンを 62.0 以降にアップグレードしてください。

Safari が web ソケットへの接続を確立できない¶

以下の接続エラーが Tower に表示されます。

このエラーは、Safari が自己署名証明書を使用する Web ソケットへの接続の確立を警告なしに拒否する結果として生じます。この問題を解決するには、Safari が最初にアクセスする web サイトを常に信頼するように設定する必要があります。

1. 現在のブラウザーを閉じてサイトに再びアクセスします。Safari が web サイトの ID を確認できないことを示すエラーメッセージが表示されます。

2. Show Certificate をクリックします。

3. Always trust ... when connecting to ... チェックボックスにチェックを付けて Safari で接続を受け入れるようにします。

このチェックボックスにチェックを付けずに Continue をクリックすると、このエラーが残ります。

Ansible Azure の依存関係¶

Ansible 3.3 には、Ansible 2.6 との互換性がある Microsoft Azure のバインディングが含まれていますが、これらのバインディングは 2.5 以前の Ansible とは機能しません。カスタムの仮想環境で Ansible の以前のバージョンを使用している場合に、Microsoft Azure モジュールを使用するには Azure 依存関係の異なるバージョンをインストールする必要があります。

sudo/su がローカルの Playbook または local_actions を含む Playbook で予想通りに機能しない¶

完全にローカルの Playbook または一部の local_actions ケースを含む Playbook の使用時に sudo/su コマンドが機能しない例が報告されています。これはジョブが有効にされていることが原因である可能性があります。ローカル Playbook または local_actions を含む Playbook で sudo/su コマンドを使用するには、ジョブを無効にする必要があります。ジョブの分離の有効化 の切り替えを オフ に設定して「Tower の設定」画面の ジョブ タブでジョブを無効にすることができます。

保存 をクリックして変更を保存し、サービスを再起動します。

SSH カスタマイズを使用する際の問題¶

Ansible Tower のジョブ分離機能は Playbook の実行時に表示し、使用する Playbook で利用可能な Tower ファイルシステム上のディレクトリーを制限します。Tower ユーザーのホームディレクトリーでカスタム SSH 設定を使用して SSH 動作のカスタマイズを試行する場合、このディレクトリーを bubblewrap で公開されるディレクトリーの一覧に追加する必要があります。

たとえば、/var/lib/awx/.ssh/config にカスタム SSH 設定を追加し、これを Tower ジョブで利用可能にするには、「Tower の設定」画面の ジョブ タブからアクセスする Job Execution Isolation Path (ジョブ実行の分離パス) フィールドでパスを指定することができます。

Ubuntu はバンドルインストールのサポート対象外¶

Ansible Tower のバンドルインストーラーを使用している場合、Red Hat Enterprise Linux および CentOS のみが現時点でサポートされることに注意してください。Ubuntu のサポートはバンドルインストーラーに追加されていません。Ubuntu ユーザーはバンドルされていないインストーラーを引き続き使用することができます。

削除済みの OAuth 認証アカウントの再アクティブ化¶

ソーシャル認証を使用してログインするユーザーは削除されており、ユーザーは、システム管理者がユーザーが再度ログインできるように cleanup_deleted アクションを days=0 の設定で実行するまで再度ログインできず、再作成されることはありません。cleanup_deleted が実行されると、Tower は ansible-tower-service restart コマンドを使用して再起動される必要があります。cleanup_deleted アクションの実行前に削除されているアカウントはログインの試行時に「アカウントが非アクティブです」というメッセージを受信します。

プロジェクトから取得されたインベントリーでの Vault 処理された変数の使用¶

ソース制御プロジェクトからインベントリーを使用する場合には、個別の Vault 変数の値はサポートされません。現在、Vault ファイルはサポートされていません。

Tower 3.3 トークンでの Tower の認証情報の使用¶

Ansible Tower 3.3 の Ansible Tower 認証タイプでは、OAuth2 トークンはサポートされません。現在、ユーザー名とパスワードのみがサポートされています。

保存済みのスケジュールおよびワークフロー設定および Survey¶

ジョブテンプレートの設定がスケジュールされるか、プロンプトの Survey からの回答が含まれるワークフローに追加された場合には、ジョブテンプレート Survey を変更して別の変数を渡すと、保存済みの設定が機能しなくなることがありました。回避策として、保存済みのスケジュール設定/ワークフローノードを削除して、更新済みの survey からの回答を使用して再作成してください。