Red Hat Ansible Automation Platform のアップグレードおよび移行ガイド
最新バージョンの Ansible Automation Platform にアップグレードし、以前の仮想環境を自動化実行環境に移行
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
第1章 Red Hat Ansible Automation Platform 2.3 のアップグレード
インベントリーを設定し、インストールスクリプトを実行して Red Hat Ansible Automation Platform 2.3 にアップグレードします。その後、Ansible はデプロイメントを 2.3 にアップグレードします。Ansible Automation Platform 2.0 以前からアップグレードする場合は、2.3 との互換性を確保するために Ansible コンテンツを移行する必要があります。
1.1. Ansible Automation Platform のアップグレード
Ansible Automation Platform 2.1 以降からバージョン 2.3 にアップグレードするには、インストールパッケージをダウンロードしてから以下の手順を実行します。
- インストール環境に合わせてインベントリーを設定します。
- 現在の Ansible Automation Platform インストールで 2.3 インストールプログラムを実行します。
1.2. Ansible Automation Platform のレガシーアップグレード
Ansible Automation Platform 2.0 以前からバージョン 2.3 にアップグレードするには、互換性のために Ansible コンテンツを移行する必要があります。
以下の手順は、レガシーのアップグレードプロセスの概要を示しています。
-
awx-manageコマンドを使用して、カスタムの仮想環境を自動化実行環境に複製します。 - ノードが最新の自動化メッシュ機能と互換性を持つように、サイドバイサイドアップグレードを実行して、分離されたレガシーノードから実行ノードにデータを移行します。
- 新しい自動化ハブ API トークンをインポートまたは生成します。
-
ansible-core2.13 との互換性のために、完全修飾コレクション名 (FQCN) を組み込むように Ansible コンテンツを再設定します。
第2章 Red Hat Ansible Automation Platform 2.3 へのアップグレード
Red Hat Ansible Automation Platform をアップグレードするには、計画情報を確認してアップグレードが成功するようにします。次に、必要なバージョンの Ansible Automation Platform インストーラーをダウンロードし、環境を反映するようにインストールバンドル内のインベントリーファイルを設定してから、インストーラーを実行できます。
2.1. Ansible Automation Platform のアップグレード計画
アップグレードプロセスを開始する前に、以下の考慮事項を確認して、Ansible Automation Platform デプロイメントを計画し、準備してください。
Automation Controller
- 以前のバージョンから有効なライセンスがある場合でも、最新バージョンの自動化コントローラーにアップグレードする際に、認証情報またはサブスクリプションマニフェストを指定する必要があります。
- Red Hat Enterprise Linux および自動化コントローラーをアップグレードする必要がある場合は、まず自動化コントローラーデータをバックアップして復元する必要があります。
- クラスター形式のアップグレードでは、アップグレード前にインスタンスとインスタンスグループに特に留意が必要です。
Automation Hub
- Ansible Automation Platform 2.3 にアップグレードする場合は、既存の自動化ハブ API トークンを追加するか、新規作成して既存トークンを無効にできます。
関連情報
2.2. 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 (AAP) インストーラーを選択します。インターネットアクセスを使用してインストールすると、必要な最新のリポジトリー、パッケージ、および依存関係を取得します。AAP インストーラーを設定するには、以下のいずれかの方法を選択します。
tarball インストール
- Red Hat Ansible Automation Platform のダウンロード ページに移動します。
- Ansible Automation Platform <latest-version> Setup の Download Now をクリックします。
ファイルをデプロイメントします。
$ tar xvzf ansible-automation-platform-setup-<latest-version>.tar.gz
RPM インストール
Ansible Automation Platform インストーラーパッケージをインストールします。
v.2.3 for RHEL 8 for x86_64
$ sudo dnf install --enablerepo=ansible-automation-platform-2.3-for-rhel-8-x86_64-rpms ansible-automation-platform-installer
v.2.3 for RHEL 9 for x86-64
$ sudo dnf install --enablerepo=ansible-automation-platform-2.3-for-rhel-9-x86_64-rpms ansible-automation-platform-installer
dnf install は、リポジトリーがデフォルトで無効になっているため、リポジトリーを有効にします。
RPM インストーラーを使用すると、ファイルは /opt/ansible-automation-platform/installer ディレクトリーに置かれます。
インターネットアクセスなしでのインストール
インターネットにアクセスできない場合や、オンラインリポジトリーから個別のコンポーネントおよび依存関係をインストールしたくない場合は、Red Hat Ansible Automation Platform の Bundle インストーラーを使用します。Red Hat Enterprise Linux リポジトリーへのアクセスは依然として必要です。その他の依存関係はすべて tar アーカイブに含まれます。
- Red Hat Ansible Automation Platform のダウンロード ページに移動します。
- Ansible Automation Platform <latest-version> Setup Bundle の Download Now をクリックします。
ファイルをデプロイメントします。
$ tar xvzf ansible-automation-platform-setup-bundle-<latest-version>.tar.gz
2.3. インベントリーファイルの設定
Red Hat Ansible Automation Platform インストールをアップグレードする前に、希望の設定に一致するように inventory ファイルを編集します。既存の Ansible Automation Platform デプロイメントと同じパラメーターを維持するか、使用環境に合わせてパラメーターを変更できます。
手順
インストールプログラムディレクトリーに移動します。
- バンドルのインストーラー
$ cd ansible-automation-platform-setup-bundle-2.3-1.2
- オンラインインストーラー
$ cd ansible-automation-platform-setup-2.3-1.2
-
編集する
inventoryファイルを開きます。 inventoryファイルを変更して、新規ノードのプロビジョニング、ノードまたはグループのプロビジョニング解除、および自動化ハブ API トークンのインポートまたは生成を行います。環境に変更を加えない場合は、既存の Ansible Automation Platform 2.1 インストールから同じ
inventoryファイルを使用できます。注記[automationhub]および[automationcontroller]ホストに到達可能な IP アドレスまたは完全修飾ドメイン名 (FQDN) を提供して、ユーザーが別のノードの Ansible Automation Hub からコンテンツを同期してインストールできるようにします。localhostは使用しないでください。localhostを使用している場合は、アップグレードがプリフライトチェックの一部として停止します。
クラスター内での新規ノードのプロビジョニング
以下のように
inventoryファイルの既存ノードとともに新規ノードを追加します。[controller] clusternode1.example.com clusternode2.example.com clusternode3.example.com [all:vars] admin_password='password' pg_host='' pg_port='' pg_database='<database_name>' pg_username='<your_username>' pg_password='<your_password>'
クラスター内のノードまたはグループのプロビジョニング解除
-
inventoryファイルのノードまたはグループにnode_state-deprovisionを追加します。
API トークンのインポートと生成
Red Hat Ansible Automation Platform 2.0 以前から Red Hat Ansible Automation Platform 2.1 以降にアップグレードする場合、既存の Automation Hub API トークンを使用することも、新しいトークンを生成することもできます。インベントリーファイルで、Red Hat Ansible Automation Platform インストーラーのセットアップスクリプト setup.sh を実行する前に、以下のいずれかのフィールドを編集します。
以下のように
automationhub_api_tokenフラグを使用して既存の API トークンをインポートします。automationhub_api_token=<api_token>以下のように
generate_automationhub_tokenフラグを使用して、新しい API トークンを生成し、既存のトークンを無効にします。generate_automationhub_token=True
2.4. Red Hat Ansible Automation Platform インストーラー設定スクリプトの実行
inventory ファイルの更新が完了したら、設定スクリプトを実行できます。
手順
setup.shスクリプトを実行します。$ ./setup.sh
インストールが開始します。
第3章 自動化実行環境への移行
3.1. 自動化実行環境にアップグレードする理由
Red Hat Ansible Automation Platform 2.3 には、自動化実行環境が導入されています。自動化実行環境は、単一のコンテナー内で Ansible Automation を実行するために必要なすべてのものを含めることにより、Ansible の管理を容易にするコンテナーイメージです。自動化実行環境には、以下が含まれます。
- RHEL UBI 8
- Ansible 2.9 または Ansible Core 2.13
- Python 3.9 以降
- Ansible コンテンツコレクション
- Python またはバイナリーの依存関係のコレクション
これらの要素を含めることで、Ansible はプラットフォーム管理者は、自動化が実行される環境を標準化して定義、構築、および配布できるようになります。
新しい自動化実行環境により、管理者がカスタムプラグインや自動化コンテンツを作成する必要がなくなりました。管理者は、これまでよりも短時間で、サイズのより小さい自動化実行環境を起動できるようになります。
すべてのカスタム依存関係は、管理およびデプロイメントフェーズではなく、開発フェーズで定義されるようになりました。コントロールプレーンから分離することで、開発サイクルの高速化、スケーラビリティ、信頼性、および環境間での移植性が実現します。自動化実行環境により、Ansible Automation Platform を分散アーキテクチャーに移行して、管理者が組織全体で自動化を拡張できるようになります。
3.2. レガシー venvs の自動化実行環境への移行について
古いバージョンの自動化コントローラーからバージョン 4.0 以降にアップグレードすると、コントローラーは、組織、インベントリー、およびジョブテンプレートに関連付けられた以前のバージョンの仮想環境を検出して、新しい自動化実行環境モデルに移行する必要があることを通知します。自動化コントローラーを新たにインストールすると、インストール中に 2 つの virtualenv が作成されます。1 つはコントローラーを実行し、もう 1 つは Ansible を実行します。従来の仮想環境と同様に、自動化実行環境では、コントローラーを安定した環境で実行できますが、Playbook を実行するために必要に応じて、自動化実行環境にモジュールを追加または更新できます。
自動化実行環境でのセットアップを、以前のカスタム仮想環境から新しい自動化実行環境に移行することで複製できます。このセクションの awx-manage コマンドを使用して、以下を実行します。
-
現在のすべてのカスタムの仮想環境とそのパスをリスト表示する (
list_custom_venvs) -
特定のカスタムの仮想環境に依存するリソースの表示する (
custom_venv_associations) -
特定のカスタム仮想環境を、自動化実行環境への移行に使用できる形式にエクスポートする (
export_custom_venv)。
以下のワークフローでは、awx-manage コマンドを使用して、古い venvs から自動化実行環境に移行する方法を説明します。
3.3. 仮想環境を自動化実行環境に移行
Red Hat Ansible Automation Platform 2.0 および Automation Controller 4.0 にアップグレードしたら、移行プロセスの追加手順について、以下のセクションを使用します。
3.3.1. カスタムの仮想環境の構築
awx-manage コマンドを使用して、Automation Controller インスタンスの仮想環境をリスト表示できます。
手順
自動コントローラーインスタンスに SSH 接続して実行します。
$ awx-manage list_custom_venvs
検出された仮想環境のリストが表示されます。
# Discovered virtual environments: /var/lib/awx/venv/testing /var/lib/venv/new_env To export the contents of a virtual environment, re-run while supplying the path as an argument: awx-manage export_custom_venv /path/to/venv
3.3.2. カスタムの仮想環境に関連付けられたオブジェクトの表示
awx-manage コマンドを使用して、カスタムの仮想環境に関連付けられた組織、ジョブ、およびインベントリーソースを表示します。
手順
自動コントローラーインスタンスに SSH 接続して実行します。
$ awx-manage custom_venv_associations /path/to/venv
関連付けられたオブジェクトのリストが表示されます。
inventory_sources: - id: 15 name: celery job_templates: - id: 9 name: Demo Job Template @ 2:40:47 PM - id: 13 name: elephant organizations - id: 3 name: alternating_bongo_meow - id: 1 name: Default projects: []
3.3.3. エクスポートするカスタムの仮想環境の選択
awx-manage export_custom_venv コマンドを使用して、エクスポートするカスタムの仮想環境を選択します。
手順
自動コントローラーインスタンスに SSH 接続して実行します。
$ awx-manage export_custom_venv /path/to/venv
このコマンドにより、指定した仮想環境に含まれる pip freeze が表示されます。この情報は、Ansible Builder の requirements.txt ファイルにコピーして、新しい自動化実行環境イメージを作成するのに使用できます。
numpy==1.20.2 pandas==1.2.4 python-dateutil==2.8.1 pytz==2021.1 six==1.16.0 To list all available custom virtual environments run: awx-manage list_custom_venvs
awx-manage list_custom_venvs を実行して出力を減らしたときに -q フラグを渡します。
関連情報
- 自動化実行環境への移行の詳細は、Ansible Navigator Creator ガイド を参照してください。
第4章 分離ノードの実行ノードへの移行
バージョン 1.x から最新バージョンの Red Hat Automation Platform にアップグレードするには、プラットフォーム管理者が分離されたレガシーノードから実行ノードに、データを移行する必要があります。この移行は、自動化メッシュのデプロイに必要です。
このガイドでは、サイドバイサイド移行を実行する方法を説明します。これにより、移行プロセス中に元の自動化環境のデータが変更されないようになります。
移行プロセスには、次の手順が含まれます。
- アップグレード設定を確認します。
- 元のインスタンスをバックアップします。
- サイドバイサイドアップグレード用に新しいインスタンスをデプロイします。
- Ansible コントローラーを使用して、新しいインスタンスにインスタンスグループを再作成します。
- 元のバックアップを新しいインスタンスに復元します。
- 実行ノードを設定して、インスタンスを Red Hat Ansible Automation Platform 2.3 にアップグレードします。
- アップグレードされたコントローラーインスタンスを設定します。
4.1. Ansible Automation Platform をアップグレードするための前提条件
Ansible Automation Platform のアップグレードを開始する前に、環境が次のノードと設定の要件を満たしていることを確認してください。
4.1.1. ノードの要件
Ansible Automation Platform のアップグレードプロセスに関係するノードには、次の仕様が必要です。
- コントローラーノード、データベースノード、実行ノード、およびホップノード用の 16GB の RAM
- コントローラーノード、データベースノード、実行ノード、およびホップノード用の 4 つの CPU
- データベースノード用に 150 GB 以上のディスク容量
- データベースノード以外のノード用に 40 GB 以上のディスク容量
- DHCP 予約では、無限リースを使用して、静的 IP アドレスを持つクラスターをデプロイメント
- すべてのノードの DNS レコード
- すべてのノードで Red Hat Enterprise Linux 8 以降 64 ビット (x86) がインストール済み
- Chrony はすべてのノードに設定済み
- すべてのコンテンツ依存関係については Python3.9 以降
4.1.2. 自動化コントローラーの設定要件
Ansible Automation Platform のアップグレードプロセスを進める前に、次の自動化コントローラーの設定が必要です。
Chrony を使用した NTP サーバーの設定
クラスター内の各 Ansible Automation Platform ノードは NTP サーバーにアクセスできる必要があります。chronyd を使用して、システムクロックを NTP サーバーと同期します。これにより、ノード間の日付と時刻が同期していない場合でも、検証が必要な SSL 証明書を使用するクラスターノードが失敗しなくなります。
これは、アップグレードされた Ansible Automation Platform クラスターで使用されるすべてのノードで必要です。
chronyをインストールします。# dnf install chrony --assumeyes
-
テキストエディターを使用して
/etc/chrony.confを開きます。 パブリックサーバープールセクションを見つけて、適切な NTP サーバーアドレスが含まれるように変更します。必要なサーバーは 1 台だけですが、推奨は 3 台です。'iburst' オプションを追加して、サーバーと適切に同期するのにかかる時間を短縮します。
# Use public servers from the pool.ntp.org project. # Please consider joining the pool (http://www.pool.ntp.org/join.html). server <ntp-server-address> iburst
-
/etc/chrony.confファイル内に変更を保存します。 ホストを起動し、
chronydデーモンを有効にします。# systemctl --now enable chronyd.service
chronydデーモンのステータスを確認します。# systemctl status chronyd.service
すべてのノードでの Red Hat サブスクリプションのアタッチ
Red Hat Ansible Automation Platform では、すべてのノードに有効なサブスクリプションをアタッチする必要があります。次のコマンドを実行して、現在のノードに Red Hat サブスクリプションがあることが確認できます。
# subscription-manager list --consumed
ノードにアタッチされている Red Hat サブスクリプションがない場合の詳細は、Ansible Automation Platform サブスクリプションのアタッチ を参照してください。
sudo 権限を持つ root 以外のユーザーの作成
Ansible Automation Platform をアップグレードする前に、デプロイプロセスの sudo 権限を持つ root 以外のユーザーを作成することを推奨します。このユーザーは以下で使用されます。
- SSH 接続
- インストール時中のパスワードレス認証
- 特権昇格 (sudo) 権限
次の例では、ansible を使用してこのユーザーに名前を付けています。アップグレードされた Ansible Automation Platform クラスターで使用されるすべてのノードで、ansible という名前で root 以外のユーザーを作成し、ssh キーを生成します。
非 root ユーザーを作成します。
# useradd ansible
ユーザーのパスワードを設定します。
# passwd ansible 1 Changing password for ansible. Old Password: New Password: Retype New Password:- 1
- 別の名前を使用している場合は、
ansibleを手順 1 の root 以外のユーザーに置き換えます。
ユーザーとして
sshキーを生成します。$ ssh-keygen -t rsa
sudoを使用する場合にパスワードを要求されないようにします。# echo "ansible ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers.d/ansible
SSH キーをすべてのノードにコピー
ansible ユーザーを作成したら、アップグレードされた Ansible Automation Platform クラスターで使用されているすべてのノードに ssh キーをコピーします。これにより、Ansible Automation Platform のインストールが実行されたときに、パスワードなしですべてのノードへの ssh が可能になります。
$ ssh-copy-id ansible@node-1.example.com
クラウドプロバイダー内で実行している場合は、代わりに、すべてのノードに ansible ユーザーの公開鍵を含む ~/.ssh/authorized_keys ファイルを作成し、authorized_keys ファイルのパーミッションは、所有者 (ansible) だけに読み取りおよび書き込み権限 (パーミッション 600) を設定します。
ファイアウォールの設定
アップグレードされた Ansible Automation Platform クラスターで使用されるすべてのノードでファイアウォール設定を指定して、Ansible Automation Platform を正常にアップグレードするために適切なサービスとポートへのアクセスを許可します。Red Hat Enterprise Linux 8 以降の場合は、firewalld デーモンを有効にして、すべてのノードに必要なアクセスを有効にします。
firewalldパッケージをインストールします。# dnf install firewalld --assumeyes
firewalldサービスを開始します。# systemctl start firewalld
firewalldサービスを有効にします。# systemctl enable --now firewalld
4.1.3. Ansible Automation Platform の設定要件
Ansible Automation Platform のアップグレードプロセスを進める前に、次の Ansible Automation Platform 設定が必要です。
実行ノードとホップノードのファイアウォール設定
Red Hat Ansible Automation Platform インスタンスをアップグレードした後に、自動メッシュ機能を有効にするために、メッシュノード (実行ノードおよびホップノード) に自動メッシュポートを追加します。すべてのノードのメッシュネットワークに使用されるデフォルトのポートは 27199/tcp です。インベントリーファイル内の各ノードの変数として recptor_listener_port を指定することにより、異なるポートを使用するようにメッシュネットワークを設定できます。
ホップおよび実行ノード内で、インストールに使用する firewalld ポートを設定します。
firewalldが実行されていることを確認します。$ sudo systemctl status firewalld
コントローラーデータベースノードに
firewalldポートを追加します (例: ポート 27199)。$ sudo firewall-cmd --permanent --zone=public --add-port=27199/tcp
firewalldをリロードします。$ sudo firewall-cmd --reload
ポートが開いていることを確認します。
$ sudo firewall-cmd --list-ports
4.2. Ansible Automation Platform インスタンスのバックアップ
backup_dir フラグを指定して .setup.sh スクリプトを実行し、既存の Ansible Automation Platform インスタンスをバックアップします。これにより、現在の環境のコンテンツと設定が保存されます。
-
ansible-tower-setup-latestディレクトリーに移動します。 以下の例に従って、
./setup.shスクリプトを実行します。$ ./setup.sh -e ‘backup_dir=/ansible/mybackup’ -e ‘use_compression=True’ @credentials.yml -b 12
バックアップが成功すると、バックアップファイルが /ansible/mybackup/tower-backup-latest.tar.gz に作成されます。
このバックアップは、後でコンテンツを古いインスタンスから新しいインスタンスに移行するために必要になります。
4.3. サイドバイサイドアップグレード用の新規インスタンスのデプロイ
サイドバイサイドアップグレードプロセスを続行するには、同じインスタンスグループ設定で Ansible Tower 3.8.x の 2 番目のインスタンスをデプロイします。この新しいインスタンスは、元のインスタンスからコンテンツおよび設定を受け取り、後で Red Hat Ansible Automation Platform 2.3 にアップグレードされます。
4.3.1. Ansible Tower の新規インスタンスのデプロイ
新しい Ansible Tower インスタンスをデプロイするには、次の手順を実行します。
- Ansible Tower インストーラーページ に移動して、元の Tower インスタンスに対応する Tower インストーラーバージョンをダウンロードします。
インストーラーに移動し、テキストエディターを使用して
inventoryファイルを開き、Tower インストール用のinventoryファイルを設定します。Tower を設定したら、
isolated_groupまたはinstance_groupを含むフィールドをすべて削除します。注記Ansible Automation Platform インストーラーを使用した Tower のインストールの詳細は、特定のインストールシナリオの Ansible Automation Platform インストールガイド を参照してください。
-
setup.shスクリプトを実行して、インストールを開始します。
新しいインスタンスがインストールされたら、元の Tower インスタンスのインスタンスグループと一致するように Tower 設定を指定します。
4.3.2. 新しいインスタンスでのインスタンスグループの再作成
新しいインスタンスでインスタンスグループを再作成するには次の手順を実行します。
元の Tower インスタンスのすべてのインスタンスグループをメモします。新しいインスタンスでこれらのグループを再作成する必要があります。
- Tower の新しいインスタンスにログインします。
- ナビゲーションペインで、Administration → Instance groups を選択します。
- Create instance group をクリックします。
- 元のインスタンスのインスタンスグループと同じ Name を入力し、Save をクリックします
- 元のインスタンスのインスタンスグループがすべて再作成されるまで繰り返します。
4.4. 新しいインスタンスへのバックアップの復元
restore_backup_file フラグを指定して ./setup.sh スクリプトを実行すると、コンテンツが元の 1.x インスタンスのバックアップファイルから新しいインスタンスに移行されます。これにより、すべてのジョブ履歴、テンプレート、およびその他の Ansible Automation Platform 関連のコンテンツが効果的に移行されます。
手順
以下のコマンドを実行します。
$ ./setup.sh -r -e ‘restore_backup_file=/ansible/mybackup/tower-backup-latest.tar.gz’ -e ‘use_compression=True’ -e @credentials.yml -r -- --ask-vault-pass 123
新しい RHEL 8 Tower 3.8 インスタンスにログインして、元のインスタンスのコンテンツが復元されているかどうかを確認します。
- Administration → Instance groups に移動します。再作成されたインスタンスグループには、元のインスタンスの Total Jobs が含まれているはずです。
- サイドナビゲーションパネルを使用して、ジョブ、テンプレート、インベントリー、クレデンシャル、ユーザーなどのコンテンツが元のインスタンスからインポートされていることを確認します。
これで、元のインスタンスの全 Ansible コンテンツを含む Ansible Tower の新しいインスタンスができました。
この新しいインスタンスを Ansible Automation Platform 2.3 にアップグレードして、元のインスタンスを上書きせずに以前のすべてのデータを保持できるようにします。
4.5. Ansible Automation Platform 2.3 へのアップグレード
Ansible Tower のインスタンスを Ansible Automation Platform 2.3 にアップグレードするには、inventory ファイルを元の Tower インスタンスから新しい Tower インスタンスにコピーし、インストーラーを実行します。Red Hat Ansible Automation Platform インストーラーは、2.3 より前のバージョンを検出し、アップグレードされたインベントリーファイルを提供して、アップグレードプロセスを続行します。
- Red Hat Ansible Automation Platform の最新のインストーラーを Red Hat Customer Portal からダウンロードします。
ファイルをデプロイメントします。
$ tar xvzf ansible-automation-platform-setup-<latest_version>.tar.gzAnsible Automation Platform のインストールディレクトリーに移動します。
$ cd ansible-automation-platform-setup-<latest_version>/元のインスタンスから最新のインストーラーのディレクトリーに
inventoryファイルをコピーします。$ cp ansible-tower-setup-3.8.x.x/inventory ansible-automation-platform-setup-<latest_version>setup.shスクリプトを実行します。$ ./setup.sh
セットアップスクリプトは一時停止し、pre-2.x インベントリーファイルが検出されたことを示しますが、
inventory.new.iniという新しいファイルが提供され、元のインスタンスのアップグレードを続行できます。テキストエディターで
inventory.new.iniを開きます。注記インストーラーは、セットアップスクリプトを実行することで、tower の名前を automationcontroller に変更するなど、元のインベントリーファイルからいくつかのフィールドを変更しました。
新しく生成された
inventory.new.iniファイルを変更して、関連する変数、ノード、および関連するノード間ピア接続を割り当てて、自動化メッシュを設定します。注記自動化メッシュトポロジーの設計は、環境の自動化のニーズによって異なります。本書では、考えられるシナリオの設計をすべて提供することはしていません。以下は、自動化メッシュ設計の例です。ニーズに合わせて設計する方法は、Ansible Automation Platform オートメーションメッシュの完全なガイド を参照してください。
ホップノードを利用する 3 つのノードで設定される標準のコントロールプレーンを含むインベントリーファイルの例:
[automationcontroller] control-plane-1.example.com control-plane-2.example.com control-plane-3.example.com [automationcontroller:vars] node_type=control 1 peers=execution_nodes 2 [execution_nodes] execution-node-1.example.com peers=execution-node-2.example.com execution-node-2.example.com peers=execution-node-3.example.com execution-node-3.example.com peers=execution-node-4.example.com execution-node-4.example.com peers=execution-node-5.example.com node_type=hop execution-node-5.example.com peers=execution-node-6.example.com node_type=hop 3 execution-node-6.example.com peers=execution-node-7.example.com execution-node-7.example.com [execution_nodes:vars] node_type=execution
自動化ハブ API トークンをインポートまたは生成します。
automationhub_api_tokenフラグを使用して既存の API トークンをインポートします。automationhub_api_token=<api_token>
generate_automationhub_tokenフラグをTrueに設定して、新しい API トークンを生成し、既存のトークンを無効にします。generate_automationhub_token=True
自動化メッシュ用に
inventory.new.iniの設定が完了したら、inventory.new.iniを使用してセットアップスクリプトを実行します。$ ./setup.sh -i inventory.new.ini -e @credentials.yml -- --ask-vault-pass
- インストールが完了したら、すべての自動化コントローラーノードで Ansible Automation Platform ダッシュボード UI にログインして、Ansible Automation Platform が正常にインストールされたことを確認します。
関連情報
- Ansible Automation Platform インストーラーの使用に関する一般的な情報は、Red Hat Ansible Automation Platform インストールガイド を参照してください。
- 自動化メッシュの詳細は、Ansible Automation Platform 自動化メッシュガイド を参照してください。
4.6. アップグレードされた Ansible Automation Platform の設定
4.6.1. 自動化コントローラーインスタンスグループの設定
Red Hat Ansible Automation Platform インスタンスをアップグレードした後に、自動化コントローラー UI で設定を指定して、元のインスタンスを対応するインスタンスグループに関連付けます。
- 新しい Controller インスタンスにログインします。
- クレデンシャル、ジョブ、インベントリーなどの古いインスタンスのコンテンツが、コントローラーインスタンスに表示されるようになります。
- Administration → Instance Groups に移動します。
- インスタンスグループをクリックして実行ノードを関連付け、Instances タブをクリックします。
- Associate をクリックします。このインスタンスグループに関連付けるノードを選択し、保存 をクリックします。
- デフォルトのインスタンスを変更して、新しい実行ノードの関連付けを解除することもできます。
第5章 Ansible コンテンツの移行
ansible-core バージョンから ansible-core 2.13 に移行する場合は、各バージョン間の変更と更新について理解できるように Ansible Core 移植ガイド を確認することを検討してください。Ansible Core 移植ガイドを確認する場合は、ガイドの左上の列にある最新バージョンの ansible-core または devel を選択してください。
完全にサポートおよび認定された Ansible コンテンツコレクションのリストについては、console.redhat.com の Ansible Automation Hub を参照してください。
5.1. Ansible Playbook とロールの Core 2.13 への移行
非コレクションベースのコンテンツからコレクションベースのコンテンツに移行する場合は、予期しない動作を回避するために、Playbook とロールで完全修飾コレクション名 (FQCN) を使用する必要があります。
FQCN を使用した Playbook の例:
- name: get some info
amazon.aws.ec2_vpc_net_info:
region: "{{ec2_region}}"
register: all_the_info
delegate_to: localhost
run_once: true
ansible-core モジュールを使用していて、別のコレクションからモジュールを呼び出していない場合は、FQCNansible.builtin.copy を使用する必要があります。
FQCN を使用したモジュールの例:
- name: copy file with owner and permissions ansible.builtin.copy: src: /srv/myfiles/foo.conf dest: /etc/foo.conf owner: foo group: foo mode: '0644'
