Documentation

既知の問題

分離ノードは、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_HEADERSX_FORWARDED_FOR を使用する場合に発生する可能性のあるセキュリティーの問題

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

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

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

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

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

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

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

  • 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 のインベントリーソースでこれを設定できます。

_images/ki-vmware-source-variables-example.png

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 ソケットへの接続を確立できない

以下の接続エラーがコントローラーに表示されます。

_images/ki-tower-connect-error.png

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

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

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

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

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

ローカル管理が期待どおりに機能しない

すべての Playbook は、自動化実行環境と呼ばれる Linux コンテナーで、automation controller により実行されます。

実行中のホストを管理するために delegate_to: localhostlocal_action を使用しても、コンテナー内で実行しているため、この環境では機能しません。

実行が実行しているローカルホストを管理するには、ssh 接続プラグインを使用してコンテナーからローカルホストに接続する必要があります。

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

automation controller のジョブ分離機能では、Playbook で利用できるディレクトリーが、使用中のプロジェクトに制限されます。awx ユーザーのホームディレクトリーにカスタム SSH 設定を使用して SSH の動作をカスタマイズしようとしている場合は、このディレクトリーをコンテナーに公開するディレクトリーのリストに追加する必要があります。

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

_images/ki-job-isolation_path.png

Database server installed on nodes

All nodes in the cluster get a database server even if the nodes do not have a database. This is unexpected and may take up space.

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

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

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

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

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

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