Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

RPM によるアップグレードと移行

Red Hat Ansible Automation Platform 2.5

Ansible Automation Platform のレガシーデプロイメントのアップグレードと移行

Red Hat Customer Content Services

概要

このガイドでは、Ansible Automation Platform の最新バージョンにアップグレードし、レガシー仮想環境をオートメーション実行環境に移行する方法を説明します。

Red Hat ドキュメントへのフィードバック (英語のみ)
リンクのコピー

このドキュメントの改善に関するご意見がある場合や、エラーを発見した場合は、https://access.redhat.com から Technical Support チームに連絡してください。

第1章 Red Hat Ansible Automation Platform 2.5 のアップグレード
リンクのコピー

1.1. Ansible Automation Platform のアップグレード
リンクのコピー

現在、Ansible Automation Platform のアップグレードは、サポートされている次のいずれかのアップグレードパスを使用して実行できます。

重要

Event-Driven Ansible 2.4 からのアップグレードはサポートされていません。Ansible Automation Platform 2.4 から 2.5 にアップグレードし、イベント駆動型 Ansible をデプロイしている場合は、最初にイベント駆動型 Ansible 2.4 データベースを削除してから、プラットフォームを 2.5 にアップグレードする必要があります。手順の詳細は、Event-Driven Ansible 2.4 データベースの削除 を参照してください。

アップグレードを開始する前に、このガイドの前提条件とアップグレード計画のセクションを必ず確認してください。

Expand

サポート対象のアップグレードパス

アップグレードの手順

Ansible Automation Platform 2.4 から 2.5

インストールパッケージをダウンロード します。

インストール環境に合わせて インベントリーファイルを設定 します。テスト済みのデプロイメントモデル でサンプルのインベントリーファイルのリストを参照してください。

Ansible Automation Platform インスタンスをバックアップ します。

Event-Driven Ansible をデプロイした場合は、Event-Driven Ansible 2.4 データベースを削除 します。

現在の Ansible Automation Platform インスタンスで 2.5 インストールプログラムを実行 します。

既存のサービスレベルアカウントを 1 つの統合プラットフォームアカウントにリンク します。

Ansible Automation Platform 2.5 から 2.5.x

インストールパッケージをダウンロード します。

インストール環境に合わせて インベントリーファイルを設定 します。テスト済みのデプロイメントモデル でサンプルのインベントリーファイルのリストを参照してください。

Ansible Automation Platform インスタンスをバックアップ します。

現在の Ansible Automation Platform インスタンスで 2.5 インストールプログラムを実行 します。

Automation Controller および Automation Hub 2.4 と Event-Driven Ansible 2.5 および統合 UI のアップグレード

2.4 のサービスをアップグレードし (インベントリーファイルを使用して Automation Controller および Automation Hub 仮想マシンのみを指定)、AAP 2.5 の初期バージョンにします。

すべてのサービスが同じバージョンになったら、すべてのサービスで 2.5 のアップグレードを実行します。

第2章 Red Hat Ansible Automation Platform 2.5 へのアップグレード
リンクのコピー

Red Hat Ansible Automation Platform をアップグレードするには、アップグレードを正常に実行するため、最初に インストール計画 を確認してください。次に、必要なバージョンの Ansible Automation Platform インストーラーをダウンロードし、環境を反映するようにインストールバンドル内のインベントリーファイルを設定してから、インストーラーを実行できます。

2.1. 前提条件
リンクのコピー

  • Ansible Automation Platform 2.5 へのアップグレードには、プラットフォームゲートウェイ が含まれます。2.5 のネットワークポートとプロトコル でアーキテクチャーの変更点を、テスト済みのデプロイメントモデル で事前設定済みのデプロイメントモデルに関する情報を必ず確認してください。
  • Ansible Automation Platform によって提供される、スタンドアロントポロジーとクラスタートポロジーの 集中型の Redis インスタンスを確認してください。
  • Red Hat Ansible Automation Platform をアップグレードする前に、アップグレードを正常に実行するために、インストールの計画 を確認してください。次に、必要なバージョンの Ansible Automation Platform インストーラーをダウンロードし、環境を反映するようにインストールバンドル内のインベントリーファイルを設定してから、インストーラーを実行できます。
  • Red Hat Ansible Automation Platform をアップグレードする前に、必ず Automation Controller 4.5 以降にアップグレードしてください。
  • Ansible Automation Platform 2.5 にアップグレードする場合は、RPM インストーラーバージョン 2.5-11 以降を使用する必要があります。古いインストーラーを使用すると、インストールが失敗する可能性があります。古いバージョンのインストーラーを使用してインストールに失敗した場合は、RPM インストーラーバージョン 2.5-11 以降を使用してインストールを再実行してください。

2.2. Ansible Automation Platform のアップグレード計画
リンクのコピー

アップグレードプロセスを開始する前に、以下の考慮事項を確認して、Ansible Automation Platform デプロイメントを計画し、準備してください。

  • 「インストール計画」ガイドの システム要件 を参照して、ユースケースに適したトポロジーを使用していることを確認してください。

    注記

    2.4 から 2.5 へのアップグレードには、プラットフォームゲートウェイ が含まれます。2.5 の ネットワークポートとプロトコル でアーキテクチャーの変更点を必ず確認してください。

    重要

    Ansible Automation Platform 2.4 から 2.5 にアップグレードした場合は、Automation Controller、Automation Hub、および Event-Driven Ansible Controller の API エンドポイントをすべて使用できます。これらの API は非推奨になり、今後のリリースで無効になる予定です。現在の猶予期間は、プラットフォームゲートウェイとともに導入された新しい API への移行を可能にするためのものです。

  • 以前のバージョンの Ansible Automation Platform からアップグレードする前に、有効なサブスクリプションがあることを確認してください。既存のサブスクリプションは、アップグレードプロセス中に引き継がれます。
  • 問題が発生した場合に備えて、アップグレードする前に Ansible Automation Platform 2.4 環境のバックアップがあることを確認してください。環境の特定のトポロジーは、バックアップおよび復元 および Operator 環境のバックアップとリカバリー を参照してください。
  • アップグレードする前に、インベントリーまたはインスタンスグループの詳細を必ずキャプチャーしてください。
  • Red Hat Ansible Automation Platform をアップグレードする前に、必ず Ansible Automation Platform 2.4 の最新バージョンにアップグレードしてください。
  • イベント駆動型 Ansible 2.4 から 2.5 へのアップグレードはサポートされていません。Event-Driven Ansible 2.4 と Event-Driven Ansible 2.5 間のデータベース移行には互換性がありません。Ansible Automation Platform 2.4 から 2.5 にアップグレードし、イベント駆動型 Ansible をデプロイしている場合は、最初にイベント駆動型 Ansible 2.4 データベースを削除してから、プラットフォームを 2.5 にアップグレードする必要があります。手順の詳細は、Event-Driven Ansible 2.4 データベースの削除 を参照してください。
  • 現在 Event-Driven Ansible Controller 2.5 を実行している場合は、アップグレードプロセスの完了後に新しいアクティベーションのみが実行されるように、アップグレード前にすべての Event-Driven Ansible アクティベーションを無効にすることを推奨します。詳細は、Automation Controller および Automation Hub 2.4 と Event-Driven Ansible 2.5 および統合 UI のアップグレード を参照してください。
  • プラットフォーム UI 上の Automation Controller OAuth アプリケーションは、2.4 から 2.5 に移行できません。詳細は、こちらの ナレッジベースの記事 を参照してください。「アクセス管理と認証」ガイドの アプリケーション を参照して、OAuth アプリケーションを再作成する方法を確認してください。
  • アップグレードプロセス中に、各サービスのユーザーアカウントが移行されます。複数のサービスのアカウントがある場合は、統合プラットフォームにアクセスするために、それらをリンクする必要があります。詳細は、アカウントのリンク を参照してください。
  • Ansible Automation Platform 2.5 は、スタンドアロン トポロジーと クラスター トポロジーの両方で、集中型の Redis インスタンスを提供します。Redis の設定方法は、「RPM インストール」ガイドの Redis の設定 を参照してください。

  • Ansible Automation Platform 2.4 から 2.5 にアップグレードする場合、ロードバランサーの後で Automation Controller を使用していると、プラットフォームゲートウェイ UI でプラットフォームゲートウェイ URL への接続が失敗する可能性があります。エラーメッセージ Error connecting to Controller API が表示されます。

    この問題を解決するには、各コントローラーホストの settings.py ファイルで、CSRF_TRUSTED_ORIGIN 設定にプラットフォームゲートウェイ URL を信頼済みソースとして追加します。その後、URL の変更が実装されるように、各コントローラーホストを再起動する必要があります。詳細は、Ansible Automation Platform のトラブルシューティング の アップグレード を参照してください。

2.3. Red Hat Ansible Automation Platform インストーラーの選択および取得
リンクのコピー

Red Hat Enterprise Linux 環境のインターネット接続に基づいて、必要な Ansible Automation Platform インストーラーを選択します。以下のシナリオを確認し、ニーズを満たす Red Hat Ansible Automation Platform インストーラーを決定してください。

注記

Red Hat カスタマーポータルで Red Hat Ansible Automation Platform インストーラーのダウンロードにアクセスするには、有効な Red Hat カスタマーアカウントが必要です。

Red Hat Enterprise Linux 環境がインターネットに接続している場合は、Ansible Automation Platform インストーラーを選択します。インターネットアクセスを使用してインストールすると、必要な最新のリポジトリー、パッケージ、および依存関係を取得します。Ansible Automation Platform インストーラーをセットアップするには、次のいずれかの方法を選択します。

手順

  • tarball インストール

    1. Red Hat Ansible Automation Platform のダウンロード ページに移動します。
    2. Product software タブで、Ansible Automation Platform <latest-version> Setup の Download Now をクリックします。

    3. ファイルを展開します。 

      $ tar xvzf ansible-automation-platform-setup-<latest-version>.tar.gz

  • RPM インストール

    1. Ansible Automation Platform インストーラーパッケージをインストールします。

      v.2.5 for RHEL 8 for x86_64: 

      $ sudo dnf install --enablerepo=ansible-automation-platform-2.5-for-rhel-8-x86_64-rpms ansible-automation-platform-installer

      v.2.5 for RHEL 9 for x86-64: 

      $ sudo dnf install --enablerepo=ansible-automation-platform-2.5-for-rhel-9-x86_64-rpms ansible-automation-platform-installer
      注記

      dnf install は、リポジトリーがデフォルトで無効になっているため、リポジトリーを有効にします。

      RPM インストーラーを使用すると、ファイルは /opt/ansible-automation-platform/installer ディレクトリーに置かれます。

2.3.1. インターネットアクセスがない場合のインストール
リンクのコピー

インターネットにアクセスできない場合や、オンラインリポジトリーから個別のコンポーネントおよび依存関係をインストールしたくない場合は、Red Hat Ansible Automation Platform の Bundle インストーラーを使用します。Red Hat Enterprise Linux リポジトリーへのアクセスは依然として必要です。その他の依存関係はすべて tar アーカイブに含まれています。

手順

  1. Red Hat Ansible Automation Platform のダウンロード ページに移動します。
  2. Product software タブで、Ansible Automation Platform <latest-version> Setup Bundle の Download Now をクリックします。

  3. ファイルを展開します。 

    $ tar xvzf ansible-automation-platform-setup-bundle-<latest-version>.tar.gz

2.4. インベントリーファイルの設定
リンクのコピー

Red Hat Ansible Automation Platform インストールをアップグレードする前に、希望の設定に一致するように inventory ファイルを編集します。既存の Ansible Automation Platform デプロイメントと同じパラメーターを維持するか、使用環境に合わせてパラメーターを変更できます。

サンプルのインベントリーファイルが Test topologies GitHub リポジトリーや テスト済みデプロイメントモデル ガイドにあります。

手順

  1. インストールプログラムディレクトリーに移動します。

    バンドルのインストーラー
    $ cd ansible-automation-platform-setup-bundle-2.5-4-x86_64
    オンラインインストーラー
    $ cd ansible-automation-platform-setup-2.5-4
  2. 編集する inventory ファイルを開きます。

  3. inventory ファイルを変更して、新規ノードのプロビジョニング、ノードまたはグループのプロビジョニング解除、および自動化ハブ API トークンのインポートまたは生成を行います。

    環境に変更を加えない場合は、既存の Ansible Automation Platform インストールからの同じ inventory ファイルを使用できます。

    注記

    ユーザーが別のノードから Ansible Automation Hub のコンテンツを同期およびインストールできるように、すべてのホストに、到達可能な IP アドレスまたは完全修飾ドメイン名 (FQDN) を指定してください。localhost は使用しないでください。localhost を使用している場合は、アップグレードがプリフライトチェックの一部として停止します。

  4. 次のように、インベントリー ファイル内の既存のノードの横に新しいノードを追加して、クラスターに新しいノードをプロビジョニングします。 

    [automationcontroller]
clusternode1.example.com
clusternode2.example.com
clusternode3.example.com

[all:vars]
admin_password='password'

pg_host='<host_name>'

pg_database='<database_name>'
pg_username='<your_username>'
pg_password='<your_password>'

2.5. Ansible Automation Platform インスタンスのバックアップ
リンクのコピー

backup_dest フラグを指定して .setup.sh スクリプトを実行し、既存の Ansible Automation Platform インスタンスをバックアップします。これにより、現在の環境のコンテンツと設定が保存されます。バックアップ操作を実行するホストにバックアップアーティファクトが送信される前に、圧縮フラグ use_archive_compression および use_db_compression を使用してバックアップアーティファクトを圧縮します。

手順

  1. Ansible Automation Platform のインストールディレクトリーに移動します。

  2. 以下の例に従って、./setup.sh スクリプトを実行します。 

    $ ./setup.sh -e 'backup_dest=/ansible/mybackup' -e
'use_archive_compression=true' 'use_db_compression=true' @credentials.yml -b

    詳細は以下のようになります。

    • backup_dest: バックアップを保存するディレクトリーを指定します。

    • use_archive_compression=true および use_db_compression=true: バックアップ操作を実行するホストにバックアップアーティファクトが送信される前に、アーティファクトを圧縮します。

      次の変数を使用して圧縮をカスタマイズできます。

      • ファイルシステム関連のバックアップファイルの圧縮をグローバルに制御する場合: use_archive_compression=true

      • ファイルシステム関連のバックアップファイルの圧縮をコンポーネントレベルで制御する場合: <componentName>_use_archive_compression

        以下に例を示します。

        • automationgateway_use_archive_compression=true
        • automationcontroller_use_archive_compression=true
        • automationhub_use_archive_compression=true
        • automationedacontroller_use_archive_compression=true
      • データベース関連のバックアップファイルの圧縮をグローバルに制御する場合: use_db_compression=true

      • データベース関連のバックアップファイルの圧縮をコンポーネントレベルで制御する場合: <componentName>_use_db_compression=true

        以下に例を示します。

        • automationgateway_use_db_compression=true
        • automationcontroller_use_db_compression=true
        • automationhub_use_db_compression=true

        • automationedacontroller_use_db_compression=true

          バックアップが成功すると、/ansible/mybackup/automation-platform-backup-<date/time>.tar.gz にバックアップファイルが作成されます。

2.6. Event-Driven Ansible 2.4 データベースの削除
リンクのコピー

Ansible Automation Platform 2.5 は、イベント駆動型 Ansible を除くすべてのコンポーネントの Ansible Automation Platform 2.4 環境からのアップグレードをサポートします。Event-Driven Ansible 2.4 と Event-Driven Ansible 2.5 間のデータベース移行には互換性がありません。

Ansible Automation Platform 2.4 から 2.5 にアップグレードする場合は、最初にイベント駆動型 Ansible 2.4 データベースを削除する必要があります。アップグレード後に、新しい Event-Driven Ansible 2.5 データベースが自動的に作成されます。その後、Automation Decisions (Event-Driven Ansible Controller) を Automation Execution (Automation Controller) に再接続して、ルールブックのアクティベーションを実行できます。

手順

  1. 古い Event-Driven Ansible 2.4 ホストをシャットダウンします。

  2. スーパーユーザー特権を持つユーザーでデータベースホストにログインします。

    # psql -h <hostname> -U <username>

  3. プロンプトが表示されたら、パスワードを入力します。

  4. 次のコマンドを使用して、既存の Event-Driven Ansible 2.4 データベースを削除します。

    DROP DATABASE automationedacontroller

  5. プロンプトが表示されたら、パスワードを再入力します。

次のステップ

  1. Ansible Automation Platform インストーラーのセットアップスクリプトを実行します。
  2. アップグレードが完了したら、Automation Decisions (Event-Driven Ansible controller) を Automation Execution (Automation Controller) に再接続して、ルールブックのアクティベーションを正常に実行します。

2.7. Red Hat Ansible Automation Platform インストーラー設定スクリプトの実行
リンクのコピー

inventory ファイルの更新が完了したら、設定スクリプトを実行できます。

手順

  • setup.sh スクリプトを実行します。 

    $ ./setup.sh

    インストールが開始します。

Ansible Automation Platform 2.5 は、Event-Driven Ansible を除くすべてのコンポーネントについて、Ansible Automation Platform 2.4 環境からのアップグレードをサポートしています。2.5 の Event-Driven Ansible をレガシーの 2.4 クラスターに接続して、混合環境を構成することもできます。このようなトポロジー内でインストール方法 (OCP、RPM、コンテナー) を組み合わせることは、Ansible Automation Platform ではサポートされていません。

注記

実稼働環境でバージョン 2.4 の Event-Driven Ansible を実行している場合は、アップグレードする前に、Red Hat のサポートまたはアカウント担当者に問い合わせて、Ansible Automation Platform 2.5 への移行方法の詳細を確認してください。

このドキュメントで説明されているサポート対象のトポロジーは、以下を前提としています。

  • 2.4 のサービスに含まれるのは、Automation Controller と Automation Hub だけです。
  • 2.5 の部分には、Event-Driven Ansible と統合 UI (プラットフォームゲートウェイ) が必ず含まれています。
  • これらのトポロジーのインストール方法を組み合わせることはサポートされていません。

2.8.1. アップグレードに関する考慮事項
リンクのコピー

  • 2.4 のサービス用と 2.5 のサービス用に 2 つの個別のインベントリーファイルを維持管理する必要があります。
  • このシナリオでは、2.4 サービス用と 2.5 サービス用の 2 つの個別のインストールを維持する必要があります。
  • 2 つの個別のインストールを別々にアップグレードする必要があります。

  • 一貫したコンポーネントバージョントポロジーにアップグレードするために、次の点を考慮してください。

    • 2.4 のインベントリーのインベントリーファイル設定を 2.5 のインベントリーに手動で結合し、2.5 のインベントリーファイルのみでアップグレードを実行する必要があります。
    • 2.4 のインベントリーと 2.5 のインベントリーの両方に、外部データベースを使用している必要があります。
    • 2.4 または 2.5 インベントリーに管理データベースインスタンスを使用している場合は、アップグレード前に最初に外部データベースに移行する必要があります。

2.8.2. マネージドデータベースを使用した 2.4 インスタンスの移行パスの使用
リンクのコピー

マネージドデータベースを使用する 2.4 インスタンスの移行パスがある場合は、この手順を使用します。

前提条件

  • Automation Controller および Automation Hub 用の 2.4 からのインベントリーと、統合 UI (プラットフォームゲートウェイ) および Event-Driven Ansible 用の 2.5 のインベントリー。まず、2.4 のサービスでアップグレードを実行し (インベントリーファイルを使用して Automation Controller および Automation Hub 仮想マシンのみを指定)、Ansible Automation Platform 2.5 の初期バージョンにする必要があります。すべてのサービスが同じバージョンになったら、すべてのサービスでアップグレードを (完全なインベントリーファイルを使用して) 実行し、Ansible Automation Platform 2.5 の最新バージョンに移行します。
重要

必ず先に個々のサービス (Automation Controller と Automation Hub) を Ansible Automation Platform 2.5 の初期バージョンにアップグレードしてから、Event-Driven Ansible と統合 UI (プラットフォームゲートウェイ) を Ansible Automation Platform 2.5 の最新バージョンにアップグレードしてください。

  • Red Hat Ansible Automation Platform をアップグレードする前に、必ず Ansible Automation Platform 2.4 の最新バージョンにアップグレードしてください。

手順

  • スタンドアロンノード管理データベースの場合

    • データベースノードを外部ノードに変換し、インベントリーから削除してください。PostgreSQL ノードは引き続き動作し、Ansible Automation Platform が提供するセットアップは失われません。ただし、その後の設定管理はユーザーの責任です。

  • 共存管理データベースの場合

    1. Back up
    2. 共存するマネージドデータベースノードではなく、スタンドアロンのマネージドデータベースノードを使用して復元します。
    3. 管理対象外のスタンドアロンデータベース

2.8.3. 2.5 サービスを使用した 2.4 サービスの移行パスの使用
リンクのコピー

Ansible Automation Platform 2.5 をインストールしてサポート対象のシナリオでイベント駆動型 Ansible を使用する場合は、このセクションの手順に従って、Ansible Automation Platform 2.4 Automation Controller と Automation Hub を Ansible Automation Platform 2.5 にアップグレードできます。

前提条件

  • Automation Controller および Automation Hub 用の 2.4 からのインベントリーと、統合 UI (プラットフォームゲートウェイ) および Event-Driven Ansible 用の 2.5 のインベントリー。まず、2.4 のサービスでアップグレードを実行し (インベントリーファイルを使用して Automation Controller および Automation Hub 仮想マシンのみを指定)、Ansible Automation Platform 2.5 の初期バージョンにする必要があります。すべてのサービスが同じバージョンになったら、すべてのサービスでアップグレードを (完全なインベントリーファイルを使用して) 実行し、Ansible Automation Platform 2.5 の最新バージョンに移行します。
重要

必ず先に個々のサービス (Automation Controller と Automation Hub) を Ansible Automation Platform 2.5 の初期バージョンにアップグレードしてから、Event-Driven Ansible と統合 UI (プラットフォームゲートウェイ) を Ansible Automation Platform 2.5 の最新バージョンにアップグレードしてください。

  • Red Hat Ansible Automation Platform をアップグレードする前に、必ず Ansible Automation Platform 2.4 の最新バージョンにアップグレードしてください。

手順

  1. 2.4 のインベントリーデータを 2.5 のインベントリーにマージします。

    以下の例では、2.4 の Automation Controller および Automation Hub のインベントリーファイルと、2.5 の Event-Driven Ansible および統合 UI (プラットフォームゲートウェイ) のインベントリーファイルをそれぞれ開始点として示し、マージしたインベントリーがどのようになるかを示します。

    2.4 のインベントリーファイル 

    [automationcontroller]
controller-1
controller-2

[automationhub]
hub-1
hub-2

[all:vars]
# Here we have the admin passwd, db credentials, etc.

    2.5 のインベントリーファイル 

    [edacontroller]
eda-1
eda-2

[gateway]
gw-1
gw-2

[all:vars]
# Here we have admin passwd, db credentials etc.

    マージしたインベントリー 

    [automationcontroller]
controller-1
controller-2

[automationhub]
hub-1
hub-2

[edacontroller]
eda-1
eda-2

[gateway]
gw-1
gw-2

[all:vars]
# Here we have admin passwd, db credentials etc from both inventories above

  2. setup.sh を実行します。

    インストーラーは、Automation Controller と Automation Hub を 2.4 から Ansible Automation Platform 2.5.latest、Event-Driven Ansible、Event-Driven Ansible、および統合 UI （プラットフォームゲートウェイ）から最新バージョンの 2.5 にアップグレードし、Automation Controller と Automation Hub を統一された UI （プラットフォームゲートウェイ）ノードと正しく接続して統合エクスペリエンスを初期化します。

検証

  • すべてが 2.5 にアップグレードされ、正常に動作していることを、次のどちらかの方法で確認します。

    • Automation Controller と Event-Driven Ansible への SSH を実行します。
    • 統合 UI で、Help > About に移動して、RPM バージョンが 2.5 であることを確認します。

第3章 Ansible Automation Platform のアップグレード後の手順
リンクのコピー

Ansible Automation Platform 2.5 へのアップグレードが成功したら、次の重要なステップは、ユーザーをプラットフォームの最新バージョンに移行することです。

Automation Controller と Private Automation Hub からのユーザーデータとレガシー認証設定は、アップグレードプロセス中に引き継がれます。これにより、アップグレード後にプラットフォームへのシームレスな初期アクセスが可能になります。お客様は追加の操作なしでログインできます。

ただし、認証を完全に移行して 2.5 プラットフォームゲートウェイのすべての機能を使用するには、アップグレード後に新しい認証フレームワークを活用するための手動プロセスが必要です。Ansible Automation Platform 2.5 へのアップグレードの文脈では、この手動プロセスは 移行 と呼ばれます。

以下を含むユーザー移行タイプごとに、重要な注記と考慮事項があります。

  • 管理者ユーザー
  • 通常ユーザー
  • SSO ユーザー
  • LDAP ユーザー

移行プロセスをできるだけスムーズに進めるために、各ユーザータイプごとに強調表示されている重要な注記を必ずお読みください。

3.1. 管理者ユーザーの移行に関する重要な考慮事項
リンクのコピー

Ansible Automation Platform 2.4 から 2.5 にアップグレードすると、各コンポーネントの管理者を、既存のコンポーネントレベルの管理者権限を保ったまま管理者を移行できます。ただし、アップグレードプロセス中にプラットフォームゲートウェイ管理者への権限昇格は自動的に行われません。これにより、組織の特定のニーズに合わせてカスタマイズできる安全な権限昇格プロセスが提供されます。

コンポーネントレベルの管理者権限は保持されます: Automation Controller と Automation Hub の管理者は、アップグレード後もそれぞれのサービスに対する既存の管理者権限を保持します。たとえば、Automation Controller の管理者は、Automation Controller リソースに対する完全な管理権限を引き続き保持します。

プラットフォームゲートウェイ管理者へのエスカレーションは、アップグレード後に手動で設定する必要があります。 アップグレードプロセス中、個々のサービスの管理者権限は、プラットフォーム管理者権限に自動的に変換されません。プラットフォーム管理者は、アップグレードおよび移行の後でプラットフォームゲートウェイ管理者へのエスカレーションを許可する必要があります。各サービス管理者は、アクセスが変更されるまで、アクセスの元のスコープを保持します。

プラットフォーム管理者は、Ansible Automation Platform Administrator チェックボックスを選択すると、ユーザーの権限昇格を実行できるようになります。特権を昇格できるのはプラットフォーム管理者のみです。

注記

以前に Automation Controller 管理者または Automation Hub 管理者として指定されたユーザーには、ユーザーリストビューの User type 列に Normal というラベルが付けられます。これは正しくありません。アカウントを編集すると、これらのユーザーが実際にはサービスレベル管理者権限を保持していることを確認できます。

3.2. 管理者ユーザーの移行
リンクのコピー

管理者ユーザーを移行するには、次の手順に従います。

前提条件

  • 現行デプロイメントにおける各サービスの現在の管理者ロールを確認する。
  • アップグレード後にプラットフォームゲートウェイの管理者権限を必要とするユーザーを確認する。

手順

  1. プラットフォームゲートウェイのナビゲーションパネルで、Access Management → Users を選択します。
  2. 変更するユーザーのチェックボックスをオンにします。
  3. 鉛筆アイコンをクリックし、Edit user を選択します。
  4. ユーザー編集ページが表示され、User type チェックボックスで割り当てられたサービスレベル管理者権限を確認できます。ユーザータイプの詳細は、ユーザーの編集 を参照してください。

3.3. 通常ユーザーの移行に関する重要な考慮事項
リンクのコピー

以前のサービスアカウントには接頭辞が付けられます: 2.4 で複数のサービスにアカウントを持つユーザーは、2.5 の個別ユーザーとして移行され、移行元のサービスを識別するための接頭辞が付けられます。たとえば、Automation Hub アカウントには hub_<username> という接頭辞が付きます。Automation Controller ユーザー名に接頭辞は含まれません。

Automation Controller ユーザーアカウントが優先されます: 1 つのユーザーが 2.4 で複数のサービスにアカウントを持っている場合、移行時に Automation Controller アカウントが優先されるため、名前は変更されません。

コンポーネントレベルのロールは、ユーザーの移行が完了するまで保持されます。 ユーザーが既存のサービスアカウントを使用してログインし、アカウントリンクプロセスを実行しない場合は、その特定のサービスアカウントのロールのみが使用可能になります。ユーザーがアカウントリンクプロセスを実行すると、移行プロセスが完了します。その時点で、すべてのサービスのすべてのロールが新しいプラットフォームゲートウェイのユーザーアカウントに移行されます。

3.4. 通常ユーザーの移行
リンクのコピー

Ansible Automation Platform 2.4 から 2.5 にアップグレードすると、既存のユーザーアカウントは単一のプラットフォームアカウントに自動的に移行されます。ただし、複数のコンポーネントアカウント (Automation Controller、Private Automation Hub、Event-Driven Ansible など) がある場合は、プラットフォームの一元化機能を使用するために、アカウントをリンクする必要があります。

3.4.2. アカウントのリンク
リンクのコピー

Ansible Automation Platform 2.5 では、ユーザー、チーム、組織が一元的な場所からプラットフォームのサービスと機能にアクセスできます。

Ansible Automation Platform 2.5 に初めてログインすると、既存のサービスが検索され、ユーザーが入力した認証情報を持つユーザーアカウントが特定されます。既存のアカウントと一致すると、そのアカウントは登録され、プラットフォームによって一元管理されるようになります。システム内のそれ以降のコンポーネントアカウントは、孤立してプラットフォームへのログインに使用できなくなります。

この問題を解決するには、アカウントリンク手順を使用して、既存のコンポーネントアカウントから認証し、プラットフォームによって引き続き認識されるようにします。アカウントをリンクすると、既存のコンポーネントアカウントが同じユーザープロファイルに関連付けられます。

アップグレードプロセスが完了し、従来の Ansible Automation Platform サブスクリプションをお持ちの場合は、以下のアカウントリンク手順に従って、アカウントを Ansible Automation Platform 2.5 に移行します。

前提条件

  • アップグレードプロセスが完了し、従来の Ansible Automation Platform アカウントと認証情報を取得した。

手順

  1. Ansible Automation Platform のログインページに移動します。
  2. ログインモーダルで、お持ちの認証情報に応じて、I have an automation controller account または I have an automation hub account を選択します。

  3. 次の画面で、選択したコンポーネントアカウントの従来の認証情報を入力し、Log in をクリックします。

    注記

    OIDC 認証情報を使用してログインしている場合は、How to fix broken OIDC redirect after upgrading to AAP 2.5 を参照してください。

  4. アカウントのリンクに成功すると、次の画面にユーザー名とその横に緑色のチェックマークが表示されます。リンクする必要がある従来のアカウントが他にもある場合は、そのアカウントの認証情報を入力し、Link をクリックして、一元化されたプラットフォームゲートウェイのアカウントにリンクします。
  5. Submit をクリックして、従来のアカウントのリンクを完了します。

  6. アカウントをリンクした後、認証方法に応じて、新しいユーザー名とパスワードを作成するように求められる場合があります。これらの認証情報によって、各コンポーネントアカウントの従来の認証情報が置き換えられます。

    • 以下の手順に従って、従来のアカウントを手動でリンクすることもできます。
  7. 画面右上のユーザーアイコンを選択し、User details を選択します。
  8. More Actions アイコン ⋮ > Link user accounts を選択します。
  9. リンクするアカウントの認証情報を入力します。

トラブルシューティング

アカウントを認証できなかったというエラーメッセージが表示された場合は、プラットフォーム管理者に問い合わせてください。

注記

Ansible Automation Platform に初めてログインしたときにユーザー名を変更するように求められた場合は、別のユーザーがすでに同じユーザー名で Ansible Automation Platform にログインしていることを示しています。アカウントの移行を続行するには、指示に従ってユーザー名を変更してください。Ansible Automation Platform は、パスワードを使用して、どのアカウントがユーザーに属しているかを認証します。

アカウントリンクのフロー図 Account linking flow

ユーザーアカウントを移行したら、Access Management メニューからアカウントを管理できます。ロールベースのアクセス制御によるアクセスの管理 を参照してください。

3.5. シングルサインオン (SSO) ユーザーの移行
リンクのコピー

Ansible Automation Platform 2.4 から 2.5 にアップグレードする場合、アップグレード後もシングルサインオン (SSO) 機能を引き続き使用するには、SSO ユーザーアカウントを移行する必要があります。SSO ユーザーをスムーズに移行するためには、次の手順で示すステップを実行します。

3.5.1. 主な考慮事項
リンクのコピー

SSO 設定は 2.5 へのアップグレード中に自動的に移行されません。 レガシー認証設定は、アップグレードプロセス中に引き継がれます。これにより、アップグレード後にプラットフォームへのシームレスな初期アクセスが可能になります。一方、SSO 設定は、新しい Ansible Automation Platform 2.5 認証設定に手動で移行する必要があります。レガシー設定は、既存の認証機能を保持し、移行プロセスを容易にするための参照先として機能します。移行が完了した後は、レガシー認証設定を直接変更したり使用したりしないでください。

UI で SSO の移行がサポートされています。 2.5 の UI では、レガシー SSO アカウントを移行できます。この移行を実行するには、新しい認証方法を設定するときに、Auto migrate users from リストからレガシーオーセンティケーターを選択します。このレガシーオーセンティケーターから、新しいプラットフォームゲートウェイ認証設定にユーザーを自動的に移行します。

SSO の移行は、ユーザーがログインしてアカウントのリンクを開始する前に行う必要があります。 2.5 で SSO を設定した後、ユーザーがログインする 前に、Auto migrate users to 設定を有効にする必要があります。

注記

Ansible Automation Platform 2.4 の SSO 設定は、アップグレードプロセス中に名前が変更され、レガシー設定を示す接頭辞付き (例: legacy_sso-saml-<entity id>) で Authentication Methods リストビューに表示されます。Authentication type も legacy sso としてリストされます。これらの設定は変更できません。

自動移行機能を設定すると、プラットフォームゲートウェイで SSO を使用してログインできるようになり、レガシー SSO オーセンティケーターからの一致するアカウントが自動的にリンクされます。

3.6. LDAP ユーザーの移行
リンクのコピー

Ansible Automation Platform 2.4 から 2.5 にアップグレードするプラットフォーム管理者は、アップグレード後に LDAP 認証機能を引き続き使用する場合、LDAP ユーザーアカウントを移行する必要があります。可能な限りスムーズに LDAP ユーザーを移行するために、この手順に従ってください。

レガシー認証システムから LDAP ベースの認証にユーザーを移行する手順は、主に 2 つあります。

  1. 従来のユーザーログインとアカウントのリンク
  2. アカウントをリンクせずに LDAP に移行する

3.6.1. 主な考慮事項
リンクのコピー

LDAP 設定は 2.5 へのアップグレード中に自動的に移行されません。 レガシー LDAP 認証設定は、アップグレードプロセス中に引き継がれます。これにより、アップグレード後にプラットフォームへのシームレスな初期アクセスが可能になります。一方、LDAP 設定は、新しい Ansible Automation Platform 2.5 の LDAP 設定に手動で移行する必要があります。レガシー設定は、既存の認証機能を保持し、移行プロセスを容易にするための参照先として機能します。移行が完了した後は、レガシー認証設定を直接変更したり使用したりしないでください。

UID 競合のリスク: LDAP とレガシーパスワードオーセンティケーターは、どちらもユーザー名を UID として使用します。これにより、ユーザー間または別々の人が所有する同じ名前のユーザー間で UID の競合が発生する可能性があります。UID の競合が原因で安全に自動移行できないユーザーアカウントは、適切に処理されるように手動で移行する必要があります。このようなユーザーは、自動移行を設定する前に、API /api/gateway/v1/authenticator_users/ を介して手動で移行できます。

アップグレード前にプラットフォームにユーザーアカウントがない場合は、レガシー LDAP 認証を使用してログインしないでください。 代わりに、アカウントをリンクせずに LDAP に直接自動移行 する必要があります。

3.6.2. 従来のユーザーログインとアカウントのリンク
リンクのコピー

ユーザーは、“I have a <component> account” を選択し、認証情報 (ユーザー名とパスワード) を入力することで、従来のアカウントを使用してログインできます。ログインが成功した場合、アカウントを別のコンポーネント (Automation Hub や Automation Controller など) のアカウントにリンクするように求められる場合があります。Automation Hub と Automation Controller の両方のログイン認証情報が同じ場合は、そのユーザーのアカウントリンクが自動的に実行されます。

アカウントのリンクが成功すると、両方のコンポーネントのユーザーアカウントが gateway:legacy external password オーセンティケーターに統合されます。ユーザーアカウントが gateway:legacy external password オーセンティケーターに自動的に統合されない場合は、アカウントをリンクせずに LDAP に直接自動移行する必要があります。

アカウントのリンクの詳細は、アカウントのリンク を参照してください。

3.6.3. アカウントをリンクせずに LDAP ユーザーを移行する
リンクのコピー

Automation Hub アカウントにリンクする方法がなく、ユーザーがアカウントをリンクできない場合は、すべてのレガシーパスワードオーセンティケーターで自動移行機能をすぐに設定して、新しいゲートウェイ LDAP オーセンティケーターをターゲットにする必要があります。

その後、ユーザーのログイン時に一致する UID が見つかった場合、プラットフォームゲートウェイが自動的にユーザーを LDAP オーセンティケーターに移行します。

前提条件

  • 自動移行を進める前に、従来のすべてのアカウントが適切にリンクおよび統合されていることを確認してください。
  • 自動移行を進める前に、UID の競合がないことを確認するか、必ずアカウントを手動で移行してください。

手順

  1. Ansible Automation Platform UI にログインします。

  2. LDAP 認証の設定 の手順に従って、プラットフォームゲートウェイで新しい LDAP 認証方法を設定します。これは、以前の LDAP ユーザーを移行する設定です。

    注記

    Ansible Automation Platform 2.4 の LDAP 設定は、アップグレードプロセス中に名前が変更され、レガシー設定であることを示す接頭辞付きで Authentication Methods リストビューに表示されます (例: <controller/hub/eda>: legacy_password)。Authentication type は Legacy password としてリストされます。これらの設定は変更できません。

  3. Auto migrate users from リストからレガシー LDAP オーセンティケーターを選択します。これは、ユーザーをプラットフォームゲートウェイ LDAP オーセンティケーターに移行するのに使用するレガシーオーセンティケーターです。

自動移行機能を設定すると、プラットフォームゲートウェイで LDAP を使用してログインできるようになり、2.4 のレガシー LDAP オーセンティケーターからの一致するアカウントが自動的にリンクされます。

法律上の通知
リンクのコピー

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

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

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

Legal Notice

Theme

© 2026 Red Hatトップに戻る