Ansible Automation Platform の運用


Red Hat Ansible Automation Platform 2.5

Ansible Automation Platform インストールのスムーズなデプロイを確実にするためのインストール後の設定

Red Hat Customer Content Services

概要

このガイドでは、Red Hat 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 の使用を承認します。サブスクリプションを取得するには、次のいずれかを実行できます。

  1. Ansible Automation Platform を起動するときに、Red Hat のユーザー名とパスワード、サービスアカウントの認証情報、または Satellite の認証情報を使用します。
  2. 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 フィールドを編集します。

手順

  1. ナビゲーションパネルから、SettingsAutomation ExecutionSystem を選択します。
  2. Edit をクリックします。
  3. Remote Host Headers フィールドに次の値を入力します。

    [
      "HTTP_X_FORWARDED_FOR",
      "REMOTE_ADDR",
      "REMOTE_HOST"
    ]
    Copy to Clipboard Toggle word wrap
  4. Save をクリックして設定を保存します。

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 を使用すると、脆弱性が発生します。

これを回避するには、許可する既知のプロキシーのリストを設定します。

手順

  1. ナビゲーションパネルから、SettingsAutomation ExecutionSystem を選択します。
  2. Proxy IP Allowed List フィールドに、サービスがカスタムリモートヘッダー値を信頼すべきプロキシー IP アドレスのリストを入力します。

    注記

    既知のプロキシーのリストに含まれていないロードバランサーおよびホストの場合、要求が拒否されます。

2.2.1. 既知のプロキシーの設定

Automation Controller に既知のプロキシーのリストを設定するには、System Settings ページの Proxy IP Allowed List フィールドにプロキシー IP アドレスを追加します。

手順

  1. ナビゲーションパネルから、SettingsAutomation ExecutionSystem を選択します。
  2. Proxy IP Allowed List フィールドに、次の例の構文を使用して、Automation Controller への接続を許可する IP アドレスを入力します。

    Proxy IP Allowed List のエントリーの例

    [
      "example1.proxy.com:8080",
      "example2.proxy.com:8080"
    ]
    Copy to Clipboard Toggle word wrap

    重要
    • 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 を定義している
  3. Save をクリックして設定を保存します。

2.3. ロードバランサーを使用したリバースプロキシーの設定

リバースプロキシーは、サーバーへの外部要求を管理し、負荷分散を提供し、サーバーのアイデンティティーを隠してセキュリティーを強化します。Systems Settings の Remote Host Headers フィールドに HTTP_X_FORWARDED_FOR を追加することで、リバースプロキシーサーバー設定をサポートできます。X-Forwarded-For (XFF) HTTP ヘッダーフィールドは、HTTP プロキシーまたはロードバランサー経由で Web サーバーに接続するクライアントの送信元 IP アドレスを識別します。

手順

  1. ナビゲーションパネルから、SettingsAutomation ExecutionSystem を選択します。
  2. Remote Host Headers フィールドに次の値を入力します。

    [
      "HTTP_X_FORWARDED_FOR",
      "REMOTE_ADDR",
      "REMOTE_HOST"
    ]
    Copy to Clipboard Toggle word wrap
  3. 以下の行を /etc/tower/conf.d/custom.py に追加して、アプリケーションが正しいヘッダーを使用していることを確認します。

    USE_X_FORWARDED_PORT = True
    USE_X_FORWARDED_HOST = True
    Copy to Clipboard Toggle word wrap
  4. Save をクリックして設定を保存します。

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 固有のポートは次のとおりです。

acl Safe_ports port 81
acl Safe_ports port 82
acl Safe_ports port 389
acl Safe_ports port 444
acl Safe_ports port 445
acl SSL_ports port 22
Copy to Clipboard Toggle word wrap

次のポートはコンテナーインストール用です。

acl SSL_ports port 444
acl SSL_ports port 445
acl SSL_ports port 8443
acl SSL_ports port 8444
acl SSL_ports port 8445
acl SSL_ports port 8446
acl SSL_ports port 44321
acl SSL_ports port 44322

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
Copy to Clipboard Toggle word wrap

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”
Copy to Clipboard Toggle word wrap

また、これらの変数を /etc/environment ファイルに追加すると、変数を永続化できます。

インストールプログラムは、インストール中のすべての外部通信を必ずプロキシー経由で実行します。コンテナーインストールの場合、これらの変数により、podman が Egress プロキシーを確実に使用するようになります。

3.3. Automation Controller の設定

RPM インストールプログラムを使用した後、Egress プロキシーを使用するように Automation Controller を設定する必要があります。

注記

これはコンテナーインストーラーでは必要ありません。podman はシステムで設定されたプロキシーを使用し、すべてのコンテナートラフィックをプロキシーにリダイレクトするためです。

Automation Controller の場合は、/api/v2/settings/AWX_TASK_ENV 変数を設定します。UI からこれを行うには、次の手順を使用します。

手順

  1. ナビゲーションパネルから、SettingsAutomation ExecutionJob を選択します。
  2. Edit をクリックします。
  3. 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"
                    }
    Copy to Clipboard Toggle word wrap

RPM ベースの Ansible Automation Platform の次の手順では、プロキシーサーバーで動作するために SSH プロトコルを使用して Automation Controller Project Sync を使用する方法を説明します。

手順

  1. Automation Controller ノードで次の手順を実行します。ansible-builder がまだインストールされていない場合は、まずインストールしてください。

    # subscription-manager repos --enable ansible-automation-platform-2.5-for-rhel-8-x86_64-rpms
    # dnf install ansible-builder
    Copy to Clipboard Toggle word wrap
  2. カスタム実行環境を構築します。

    1. まず、作業ディレクトリーを作成します。

      # su - awx
      $ mkdir -p builder/newee
      $ cd builder/newee
      Copy to Clipboard Toggle word wrap
  3. 次の内容を含む execution-environment.yml ファイルを作成します。

    version: 1
    
    build_arg_defaults:
      EE_BASE_IMAGE: 'registry.redhat.io/ansible-automation-platform-24/ee-supported-rhel8:latest'
    
    additional_build_steps:
      prepend:
        - RUN microdnf install -y nc
    Copy to Clipboard Toggle word wrap
  4. registry.redhat.io にログインします。

    $ podman login registry.redhat.io
    Copy to Clipboard Toggle word wrap
  5. ansible-builder を実行してビルドプロセスを開始します。

    $ cd /var/lib/awx/builder/newee/
    $ ansible-builder build -t my-env -v 3
    Copy to Clipboard Toggle word wrap
  6. 作成したカスタム実行環境を追加します。
  7. ナビゲーションパネルから、Automation ExecutionInfrastructureExecution Environments を選択します。
  8. Create execution environment をクリックします。
  9. Image フィールドに localhost/my-env:latest を追加します。
  10. Create execution environment をクリックします。
  11. 次の手順に従って Ansible Automation Platform インストールプログラムを再実行し、実行環境をデフォルトから、プロジェクトの同期に使用されるカスタマイズされた環境に置き換えます。

    注記

    インストールプログラムを実行する前に、Ansible Automation Platform をバックアップしてください。

    # ./setup.sh -b
    Copy to Clipboard Toggle word wrap
  12. setup.sh ファイルと同じ場所の group_vars ディレクトリーの下に、automationcontroller ファイルを作成します。ファイルの内容は次のとおりです。

    control_plane_execution_environment: localhost/my-env
    Copy to Clipboard Toggle word wrap
  13. setup.sh を実行します。

    # ./setup.sh
    Copy to Clipboard Toggle word wrap
  14. ディレクトリーの下に ssh_config を作成します。以下に例を示します。

    Host github.com
    Hostname ssh.github.com
    ProxyCommand nc --proxy-type http --proxy proxy.example.com:port %h %p
    User git
    Copy to Clipboard Toggle word wrap
  15. コンテナー実行環境が ssh_config ファイルを読み取ることができるように、分離されたジョブを公開するには、PATH に ssh_config ファイルのディレクトリーパスを追加します。
  16. ナビゲーションパネルで、SettingsAutomation ExecutionJob を選択します。
  17. Edit をクリックします。
  18. 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"
    ]
    Copy to Clipboard Toggle word wrap

3.4. AWS インベントリーを同期するための設定可能なプロキシー環境の有効化

AWS インベントリーを同期するために設定可能なプロキシー環境を有効にするには、オーバーライド設定ファイルを手動で編集するか、プラットフォーム UI で設定を指定します。

  1. /usr/lib/systemd/system/receptor.service.d/override.conf を手動で編集し、次の http_proxy 環境変数を追加します。

    http_proxy:<value>
    https_proxy:<value>
    proxy_username:<value>
    Proxy_password:<value>
    Copy to Clipboard Toggle word wrap

    または、以下を実行します。

  2. UI からこれを行うには、次の手順を使用します。

手順

  1. ナビゲーションパネルから、SettingsAutomation ExecutionJob を選択します。
  2. Edit をクリックします。
  3. 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/"
                },
Copy to Clipboard Toggle word wrap

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.com
    Copy to Clipboard Toggle word wrap

手順

  1. Ansible Automation Platform にログインします。
  2. ナビゲーションパネルから、Automation ContentRemotes を選択します。
  3. Community リモートの Details タブで、Edit remote をクリックします。
  4. YAML requirements フィールドに、requirements.yml ファイルの内容を貼り付けます。
  5. Save remote をクリックします。

結果

requirements.yml ファイルで識別されたコレクションを、Ansible Galaxy から Private Automation Hub に同期できるようになりました。

次のステップ

同期の手順については、Automation Hub での Ansible Content Collections の同期 を参照してください。

3.6. Event-Driven Ansible でのプロキシーの設定

Event-Driven Ansible の場合、プロキシーを設定するためのグローバル設定はありません。プロジェクトごとにプロキシーを指定する必要があります。

手順

  1. ナビゲーションパネルから、Automation DecisionsProjects を選択します。
  2. Create Project をクリックします。

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
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

4.2.2. grpc_settings.py ファイルの変更による影響

gRPC サーバーは、さまざまなプラットフォームサービス間の認証を支援する役割を担います。grpc_settings.py ファイルの設定を変更すると、特に接続の安定性に関して、gRPC 接続の動作とパフォーマンスに大きな影響を与える可能性があります。

gRPC サーバーを期待どおりに機能させるために、gRPC 設定に加えた変更を実稼働環境にデプロイする前に徹底的にテストすることが重要です。

4.3. 設定の読み込み順序

プラットフォームゲートウェイは、アプリケーション設定を管理するために Dynaconf ライブラリーを利用します。Dynaconf では階層化された設定アプローチが採用されています。このアプローチでは、設定が一定の順序で複数のソースから読み込まれ、後のソースが前のソースをオーバーライドします。Ansible Automation Platform は、次の順序で設定を読み込みます。

  1. アプリケーションの settings.py: このファイルはアプリケーション自体にあり、追加の設定ファイルの読み込み順序と場所を定義します。
  2. アプリケーションのデフォルト設定: プラットフォームは、アプリケーション自体の一部である defaults.py ファイルからデフォルト設定を読み込みます。このファイルには、API サーバーと gRPC サーバーの両方の一般的な設定が含まれています。
  3. お客様のオーバーライドファイル: /etc/ansible-automation-platform/gateway/settings.py ファイルは、自動的にインストールされ、defaults.py 内の任意の設定をオーバーライドするために使用できます。このファイルへの変更は、API サーバーと gRPC サーバーの両方に影響します。
  4. アプリケーションの gRPC デフォルト設定: お客様オーバーライドファイルの後、アプリケーションは grpc_default.py ファイルからのみ gRPC サーバーの追加のデフォルト設定を読み込みます。具体的には、このファイルには、キープアライブパラメーターなど、gRPC サーバーのデータベースオプションが含まれています。
  5. お客様の gRPC オーバーライドファイル: /etc/ansible-automation-platform/gateway/grpc_settings.py ファイル (存在する場合) が次に読み込まれます。このファイルに含まれる設定は gRPC サーバーにのみ適用されます。
  6. プラットフォームのオーバーライド設定ファイル: /etc/ansible-automation-platform/settings.py ファイル内のすべての設定が、gRPC サーバーと API サーバーの両方に適用されます。1 つのノードに複数の Ansible Automation Platform サービスがある場合、このファイル内の項目がすべてのサービスに適用されます。
  7. 環境変数: 設定ファイルの外部で特定の 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 がデータを収集する方法を、SettingsAutomation ExecutionSystem メニューから制御できます。

手順

  1. Automation Controller にログインします。
  2. ナビゲーションパネルから、SettingsAutomation ExecutionSystem を選択します。
  3. 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 証明書と鍵を更新する方法を説明します。

手順

  1. 証明書と鍵を準備するには、次のいずれかの方法を選択します。

    • カスタム証明書を提供する方法 - 更新された TLS 証明書を必要とするサービスごとに、新しい証明書と鍵を Ansible Automation Platform インストーラーを基準とした相対パスにコピーします。次に、新しいファイルへの絶対パスでインベントリーファイル変数を更新します。

      # Platform gateway
      gateway_tls_cert=<path_to_tls_certificate>
      gateway_tls_key=<path_to_tls_key>
      gateway_pg_tls_cert=<path_to_tls_certificate>
      gateway_pg_tls_key=<path_to_tls_key>
      gateway_redis_tls_cert=<path_to_tls_certificate>
      gateway_redis_tls_key=<path_to_tls_key>
      
      # Automation controller
      controller_tls_cert=<path_to_tls_certificate>
      controller_tls_key=<path_to_tls_key>
      controller_pg_tls_cert=<path_to_tls_certificate>
      controller_pg_tls_key=<path_to_tls_key>
      
      # Automation hub
      hub_tls_cert=<path_to_tls_certificate>
      hub_tls_key=<path_to_tls_key>
      hub_pg_tls_cert=<path_to_tls_certificate>
      hub_pg_tls_key=<path_to_tls_key>
      
      # Event-Driven Ansible
      eda_tls_cert=<path_to_tls_certificate>
      eda_tls_key=<path_to_tls_key>
      eda_pg_tls_cert=<path_to_tls_certificate>
      eda_pg_tls_key=<path_to_tls_key>
      eda_redis_tls_cert=<path_to_tls_certificate>
      eda_redis_tls_key=<path_to_tls_key>
      
      # PostgreSQL
      postgresql_tls_cert=<path_to_tls_certificate>
      postgresql_tls_key=<path_to_tls_key>
      
      # Receptor
      receptor_tls_cert=<path_to_tls_certificate>
      receptor_tls_key=<path_to_tls_key>
      Copy to Clipboard Toggle word wrap
    • 新しい証明書を生成する方法 - インストールプログラムでサービスの新しい証明書を生成する場合は、既存の証明書と鍵を削除または移動します。

      Expand
      表6.1 サービスごとの証明書と鍵ファイルのパス
      サービス証明書ファイルのパス鍵ファイルパス

      Automation Controller

      ~/aap/controller/etc/tower.cert

      ~/aap/controller/etc/tower.key

      Event-Driven Ansible

      ~/aap/eda/etc/eda.cert

      ~/aap/eda/etc/eda.key

      Platform gateway

      ~/aap/gateway/etc/gateway.cert

      ~/aap/gateway/etc/gateway.key

      Automation Hub

      ~/aap/hub/etc/pulp.cert

      ~/aap/hub/etc/pulp.key

      PostgreSQL

      ~/aap/postgresql/server.crt

      ~/aap/postgresql/server.key

      Receptor

      ~/aap/receptor/etc/receptor.crt

      ~/aap/receptor/etc/receptor.key

      Redis

      ~/aap/redis/server.crt

      ~/aap/redis/server.key

  2. 証明書を準備したら、インストールディレクトリーから install Playbook を実行します。

    ansible-playbook -i <inventory_file_name> ansible.containerized_installer.install
    Copy to Clipboard Toggle word wrap

検証

サービスが実行中でありアクセス可能であることをチェックして、新しい TLS 証明書が使用されていることを確認します。これを行うには、curl を使用して特定のエンドポイントを確認します。

$ curl -vk https://<hostname_or_ip>:<port_number>/api/v2/
Copy to Clipboard Toggle word wrap

このコマンドの出力には、TLS ハンドシェイクの詳細が示されます。正しい証明書が使用されていることを確認するには、次の出力を探します。

*  SSL certificate verify OK
Copy to Clipboard Toggle word wrap

6.2. Operator ベースのインストール

6.2.1. OpenShift Container Platform 上の Automation Controller の SSL 証明書と鍵の変更

次の手順では、OpenShift Container Platform で実行されている Automation Controller の SSL 証明書と鍵を変更する方法を説明します。

手順

  1. 署名された SSL 証明書と鍵をセキュアな場所にコピーします。
  2. OpenShift 内に TLS シークレットを作成します。

    oc create secret tls ${CONTROLLER_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.key
    Copy to Clipboard Toggle word wrap
  3. Automation Controller のカスタムリソースを変更して、route_tls_secret と新しいシークレットの名前を spec セクションに追加します。

    oc edit automationcontroller/${CONTROLLER_INSTANCE}
    Copy to Clipboard Toggle word wrap
    ...
    spec:
      route_tls_secret: automation-controller-certs-2023-04-06
    ...
    Copy to Clipboard Toggle word wrap

TLS シークレットの名前は任意です。この例では、Automation Controller インスタンスに適用される他の TLS シークレットと区別するために、シークレットを作成した日付のタイムスタンプが付けられています。

  1. 変更が適用されるまで数分待ちます。
  2. 新しい SSL 証明書と鍵がインストールされていることを確認します。

    true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443
    Copy to Clipboard Toggle word wrap

6.2.2. OpenShift Container Platform 上の Automation Hub の SSL 証明書と鍵を変更する

次の手順では、OpenShift Container Platform で実行されている Automation Hub の SSL 証明書と鍵を変更する方法を説明します。

手順

  1. 署名された SSL 証明書と鍵をセキュアな場所にコピーします。
  2. OpenShift 内に TLS シークレットを作成します。

    oc create secret tls ${AUTOMATION_HUB_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.key
    Copy to Clipboard Toggle word wrap
  3. Automation Hub のカスタムリソースを変更して、route_tls_secret と新しいシークレットの名前を spec セクションに追加します。

    oc edit automationhub/${AUTOMATION_HUB_INSTANCE}
    Copy to Clipboard Toggle word wrap
    ...
    spec:
      route_tls_secret: automation-hub-certs-2023-04-06
    ...
    Copy to Clipboard Toggle word wrap

TLS シークレットの名前は任意です。この例では、Automation Hub インスタンスに適用される他の TLS シークレットと区別するために、シークレットを作成した日付のタイムスタンプが付けられています。

  1. 変更が適用されるまで数分待ちます。
  2. 新しい SSL 証明書と鍵がインストールされていることを確認します。

    true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443
    Copy to Clipboard Toggle word wrap

6.3. RPM ベースのインストール

RPM ベースのインストールの SSL 証明書を更新または変更するには、インベントリーファイルを編集してインストールプログラムを実行します。インストールプログラムは、すべての Ansible Automation Platform コンポーネントが動作していることを確認します。

または、SSL 証明書を手動で変更することもできます。こちらのほうが迅速ですが、自動確認は行われません。

Red Hat では、Ansible Automation Platform デプロイメントに変更を加える際にはインストールプログラムを使用することを推奨しています。

6.3.1. 自己署名 SSL/TLS 証明書の更新

次の手順では、すべての Ansible Automation Platform コンポーネントの新しい SSL/TLS 証明書を再生成します。

手順

  1. aap_service_regen_cert=true をインベントリーファイルの [all:vars] セクションに追加します。

    [all:vars]
    aap_service_regen_cert=true
    Copy to Clipboard Toggle word wrap
  2. インストーラーを実行します。

検証

  • 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
    Copy to Clipboard Toggle word wrap
  • 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
    Copy to Clipboard Toggle word wrap
  • 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
    Copy to Clipboard Toggle word wrap
  • Automation Controller で CA ファイルと証明書ファイルを検証します。

    openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/tower/tower.cert
    openssl s_client -connect <CONTROLLER_FQDN>:443
    Copy to Clipboard Toggle word wrap

6.3.2. インストールプログラムを使用した SSL/TLS 証明書および鍵の変更

次の手順では、インベントリーファイル内の SSL/TLS 証明書と鍵を変更する方法を説明します。

前提条件

  • 証明書は PEM 形式である必要があります。
  • 中間認証局がある場合は、それをサーバー証明書に追加する必要があります。
  • 正しい証明書の順序を使用してください。最初にサーバー証明書を指定し、その後に中間認証局を指定します。

詳細は、NGINX ドキュメントの SSL 証明書のセクション を参照してください。

手順

  1. 新しい SSL/TLS 証明書と鍵を Ansible Automation Platform インストーラーに関連するパスにコピーします。
  2. SSL/TLS 証明書と鍵の絶対パスをインベントリーファイルに追加します。これらの 変数の設定に関するガイダンスは、インベントリーファイル 変数 を参照してください。

    • Event-Driven Ansible controller: automationedacontroller_ssl_certautomationedacontroller_ssl_keycustom_ca_cert
    • Platform gateway: automationgateway_ssl_certautomationgateway_ssl_keycustom_ca_cert
    • Automation Hub: automationhub_ssl_certautomationhub_ssl_keycustom_ca_cert
    • Automation Controller: web_server_ssl_certweb_server_ssl_keycustom_ca_cert

      注記

      custom_ca_cert は、中間認証局に署名したルート認証局である必要があります。このファイルは /etc/pki/ca-trust/source/anchors にインストールされます。

  3. インストールプログラムを実行します。

6.3.3. SSL/TLS 証明書および鍵の手動変更

次の手順では、すべての Ansible Automation Platform コンポーネントの SSL/TLS 証明書と鍵を手動で変更する方法を説明します。

手順

  1. 現在の SSL/TLS 証明書をバックアップします。

    cp <CERT_PATH> <CERT_PATH>-$(date +%F)
    Copy to Clipboard Toggle word wrap
  2. 現在の鍵ファイルをバックアップします。

    cp <KEY_PATH> <KEY_PATH>-$(date +%F)
    Copy to Clipboard Toggle word wrap
  3. 新しい SSL/TLS 証明書を証明書パスにコピーします。
  4. 新しい鍵を鍵パスにコピーします。
  5. SELinux コンテキストを復元します。

    restorecon -v <CERT_PATH> <KEY_PATH>
    Copy to Clipboard Toggle word wrap
  6. 証明書と鍵ファイルに適切なパーミッションを設定します。

    chown <OWNER>:<GROUP> <CERT_PATH> <KEY_PATH>
    chmod 0600 <CERT_PATH> <KEY_PATH>
    Copy to Clipboard Toggle word wrap
  7. NGINX 設定をテストします。

    nginx -t
    Copy to Clipboard Toggle word wrap
  8. NGINX をリロードします。

    systemctl reload nginx.service
    Copy to Clipboard Toggle word wrap
  9. 新しい SSL/TLS 証明書と鍵がインストールされていることを確認します。

    true | openssl s_client -showcerts -connect <COMPONENT_FQDN>:443
    Copy to Clipboard Toggle word wrap
    Expand
    表6.2 サービスごとの SSL/TLS 証明書と鍵ファイルのパス
    サービス証明書ファイルのパス鍵ファイルパス所有者: グループ

    Automation Controller

    /etc/tower/tower.cert

    /etc/tower/tower.key

    root:awx

    Automation Hub

    /etc/pulp/certs/pulp_webserver.crt

    /etc/pulp/certs/pulp_webserver.key

    root:pulp

    Event-Driven Ansible Controller

    /etc/ansible-automation-platform/eda/server.cert

    /etc/ansible-automation-platform/eda/server.key

    root:eda

    Platform gateway

    /etc/ansible-automation-platform/gateway/gateway.cert

    /etc/ansible-automation-platform/gateway/gateway.key

    root:gateway

法律上の通知

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る