既知の問題¶
ansible-runner コンポーネントの起動が期待どおりに機能しない¶
ansible-runner コンポーネントの起動方法 (コントローラーが Playbook の実行用に起動する execution environment 内の実行ファイル) に変更が加えられた結果、後方互換性が維持されなくなりました。常に使用しているプラットフォームバージョンに対応するベース execution environments の上に再ビルドすることが強く推奨されます。これは一般的にアップグレードするのに理想的な方法になります。
削除したデフォルトの組織により、重複した Ansible-Galaxy 認証情報が生成される¶
デフォルトの組織を削除する際、後続のインストールを実行することはできますが、重複した Ansible-Galaxy 認証情報を自動的に削除したり修正したりはしません。詳細は、How to remove duplicated Ansible-Galaxy credentials from the database の KCS アーティクルを参照してください。
分離ノードは、OpenShift デプロイメントでサポートされていない¶
現在、OpenShift に automation controller をデプロイする場合には、分離ノードはサポートされません。
ブラウザーが autocomplete=off の設定を無視する¶
automation controller はフォームの autocomplete=off 属性を活用してブラウザーにリレーするので、そのフォームのフィールドを自動補完するべきではありませんが、シナリオによっては、ブラウザーはこの設定を無視して、フィールドを保存したり、自動補完したりします。これは、ユーザー フォームや 設定 フォームなど、ユーザー名やパスワードといったログインフィールドを含むようなフォームで発生する傾向にあります。現在、この動作を防止するオプションを提供できるように、さらに調査を進めています。
HTTP 経由でログインするには回避策が必要¶
HTTP 経由でロードバランサーの背後にあるコントローラーノード (従来のコントローラークラスターインストール) にアクセスする方法は、Automation Controller Administration Guide の「Troubleshooting section」に記載される説明手順を参照してください。
ジョブスライスと対話の制限¶
スライスされたジョブに制限が課された場合には、この制限が原因で、スライスにホストが割り当てられず、これらのスライスが失敗するので、ジョブ全体が失敗してしまいます。
ジョブスライスの誤用は、ジョブスケジューリングでエラーを引き起こす可能性があります¶
ジョブスライスは、ジョブの実行を水平方向にスケーリングすることを目的としています。ジョブテンプレートでジョブスライスを有効にすると、処理対象のインベントリーが起動時に設定されたスライスの数に分割され、スライスごとにジョブが開始されます。
スライスの数は、コントローラーノードの数と同じかそれ以下になることが予想されます。ジョブスライスの数を極端に多く (たとえば、数千) 設定することはできますが、パフォーマンスが低下する可能性があります。これは、ジョブスケジューラーが、スライスされたジョブとなる数千のワークフローノードを同時にスケジュールするように設計されていないためです。
デフォルトの LDAP ディレクトリーは LDAP 認証を使用するように設定する必要あり¶
認証用に最大 6 つの LDAP ディレクトリーを設定する機能が導入されました。LDAP の設定ページで、「デフォルト」の LDAP 設定の後に、番号付きの設定スロットが 5 つあります。「デフォルト」が生成されない場合、コントローラーでは、他のディレクトリー設定を使用した認証は試行されません。
REMOTE_HOST_HEADERS で X_FORWARDED_FOR を使用する場合に発生する可能性のあるセキュリティーの問題¶
コントローラーノードを一部のプロキシーの背後に置くと、セキュリティーの問題が生じる可能性があります。この方法では、トラフィックは常にロードバランサーを経由するため、ロードバランサーを回避するトラフィックは X-Forwarded-For ヘッダーのスプーフィングの疑いがあります。
ホスト名を使って SAML メタデータにアクセスする際のサーバーエラー¶
コントローラーがホスト名のみを使ってアクセスされる場合 (例: https://my-little-controller)、/sso/metadata/saml/ から SAML メタデータを読み取ろうとすると sp_acs_url_invalid サーバーエラーが生成されます。
FQDN ではなくホスト名のみを使用してコントローラーにアクセスする場合に SAML を使用する設定はサポートされていません。このアクセスを実行するとエラーが発生し、そのエラーは tower.log ファイルにキャプチャーされ、詳細なトレースバック情報と共にブラウザーに表示されます。
ログイン時に SAML 認証により管理者ロールが取り消される¶
以前のバージョンの automation controller では、SAML アダプターはユーザーログインのシステム監査者またはシステム管理者のロールを評価しませんでした。そのため、ログインプロセスは、ユーザーインターフェイスから付与されたユーザーのシステムロールを変更しませんでした。アダプターには、SAML ユーザーフラグ属性マッピング と呼ばれる設定が追加され、SAML 属性またはロールに基づき、これらのロールでログインできるようになりました。また、LDAP アダプターと同様に、指定されていない場合はデフォルトでアダプターがこれらのロールを削除します。ロール、属性、および属性値の設定の関係性がどのように設定されているか、およびユーザーにシステム管理者/監査者のロールが付与されるかどうかについては、logic table を参照してください。
ライブイベントのステータスインジケーター¶
ライブイベントのステータスドットは、何かの問題が生じると自動コントローラーダッシュボードの上部に赤またはオレンジのドットで表示されます。システムが健全な状態の場合にはドットは表示されません。システムが適切に機能しているように見える場合でも赤またはオレンジのライブイベントのステータスインジケーターが表示される場合は、以下の提案が解決に役立つ可能性があります。
ブラウザーページのリフレッシュ/リロードを手動で試行する
Firefox および Safari は自己署名証明書を信頼する際に問題が発生すると報告されているため Web ブラウザーを変更してみる
DNS に一致する自己署名証明書を作成し、これを手動で信頼にインポートしてみる
匿名またはプライベートのブラウズセッションを使用してみる
ブラウザープラグインを無効にしてサービスをブロックするものが何もなくなるようにする
ライブイベントのステータスドットはコントローラーインスタンスに関する問題のトラブルシューティングに使用します。sosreport を実行してトラブルシューティングのヘルプを収集します。システムから sosreport コマンドを実行し、診断 tar ファイルを自動生成し、収集した情報を基に追加のヘルプを得られるように Ansible のサポートチームに問い合わせてください。sosreport の詳細は、Automation Controller Administration Guide の「sosreport」を参照してください。
VMWare 自己署名証明書¶
自己署名証明書を使用する VMware インスタンスをお持ちの場合、以下をクラウドグループの Source Vars 設定に追加する必要があります。
"source_vars": "---\nvalidate_certs: False",
以下のように、VMware vCenter のインベントリーソースでこれを設定できます。
awx-manage inventory_import ユーザー¶
一般的に、root または awx ユーザーがコマンドを実行すると、awx-manage コマンドの使用がサポートされます。しかし、automation controller 4.0 では、root ユーザーとして実行した場合でも、awx-manage inventory_import コマンドが、RedHat 実行環境がホストされているプライベートレジストリーでの認証に失敗します。回避策は、正しく認証されるインストーラーによってイメージが事前にプルされる必要がある場合に、そのコマンドを awx ユーザーとして実行することできます。
OCP デプロイメントで Tower 3.8 の既存のインスタンスグループのアップグレード¶
すべてのジョブの実行は、OCP 4 にデプロイされた automation controller 4.0 のコンテナーグループで行われます。新しい「通常の」インスタンスグループの作成は、ユーザーインターフェースで無効になっていますが、アップグレード時に、通常のインスタンスグループには何も起こりません。コントロールプレーン Pod を含む通常のインスタンスグループをインスタンスとして使用しようとするリソースは容量が 0 になり、ジョブが無期限に保留状態のままになるため、これは既知の問題です。回避策は、これらの「通常の」インスタンスグループをすべて削除することです。デフォルトでは、コントローラー Pod がデプロイされている名前空間でジョブの実行が行われるコンテナーグループがあります。同じまたは他の OpenShift 4 クラスターで他のコンテナーグループを設定することにより、追加の容量を提供できます。
ディスクのデータベースが破損する¶
コントローラーが正常にシャットダウンされていない場合に、ディスクに /var/lib/awx/beat.db ファイルが残されます。これが発生した場合には、ディスパッチャーが起動されず、/var/lib/awx/beat.db ファイルを手動で削除して、コントローラーを再起動しないと、ディスパッチャーが正しく起動しません。
Safari が web ソケットへの接続を確立できない¶
以下の接続エラーがコントローラーに表示されます。
このエラーは、Safari が自己署名証明書を使用する Web ソケットへの接続の確立を警告なしに拒否する結果として生じます。この問題を解決するには、Safari が最初にアクセスする web サイトを常に信頼するように設定する必要があります。
現在のブラウザーを閉じてサイトに再びアクセスします。Safari が web サイトの ID を確認できないことを示すエラーメッセージが表示されます。
Show Certificate をクリックします。
Always trust ... when connecting to ... チェックボックスにチェックを付けて Safari で接続を受け入れるようにします。
このチェックボックスにチェックを付けずに Continue をクリックすると、このエラーが残ります。
ローカル管理が期待どおりに機能しない¶
すべての Playbook は、自動化実行環境と呼ばれる Linux コンテナーで、automation controller により実行されます。
実行中のホストを管理するために delegate_to: localhost や local_action を使用しても、コンテナー内で実行しているため、この環境では機能しません。
実行が実行しているローカルホストを管理するには、ssh 接続プラグインを使用してコンテナーからローカルホストに接続する必要があります。
SSH カスタマイズを使用する際の問題¶
automation controller のジョブ分離機能では、Playbook で利用できるディレクトリーが、使用中のプロジェクトに制限されます。awx ユーザーのホームディレクトリーにカスタム SSH 設定を使用して SSH の動作をカスタマイズしようとしている場合は、このディレクトリーをコンテナーに公開するディレクトリーのリストに追加する必要があります。
たとえば、/var/lib/awx/.ssh/config にカスタム SSH 設定を追加し、これをコントローラージョブで利用可能にするには、「設定」画面の ジョブ タブからアクセスする Job Execution Isolation Path (ジョブ実行の分離パス) フィールドでパスを指定することができます。
ノードにインストールされたデータベースサーバー¶
ノードにデータベースがない場合でも、クラスターのすべてのノードはデータベースサーバーを取得します。これは予期しないため、スペースを占有してしまう可能性があります。
削除済みの OAuth 認証アカウントの再アクティブ化¶
ソーシャル認証を使用してログインするユーザーは削除されており、ユーザーは、システム管理者がユーザーが再度ログインできるように cleanup_deleted アクションを days=0 の設定で実行するまで再度ログインできず、再作成されることはありません。cleanup_deleted が実行されると、コントローラーは automation-controller-service restart コマンドを使用して再起動される必要があります。cleanup_deleted アクションの実行前に削除されているアカウントはログインの試行時に「アカウントが非アクティブです」というメッセージを受信します。
プロジェクトから取得されたインベントリーでの Vault 処理された変数の使用¶
ソース制御プロジェクトからインベントリーを使用する場合には、個別の Vault 変数の値はサポートされません。現在、Vault ファイルはサポートされていません。
保存済みのスケジュールおよびワークフロー設定および Survey¶
ジョブテンプレートの設定がスケジュールされるか、プロンプトの Survey からの回答が含まれるワークフローに追加された場合には、ジョブテンプレート Survey を変更して別の変数を渡すと、保存済みの設定が機能しなくなることがありました。回避策として、保存済みのスケジュール設定/ワークフローノードを削除して、更新済みの survey からの回答を使用して再作成してください。