Ansible Automation Platform の運用
Ansible Automation Platform インストールのスムーズなデプロイを確実にするためのインストール後の設定
概要
はじめに リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Ansible Automation Platform をインストールした後、デプロイメントがスムーズに実行するように、システムに追加の設定が必要になる場合があります。このガイドでは、Red Hat Ansible Automation Platform のインストール後に実行できる設定タスクの手順を説明します。
免責事項: この情報に含まれる外部の Web サイトへのリンクは、お客様の利便性のみを目的として提供しています。Red Hat はリンクの内容を確認しておらず、コンテンツまたは可用性に責任を負わないものとします。外部 Web サイトへのリンクが含まれていても、Red Hat が Web サイトまたはその組織、製品、もしくはサービスを保証することを意味するものではありません。お客様は、外部サイトまたはコンテンツの使用 (または信頼) によって生じる損失または費用について、Red Hat が責任を負わないことに同意するものとします。
Red Hat ドキュメントへのフィードバック (英語のみ) リンクのコピーリンクがクリップボードにコピーされました!
このドキュメントの改善に関するご意見がある場合や、エラーを発見した場合は、https://access.redhat.com からテクニカルサポートに連絡してリクエストを送信してください。
第1章 Red Hat Ansible Automation Platform のライセンス認証 リンクのコピーリンクがクリップボードにコピーされました!
組織管理者の場合は、サービスアカウントを作成 し、クライアント ID とクライアントシークレットを使用してサブスクリプションを有効にする必要があります。
管理者アクセス権がない場合は、Client ID および Client secret フィールドに Red Hat のユーザー名とパスワードを入力して、サブスクリプションを検索し、Ansible Automation Platform インスタンスに追加できます。
クライアント ID とクライアントシークレットを入力してもサブスクリプションが見つからない場合は、サービスアカウントに正しい権限が設定されていない可能性があります。サービスアカウントの詳細とトラブルシューティングのガイダンスについては、Configure Ansible Automation Platform to authenticate through service account credentials を参照してください。
Red Hat Satellite の場合は、以下のフィールドに Satellite ユーザー名と Satellite パスワードを入力します。
Red Hat Ansible Automation Platform は、利用可能なサブスクリプションまたはサブスクリプションマニフェストを使用して、Ansible Automation Platform の使用を承認します。サブスクリプションを取得するには、次のいずれかを実行できます。
- Ansible Automation Platform を起動するときに、Red Hat のユーザー名とパスワード、サービスアカウントの認証情報、または Satellite の認証情報を使用します。
- Red Hat Ansible Automation Platform インターフェイスを使用するか、Ansible Playbook で手動でサブスクリプションマニフェストファイルをアップロードします。
認証情報を使用して Ansible Automation Platform を有効にするには、Activate with credentials を参照してください。
マニフェストファイルを使用して Ansible Automation Platform を有効にするには、マニフェストファイルを 使用した Ansible Automation Platform の有効化 を参照し てください。
第2章 Red Hat Ansible Automation Platform のプロキシーサポートの設定 リンクのコピーリンクがクリップボードにコピーされました!
プロキシーを使用してトラフィックと通信できるように、Red Hat Ansible Automation Platform を設定できます。プロキシーサーバーは、リソースを別のサーバーから求めているクライアントが出した要求を仲介するロールを果たします。クライアントは、プロキシーサーバーに接続して、別のサーバーからサービスや利用可能なリソースを要求します。そして、このプロキシーサーバーは複雑な内容を簡素化して制御する方法の 1 つとして、その要求を評価します。次のセクションでは、サポート対象のプロキシー設定とその設定方法を説明します。
2.1. ロードバランサーを使用したプロキシーサポートの有効化 リンクのコピーリンクがクリップボードにコピーされました!
フォワードプロキシーはクライアントトラフィックを処理し、それを規制および保護します。Automation Controller は、プロキシーサーバーのサポートを提供するために、Automation Controller 設定の REMOTE_HOST_HEADERS リスト変数を使用して、プロキシーされた要求 (Automation Controller の前にある ALB、NLB、HAProxy、Squid、Nginx、tinyproxy など) を処理します。デフォルトでは、REMOTE_HOST_HEADERS は ["REMOTE_ADDR", "REMOTE_HOST"] に設定されています。
プロキシーサーバーのサポートを有効にするには、Automation Controller の設定ページで REMOTE_HOST_HEADERS フィールドを編集します。
手順
- ナビゲーションパネルから、 → → を選択します。
- をクリックします。
Remote Host Headers フィールドに次の値を入力します。
[ "HTTP_X_FORWARDED_FOR", "REMOTE_ADDR", "REMOTE_HOST" ]
[ "HTTP_X_FORWARDED_FOR", "REMOTE_ADDR", "REMOTE_HOST" ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow - をクリックして設定を保存します。
Automation Controller は、最初の IP アドレスが見つかるまで Remote Host Headers 内のヘッダーのリストを検索して、リモートホストの IP アドレスを特定します。
2.2. 既知のプロキシー リンクのコピーリンクがクリップボードにコピーされました!
Automation Controller を REMOTE_HOST_HEADERS = ['HTTP_X_FORWARDED_FOR', 'REMOTE_ADDR', 'REMOTE_HOST'] で設定している場合は、X-Forwarded-For の値が、Automation Controller の前にあるプロキシーまたはロードバランサ―から送られていることを前提としています。プロキシー/ロードバランサーを使用せずに Automation Controller に到達できる場合、またはプロキシーがヘッダーを検証しない場合は、X-Forwarded-For の値が偽造されて発信元の IP アドレスを偽装する可能性があります。
HTTP_X_FORWARDED_FOR 設定で REMOTE_HOST_HEADERS を使用すると、脆弱性が発生します。
これを回避するには、許可する既知のプロキシーのリストを設定します。
手順
- ナビゲーションパネルから、 → → を選択します。
Proxy IP Allowed List フィールドに、サービスがカスタムリモートヘッダー値を信頼すべきプロキシー IP アドレスのリストを入力します。
注記既知のプロキシーのリストに含まれていないロードバランサーおよびホストの場合、要求が拒否されます。
2.2.1. 既知のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
Automation Controller に既知のプロキシーのリストを設定するには、System Settings ページの Proxy IP Allowed List フィールドにプロキシー IP アドレスを追加します。
手順
- ナビゲーションパネルから、 → → を選択します。
Proxy IP Allowed List フィールドに、次の例の構文を使用して、Automation Controller への接続を許可する IP アドレスを入力します。
Proxy IP Allowed List のエントリーの例
[ "example1.proxy.com:8080", "example2.proxy.com:8080" ]
[ "example1.proxy.com:8080", "example2.proxy.com:8080" ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要-
Proxy IP Allowed List は、ヘッダー入力を適切にサニタイズすること、およびクライアントの実際の送信元 IP と同じ
X-Forwarded-For値を正しく設定することを、リスト内のプロキシーに要求します。Automation Controller は、Proxy IP Allowed List 内の IP アドレスとホスト名を利用して、X-Forwarded-Forに偽装されていない値を提供できます。 次の条件が すべて 満たされない限り、Remote Host Headers の項目として
HTTP_X_FORWARDED_FORを設定しないでください。- SSL Termination でプロキシー環境を使用している
-
プロキシーにより
X-Forwarded-Forヘッダーのサニタイズまたは検証が行われ、クライアントのなりすましを防止できる -
/etc/tower/conf.d/remote_host_headers.pyが信頼されたプロキシーまたはロードバランサーの送信元 IP のみを含むPROXY_IP_ALLOWED_LISTを定義している
-
Proxy IP Allowed List は、ヘッダー入力を適切にサニタイズすること、およびクライアントの実際の送信元 IP と同じ
- をクリックして設定を保存します。
2.3. ロードバランサーを使用したリバースプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
リバースプロキシーは、サーバーへの外部要求を管理し、負荷分散を提供し、サーバーのアイデンティティーを隠してセキュリティーを強化します。Systems Settings の Remote Host Headers フィールドに HTTP_X_FORWARDED_FOR を追加することで、リバースプロキシーサーバー設定をサポートできます。X-Forwarded-For (XFF) HTTP ヘッダーフィールドは、HTTP プロキシーまたはロードバランサー経由で Web サーバーに接続するクライアントの送信元 IP アドレスを識別します。
手順
- ナビゲーションパネルから、 → → を選択します。
Remote Host Headers フィールドに次の値を入力します。
[ "HTTP_X_FORWARDED_FOR", "REMOTE_ADDR", "REMOTE_HOST" ]
[ "HTTP_X_FORWARDED_FOR", "REMOTE_ADDR", "REMOTE_HOST" ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の行を
/etc/tower/conf.d/custom.pyに追加して、アプリケーションが正しいヘッダーを使用していることを確認します。USE_X_FORWARDED_PORT = True USE_X_FORWARDED_HOST = True
USE_X_FORWARDED_PORT = True USE_X_FORWARDED_HOST = TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - をクリックして設定を保存します。
2.4. スティッキーセッションの有効化 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、アプリケーションのロードバランサーが、選択された負荷分散アルゴリズムに基づいて、登録済みのターゲットに各リクエストを個別にルーティングします。ロードバランサーの背後で Automation Hub の複数のインスタンスの実行時に認証エラーを回避するには、スティッキーセッションを有効にする必要があります。スティッキーセッションを有効にすると、ロードバランサーで設定された Cookie と一致するカスタムアプリケーション Cookie が設定され、スティッキーが有効になります。このカスタム Cookie には、アプリケーションで必要な Cookie 属性を含めることができます。
第3章 Egress プロキシーを使用するための Ansible Automation Platform の設定 リンクのコピーリンクがクリップボードにコピーされました!
プラットフォームからのさまざまな目的の Egress (発信) がプロキシーサーバーを介して適切に機能するように、Ansible Automation Platform をデプロイできます。Egress プロキシーを使用すると、クライアントがネットワークサービスに対して間接的に (プロキシーサーバー経由で) 要求できるようになります。まず、クライアントがプロキシーサーバーに接続し、別のサーバーにあるメールなどのリソースを要求します。次に、プロキシーサーバーが指定されたサーバーに接続し、そこからリソースを取得します。
3.1. 概要 リンクのコピーリンクがクリップボードにコピーされました!
Egress プロキシーは、すべての RPM およびコンテナーインストール方式で、Ansible Automation Platform のシステムおよびコンポーネントレベルで設定する必要があります。コンテナーインストーラーの場合、ノード上の podman のシステムプロキシー設定により、プロキシー経由のアクセスに関するほとんどの問題が解決されます。RPM インストールの場合、システムとコンポーネントの両方の設定が必要です。
3.1.1. プロキシーバックエンド リンクのコピーリンクがクリップボードにコピーされました!
HTTP および HTTPS プロキシーには、Squid サーバーを使用できます。Squid は、HTTP、HTTPS、FTP をサポートする Web のフォワードプロキシーです。頻繁に要求される Web ページをキャッシュして再利用することで帯域幅を削減し、応答時間を改善します。GNU GPL でライセンスされています。フォワードプロキシーは、別のネットワーク (通常はインターネット) に送信されるネットワークトラフィックを傍受し、内部のシステムに代わって送信するシステムです。Squid プロキシーを使用すると、必要なすべての通信をプロキシー経由で行うことができます。
Squid プロキシーバックエンドで、必要なすべての Ansible Automation Platform コントロールプレーンポートが開いていることを確認してください。Ansible Automation Platform 固有のポートは次のとおりです。
次のポートはコンテナーインストール用です。
3.2. システムプロキシー設定 リンクのコピーリンクがクリップボードにコピーされました!
発信プロキシーは、コントロールプレーン内のすべてのノードに対してシステムレベルで設定されます。
次の環境変数を設定する必要があります。
http_proxy=“http://external-proxy_0:3128” https_proxy=“http://external-proxy_0:3128” no_proxy=“localhost,127.0.0.0/8,10.0.0.0/8”
http_proxy=“http://external-proxy_0:3128”
https_proxy=“http://external-proxy_0:3128”
no_proxy=“localhost,127.0.0.0/8,10.0.0.0/8”
また、これらの変数を /etc/environment ファイルに追加すると、変数を永続化できます。
インストールプログラムは、インストール中のすべての外部通信を必ずプロキシー経由で実行します。コンテナーインストールの場合、これらの変数により、podman が Egress プロキシーを確実に使用するようになります。
3.3. Automation Controller の設定 リンクのコピーリンクがクリップボードにコピーされました!
RPM インストールプログラムを使用した後、Egress プロキシーを使用するように Automation Controller を設定する必要があります。
これはコンテナーインストーラーでは必要ありません。podman はシステムで設定されたプロキシーを使用し、すべてのコンテナートラフィックをプロキシーにリダイレクトするためです。
Automation Controller の場合は、/api/v2/settings/ で AWX_TASK_ENV 変数を設定します。UI からこれを行うには、次の手順を使用します。
手順
- ナビゲーションパネルから、 → → を選択します。
- をクリックします。
Extra Environment Variables フィールドに変数を追加します。
以下を設定します。
"AWX_TASK_ENV": { "http_proxy": "http://external-proxy_0:3128", "https_proxy": "http://external-proxy_0:3128", "no_proxy": "localhost,127.0.0.0/8" }"AWX_TASK_ENV": { "http_proxy": "http://external-proxy_0:3128", "https_proxy": "http://external-proxy_0:3128", "no_proxy": "localhost,127.0.0.0/8" }Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.1. Automation Controller のプロキシーと連携するために SSH を使用して SCM プロジェクト同期を設定する リンクのコピーリンクがクリップボードにコピーされました!
RPM ベースの Ansible Automation Platform の次の手順では、プロキシーサーバーで動作するために SSH プロトコルを使用して Automation Controller Project Sync を使用する方法を説明します。
手順
Automation Controller ノードで次の手順を実行します。ansible-builder がまだインストールされていない場合は、まずインストールしてください。
subscription-manager repos --enable ansible-automation-platform-2.5-for-rhel-8-x86_64-rpms dnf install ansible-builder
# subscription-manager repos --enable ansible-automation-platform-2.5-for-rhel-8-x86_64-rpms # dnf install ansible-builderCopy to Clipboard Copied! Toggle word wrap Toggle overflow カスタム実行環境を構築します。
まず、作業ディレクトリーを作成します。
su - awx mkdir -p builder/newee cd builder/newee
# su - awx $ mkdir -p builder/newee $ cd builder/neweeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次の内容を含む
execution-environment.ymlファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow registry.redhat.io にログインします。
podman login registry.redhat.io
$ podman login registry.redhat.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow ansible-builder を実行してビルドプロセスを開始します。
cd /var/lib/awx/builder/newee/ ansible-builder build -t my-env -v 3
$ cd /var/lib/awx/builder/newee/ $ ansible-builder build -t my-env -v 3Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 作成したカスタム実行環境を追加します。
- ナビゲーションパネルから、 → → を選択します。
- をクリックします。
-
Image フィールドに
localhost/my-env:latestを追加します。 - をクリックします。
次の手順に従って Ansible Automation Platform インストールプログラムを再実行し、実行環境をデフォルトから、プロジェクトの同期に使用されるカスタマイズされた環境に置き換えます。
注記インストールプログラムを実行する前に、Ansible Automation Platform をバックアップしてください。
./setup.sh -b
# ./setup.sh -bCopy to Clipboard Copied! Toggle word wrap Toggle overflow setup.shファイルと同じ場所のgroup_varsディレクトリーの下に、automationcontrollerファイルを作成します。ファイルの内容は次のとおりです。control_plane_execution_environment: localhost/my-env
control_plane_execution_environment: localhost/my-envCopy to Clipboard Copied! Toggle word wrap Toggle overflow setup.shを実行します。./setup.sh
# ./setup.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow ディレクトリーの下に
ssh_configを作成します。以下に例を示します。Host github.com Hostname ssh.github.com ProxyCommand nc --proxy-type http --proxy proxy.example.com:port %h %p User git
Host github.com Hostname ssh.github.com ProxyCommand nc --proxy-type http --proxy proxy.example.com:port %h %p User gitCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
コンテナー実行環境が
ssh_configファイルを読み取ることができるように、分離されたジョブを公開するには、PATH にssh_configファイルのディレクトリーパスを追加します。 - ナビゲーションパネルで、 → → を選択します。
- をクリックします。
ssh_configファイルが/var/lib/awx/.ssh/ssh_configとして作成されている場合は、これを Paths to expose to isolated jobs に追加します。注記ssh_configが AWX ユーザーによって所有されていることを確認します (#chown awx:awx /var/lib/awx/.ssh/ssh_config)。[ "/var/lib/awx/.ssh:/etc/ssh:O" ]
[ "/var/lib/awx/.ssh:/etc/ssh:O" ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. AWS インベントリーを同期するための設定可能なプロキシー環境の有効化 リンクのコピーリンクがクリップボードにコピーされました!
AWS インベントリーを同期するために設定可能なプロキシー環境を有効にするには、オーバーライド設定ファイルを手動で編集するか、プラットフォーム UI で設定を指定します。
/usr/lib/systemd/system/receptor.service.d/override.confを手動で編集し、次のhttp_proxy環境変数を追加します。http_proxy:<value> https_proxy:<value> proxy_username:<value> Proxy_password:<value>
http_proxy:<value> https_proxy:<value> proxy_username:<value> Proxy_password:<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、以下を実行します。
- UI からこれを行うには、次の手順を使用します。
手順
- ナビゲーションパネルから、 → → を選択します。
- をクリックします。
Extra Environment Variables フィールドに変数を追加します。
以下に例を示します。
"AWX_TASK_ENV": {
"no_proxy": "localhost,127.0.0.0/8,10.0.0.0/8",
"http_proxy": "http://proxy_host:3128/",
"https_proxy": "http://proxy_host:3128/"
},
"AWX_TASK_ENV": {
"no_proxy": "localhost,127.0.0.0/8,10.0.0.0/8",
"http_proxy": "http://proxy_host:3128/",
"https_proxy": "http://proxy_host:3128/"
},
3.5. Automation Hub でのプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
Private Automation Hub がネットワークプロキシーの背後にある場合は、リモートでプロキシーを設定して、ローカルネットワーク外にあるコンテンツを同期できます。
前提条件
- Modify Ansible repo content 権限がある。権限の詳細は、アクセス管理と認証 を参照してください。
次の例のように、Ansible Galaxy から同期するコレクションを識別する
requirements.ymlファイルがある。requirements.yml の例
collections: # Install a collection from Ansible Galaxy. - name: community.aws version: 5.2.0 source: https://galaxy.ansible.comcollections: # Install a collection from Ansible Galaxy. - name: community.aws version: 5.2.0 source: https://galaxy.ansible.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
- Ansible Automation Platform にログインします。
- ナビゲーションパネルから、 → を選択します。
- Community リモートの Details タブで、 をクリックします。
-
YAML requirements フィールドに、
requirements.ymlファイルの内容を貼り付けます。 - をクリックします。
結果
requirements.yml ファイルで識別されたコレクションを、Ansible Galaxy から Private Automation Hub に同期できるようになりました。
次のステップ
同期の手順については、Automation Hub での Ansible Content Collections の同期 を参照してください。
3.6. Event-Driven Ansible でのプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
Event-Driven Ansible の場合、プロキシーを設定するためのグローバル設定はありません。プロジェクトごとにプロキシーを指定する必要があります。
手順
- ナビゲーションパネルから、 → を選択します。
- をクリックします。
Proxy フィールドを使用します。
3.7. 自動化メッシュのプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
自動化メッシュノード上の Receptor からの発信通信をプロキシーサーバー経由でルーティングできます。プロキシーが TLS 証明書を削除しない場合は、Ansible Automation Platform のインストール環境によってプロキシーサーバーの使用が自動的にサポートされます。
メッシュ上のすべてのノードに、インストーラーが自動的に作成する認証局が必要です。
認証局のデフォルトのインストール場所は次のとおりです。
/etc/receptor/tls/ca/mesh-CA.crt
自動的に作成される証明書と鍵の名前には、nodeID が使用されます。
証明書の場合: /etc/receptor/tls/NODEID.crt
鍵の場合: /etc/receptor/tls/NODEID.key
第4章 高度な設定 リンクのコピーリンクがクリップボードにコピーされました!
プラットフォーム管理者は、データベース接続、ロギング、キャッシュ、gRPC サーバーパラメーターなど、Ansible Automation Platform をカスタマイズするための高度な設定を実装できます。
4.1. settings.py ファイル リンクのコピーリンクがクリップボードにコピーされました!
プラットフォーム管理者は、settings.py ファイルを変更して、データベース接続、ロギング設定、キャッシュなど、Ansible Automation Platform のさまざまな側面を設定できます。
settings.py ファイルは 2 つあります。コードベースの一部であり編集してはならないデフォルトの settings.py と、デフォルト値をオーバーライドするために使用できるオーバーライドファイルです。
オーバーライド用の settings.py ファイルの場所と管理は、デプロイメント (RPM ベース、コンテナーベース、または Operator ベースのインストール) に応じて異なる場合があります。
4.1.1. RPM デプロイメント リンクのコピーリンクがクリップボードにコピーされました!
RPM ベースのセットアップのオーバーライド用 settings.py ファイルは直接編集できます。変更はプラットフォームゲートウェイサービスを再起動した後に有効になります。ファイルを編集する場合は、必ず適切な構文と値を使用してください。オーバーライド用の settings.py ファイルは次のディレクトリーにあります。
/etc/ansible-automation-platform/gateway/settings.py
/etc/ansible-automation-platform/gateway/settings.py
4.1.2. コンテナーベースのデプロイメント リンクのコピーリンクがクリップボードにコピーされました!
コンテナーベースのインストールデプロイメントの場合、Ansible Automation Platform はコンテナー内で実行され、settings.py ファイルはコンテナー内に含まれます。ただし、コンテナーベースのインストールデプロイメントで settings.py ファイルを直接編集することは推奨しません。アップグレードまたは新規インストール中に settings.py ファイルが上書きされるためです。
コンテナーベースのインストールデプロイメントで設定をカスタマイズする場合、extra_settings パラメーターを使用すると、インストーラーの更新後もカスタマイズ内容を確実に保持できます。詳細は、「コンテナーインストール」ガイドの インベントリーファイル変数 を参照してください。
4.1.3. Operator ベースのデプロイメント リンクのコピーリンクがクリップボードにコピーされました!
Operator ベースのインストールデプロイメントの場合、settings.py ファイルは通常コンテナー内に配置されます。しかし、Red Hat OpenShift Container Platform のコンテナーは読み取り専用であるため、ユーザーはコンテナー内で直接 settings.py ファイルを変更することはできません。
代わりに、Operator ベースのデプロイメントでは、Ansible Automation Platform カスタムリソースの spec.extra_settings パラメーターを使用して、プラットフォームゲートウェイの設定を変更できます。
4.2. grpc_settings.py ファイル リンクのコピーリンクがクリップボードにコピーされました!
プラットフォーム管理者は、grpc_settings.py ファイルを使用して、gRPC サーバー用の特別なパラメーターまたはカスタムパラメーターを定義できます。
gRPC 設定ファイルは 2 つあります。コードベースの一部であり編集してはならないデフォルトの grpc_default.py と、デフォルト値をオーバーライドするために使用できるオーバーライドファイルです。grpc_default.py ファイルには、正常な gRPC 接続を維持し、中断を防ぐのに役立つデータベースキープアライブオプションが含まれています。このデフォルトオプションを変更する必要がある場合は、grpc_settings.py ファイルを使用して、grpc_defauly.py ファイルの値をオーバーライドできます。
オーバーライド用の grpc_settings.py ファイルの場所と管理は、デプロイメント (RPM ベース、コンテナーベース、または Operator ベースのインストール) によって異なる場合があります。
4.2.1. RPM デプロイメント リンクのコピーリンクがクリップボードにコピーされました!
RPM ベースのセットアップ内のオーバーライド用 grpc_settings.py ファイルは直接編集できます。変更はゲートウェイ systemd サービスを再起動した後に有効になります。ファイルを編集する場合は、必ず適切な構文と値を使用してください。オーバーライド用の grpc_settings.py ファイルは次のディレクトリーにあります。
/etc/ansible-automation-platform/gateway/grpc_settings.py
/etc/ansible-automation-platform/gateway/grpc_settings.py
4.2.2. grpc_settings.py ファイルの変更による影響 リンクのコピーリンクがクリップボードにコピーされました!
gRPC サーバーは、さまざまなプラットフォームサービス間の認証を支援する役割を担います。grpc_settings.py ファイルの設定を変更すると、特に接続の安定性に関して、gRPC 接続の動作とパフォーマンスに大きな影響を与える可能性があります。
gRPC サーバーを期待どおりに機能させるために、gRPC 設定に加えた変更を実稼働環境にデプロイする前に徹底的にテストすることが重要です。
4.3. 設定の読み込み順序 リンクのコピーリンクがクリップボードにコピーされました!
プラットフォームゲートウェイは、アプリケーション設定を管理するために Dynaconf ライブラリーを利用します。Dynaconf では階層化された設定アプローチが採用されています。このアプローチでは、設定が一定の順序で複数のソースから読み込まれ、後のソースが前のソースをオーバーライドします。Ansible Automation Platform は、次の順序で設定を読み込みます。
- アプリケーションの settings.py: このファイルはアプリケーション自体にあり、追加の設定ファイルの読み込み順序と場所を定義します。
- アプリケーションのデフォルト設定: プラットフォームは、アプリケーション自体の一部である defaults.py ファイルからデフォルト設定を読み込みます。このファイルには、API サーバーと gRPC サーバーの両方の一般的な設定が含まれています。
-
お客様のオーバーライドファイル:
/etc/ansible-automation-platform/gateway/settings.pyファイルは、自動的にインストールされ、defaults.py内の任意の設定をオーバーライドするために使用できます。このファイルへの変更は、API サーバーと gRPC サーバーの両方に影響します。 -
アプリケーションの gRPC デフォルト設定: お客様オーバーライドファイルの後、アプリケーションは
grpc_default.pyファイルからのみ gRPC サーバーの追加のデフォルト設定を読み込みます。具体的には、このファイルには、キープアライブパラメーターなど、gRPC サーバーのデータベースオプションが含まれています。 -
お客様の gRPC オーバーライドファイル:
/etc/ansible-automation-platform/gateway/grpc_settings.pyファイル (存在する場合) が次に読み込まれます。このファイルに含まれる設定は gRPC サーバーにのみ適用されます。 -
プラットフォームのオーバーライド設定ファイル:
/etc/ansible-automation-platform/settings.pyファイル内のすべての設定が、gRPC サーバーと API サーバーの両方に適用されます。1 つのノードに複数の Ansible Automation Platform サービスがある場合、このファイル内の項目がすべてのサービスに適用されます。 - 環境変数: 設定ファイルの外部で特定の Ansible Automation Platform 設定を指定できる環境変数が最後に読み込まれます。以前に読み込まれた設定はオーバーライドされます。
第5章 ユーザビリティーアナリティクスおよび Automation Controller からのデータ収集の管理 リンクのコピーリンクがクリップボードにコピーされました!
Automation Controller のユーザーインターフェイスをオプトアウトまたは変更することで、Automation Controller からユーザビリティーアナリティクスおよびデータ収集への参加方法を変更できます。
5.1. ユーザビリティーアナリティクスおよびデータ収集 リンクのコピーリンクがクリップボードにコピーされました!
ユーザビリティーのデータ収集は、Automation Controller に含まれており、Automation Controller ユーザーが Automation Controller とどのように相互作用するかをよりよく理解するためのデータを収集し、今後のリリースの強化に役立て、ユーザーエクスペリエンスの合理化を継続していきます。
このデータ収集の対象となるのは、Automation Controller の試用版をインストールするユーザー、または Automation Controller の新規インストールを行うユーザーのみです。
5.1.1. Automation Controller からのデータ収集の制御 リンクのコピーリンクがクリップボードにコピーされました!
Automation Controller がデータを収集する方法を、 → → メニューから制御できます。
手順
- Automation Controller にログインします。
- ナビゲーションパネルから、 → → を選択します。
- Gather data for Automation Analytics を選択すると、Automation Controller が自動化に関するデータを収集し、Automation Analytics に送信できるようになります。
第6章 SSL/TLS 証明書の更新と変更 リンクのコピーリンクがクリップボードにコピーされました!
現在の SSL/TLS 証明書の有効期限が切れているか、もうすぐ切れる場合は、Ansible Automation Platform で使用される SSL/TLS 証明書を更新または置き換えることができます。
新しいホストなどの新しい情報で SSL/TLS 証明書を再生成する必要がある場合は、証明書を更新する必要があります。
内部認証局によって署名された証明書を使用する場合は、SSL/TLS 証明書を置き換える必要があります。
6.1. コンテナーベースのインストール リンクのコピーリンクがクリップボードにコピーされました!
コンテナーベースの Ansible Automation Platform インストールの TLS 証明書と鍵を変更できます。このプロセスには、新しいカスタム証明書を提供するか、古い証明書を削除または移動する準備手順と、それに続くインストールプログラムの実行が含まれます。
6.1.1. インストールプログラムを使用した TLS 証明書および鍵の変更 リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、インストールプログラムを使用して TLS 証明書と鍵を更新する方法を説明します。
手順
証明書と鍵を準備するには、次のいずれかの方法を選択します。
カスタム証明書を提供する方法 - 更新された TLS 証明書を必要とするサービスごとに、新しい証明書と鍵を Ansible Automation Platform インストーラーを基準とした相対パスにコピーします。次に、新しいファイルへの絶対パスでインベントリーファイル変数を更新します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しい証明書を生成する方法 - インストールプログラムでサービスの新しい証明書を生成する場合は、既存の証明書と鍵を削除または移動します。
Expand 表6.1 サービスごとの証明書と鍵ファイルのパス サービス 証明書ファイルのパス 鍵ファイルパス Automation Controller
~/aap/controller/etc/tower.cert~/aap/controller/etc/tower.keyEvent-Driven Ansible
~/aap/eda/etc/eda.cert~/aap/eda/etc/eda.keyPlatform gateway
~/aap/gateway/etc/gateway.cert~/aap/gateway/etc/gateway.keyAutomation Hub
~/aap/hub/etc/pulp.cert~/aap/hub/etc/pulp.keyPostgreSQL
~/aap/postgresql/server.crt~/aap/postgresql/server.keyReceptor
~/aap/receptor/etc/receptor.crt~/aap/receptor/etc/receptor.keyRedis
~/aap/redis/server.crt~/aap/redis/server.key
証明書を準備したら、インストールディレクトリーから
installPlaybook を実行します。ansible-playbook -i <inventory_file_name> ansible.containerized_installer.install
ansible-playbook -i <inventory_file_name> ansible.containerized_installer.installCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
サービスが実行中でありアクセス可能であることをチェックして、新しい TLS 証明書が使用されていることを確認します。これを行うには、curl を使用して特定のエンドポイントを確認します。
curl -vk https://<hostname_or_ip>:<port_number>/api/v2/
$ curl -vk https://<hostname_or_ip>:<port_number>/api/v2/
このコマンドの出力には、TLS ハンドシェイクの詳細が示されます。正しい証明書が使用されていることを確認するには、次の出力を探します。
* SSL certificate verify OK
* SSL certificate verify OK
6.2. Operator ベースのインストール リンクのコピーリンクがクリップボードにコピーされました!
6.2.1. OpenShift Container Platform 上の Automation Controller の SSL 証明書と鍵の変更 リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、OpenShift Container Platform で実行されている Automation Controller の SSL 証明書と鍵を変更する方法を説明します。
手順
- 署名された SSL 証明書と鍵をセキュアな場所にコピーします。
OpenShift 内に TLS シークレットを作成します。
oc create secret tls ${CONTROLLER_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.keyoc create secret tls ${CONTROLLER_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Automation Controller のカスタムリソースを変更して、
route_tls_secretと新しいシークレットの名前を spec セクションに追加します。oc edit automationcontroller/${CONTROLLER_INSTANCE}oc edit automationcontroller/${CONTROLLER_INSTANCE}Copy to Clipboard Copied! Toggle word wrap Toggle overflow ... spec: route_tls_secret: automation-controller-certs-2023-04-06 ...
... spec: route_tls_secret: automation-controller-certs-2023-04-06 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
TLS シークレットの名前は任意です。この例では、Automation Controller インスタンスに適用される他の TLS シークレットと区別するために、シークレットを作成した日付のタイムスタンプが付けられています。
- 変更が適用されるまで数分待ちます。
新しい SSL 証明書と鍵がインストールされていることを確認します。
true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2.2. OpenShift Container Platform 上の Automation Hub の SSL 証明書と鍵を変更する リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、OpenShift Container Platform で実行されている Automation Hub の SSL 証明書と鍵を変更する方法を説明します。
手順
- 署名された SSL 証明書と鍵をセキュアな場所にコピーします。
OpenShift 内に TLS シークレットを作成します。
oc create secret tls ${AUTOMATION_HUB_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.keyoc create secret tls ${AUTOMATION_HUB_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Automation Hub のカスタムリソースを変更して、
route_tls_secretと新しいシークレットの名前を spec セクションに追加します。oc edit automationhub/${AUTOMATION_HUB_INSTANCE}oc edit automationhub/${AUTOMATION_HUB_INSTANCE}Copy to Clipboard Copied! Toggle word wrap Toggle overflow ... spec: route_tls_secret: automation-hub-certs-2023-04-06 ...
... spec: route_tls_secret: automation-hub-certs-2023-04-06 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
TLS シークレットの名前は任意です。この例では、Automation Hub インスタンスに適用される他の TLS シークレットと区別するために、シークレットを作成した日付のタイムスタンプが付けられています。
- 変更が適用されるまで数分待ちます。
新しい SSL 証明書と鍵がインストールされていることを確認します。
true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3. RPM ベースのインストール リンクのコピーリンクがクリップボードにコピーされました!
RPM ベースのインストールの SSL 証明書を更新または変更するには、インベントリーファイルを編集してインストールプログラムを実行します。インストールプログラムは、すべての Ansible Automation Platform コンポーネントが動作していることを確認します。
または、SSL 証明書を手動で変更することもできます。こちらのほうが迅速ですが、自動確認は行われません。
Red Hat では、Ansible Automation Platform デプロイメントに変更を加える際にはインストールプログラムを使用することを推奨しています。
6.3.1. 自己署名 SSL/TLS 証明書の更新 リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、すべての Ansible Automation Platform コンポーネントの新しい SSL/TLS 証明書を再生成します。
手順
aap_service_regen_cert=trueをインベントリーファイルの[all:vars]セクションに追加します。[all:vars] aap_service_regen_cert=true
[all:vars] aap_service_regen_cert=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - インストーラーを実行します。
検証
Event-Driven Ansible controller で CA ファイルと証明書ファイルを検証します。
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/ansible-automation-platform/eda/server.cert openssl s_client -connect <EDA_FQDN>:443
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/ansible-automation-platform/eda/server.cert openssl s_client -connect <EDA_FQDN>:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow platform gateway で CA ファイルと証明書ファイルを検証します。
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/ansible-automation-platform/gateway/gateway.cert openssl s_client -connect <GATEWAY_FQDN>:443
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/ansible-automation-platform/gateway/gateway.cert openssl s_client -connect <GATEWAY_FQDN>:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow Automation Hub で CA ファイルと証明書ファイルを検証します。
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/pulp/certs/pulp_webserver.crt openssl s_client -connect <HUB_FQDN>:443
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/pulp/certs/pulp_webserver.crt openssl s_client -connect <HUB_FQDN>:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow Automation Controller で CA ファイルと証明書ファイルを検証します。
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/tower/tower.cert openssl s_client -connect <CONTROLLER_FQDN>:443
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/tower/tower.cert openssl s_client -connect <CONTROLLER_FQDN>:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.2. インストールプログラムを使用した SSL/TLS 証明書および鍵の変更 リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、インベントリーファイル内の SSL/TLS 証明書と鍵を変更する方法を説明します。
前提条件
- 証明書は PEM 形式である必要があります。
- 中間認証局がある場合は、それをサーバー証明書に追加する必要があります。
- 正しい証明書の順序を使用してください。最初にサーバー証明書を指定し、その後に中間認証局を指定します。
詳細は、NGINX ドキュメントの SSL 証明書のセクション を参照してください。
手順
- 新しい SSL/TLS 証明書と鍵を Ansible Automation Platform インストーラーに関連するパスにコピーします。
SSL/TLS 証明書と鍵の絶対パスをインベントリーファイルに追加します。これらの 変数の設定に関するガイダンスは、インベントリーファイル 変数 を参照してください。
-
Event-Driven Ansible controller:
automationedacontroller_ssl_cert、automationedacontroller_ssl_key、custom_ca_cert -
Platform gateway:
automationgateway_ssl_cert、automationgateway_ssl_key、custom_ca_cert -
Automation Hub:
automationhub_ssl_cert、automationhub_ssl_key、custom_ca_cert Automation Controller:
web_server_ssl_cert、web_server_ssl_key、custom_ca_cert注記custom_ca_certは、中間認証局に署名したルート認証局である必要があります。このファイルは/etc/pki/ca-trust/source/anchorsにインストールされます。
-
Event-Driven Ansible controller:
- インストールプログラムを実行します。
6.3.3. SSL/TLS 証明書および鍵の手動変更 リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、すべての Ansible Automation Platform コンポーネントの SSL/TLS 証明書と鍵を手動で変更する方法を説明します。
手順
現在の SSL/TLS 証明書をバックアップします。
cp <CERT_PATH> <CERT_PATH>-$(date +%F)
cp <CERT_PATH> <CERT_PATH>-$(date +%F)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 現在の鍵ファイルをバックアップします。
cp <KEY_PATH> <KEY_PATH>-$(date +%F)
cp <KEY_PATH> <KEY_PATH>-$(date +%F)Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 新しい SSL/TLS 証明書を証明書パスにコピーします。
- 新しい鍵を鍵パスにコピーします。
SELinux コンテキストを復元します。
restorecon -v <CERT_PATH> <KEY_PATH>
restorecon -v <CERT_PATH> <KEY_PATH>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 証明書と鍵ファイルに適切なパーミッションを設定します。
chown <OWNER>:<GROUP> <CERT_PATH> <KEY_PATH> chmod 0600 <CERT_PATH> <KEY_PATH>
chown <OWNER>:<GROUP> <CERT_PATH> <KEY_PATH> chmod 0600 <CERT_PATH> <KEY_PATH>Copy to Clipboard Copied! Toggle word wrap Toggle overflow NGINX 設定をテストします。
nginx -t
nginx -tCopy to Clipboard Copied! Toggle word wrap Toggle overflow NGINX をリロードします。
systemctl reload nginx.service
systemctl reload nginx.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しい SSL/TLS 証明書と鍵がインストールされていることを確認します。
true | openssl s_client -showcerts -connect <COMPONENT_FQDN>:443
true | openssl s_client -showcerts -connect <COMPONENT_FQDN>:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expand 表6.2 サービスごとの SSL/TLS 証明書と鍵ファイルのパス サービス 証明書ファイルのパス 鍵ファイルパス 所有者: グループ Automation Controller
/etc/tower/tower.cert/etc/tower/tower.keyroot:awxAutomation Hub
/etc/pulp/certs/pulp_webserver.crt/etc/pulp/certs/pulp_webserver.keyroot:pulpEvent-Driven Ansible Controller
/etc/ansible-automation-platform/eda/server.cert/etc/ansible-automation-platform/eda/server.keyroot:edaPlatform gateway
/etc/ansible-automation-platform/gateway/gateway.cert/etc/ansible-automation-platform/gateway/gateway.keyroot:gateway