Red Hat Ansible Automation Platform のアップグレードおよび移行ガイド
最新バージョンの Ansible Automation Platform にアップグレードし、以前の仮想環境を自動化実行環境に移行
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
第1章 分離ノードの実行ノードへのアップグレード
バージョン 1.x から最新バージョンの Red Hat Automation Platform にアップグレードするには、プラットフォーム管理者が分離されたレガシーノードから実行ノードに、データを移行する必要があります。この移行は、自動化メッシュのデプロイに必要です。
このガイドでは、サイドバイサイド移行を実行する方法を説明します。これにより、移行プロセス中に元の自動化環境のデータが変更されないようになります。
移行プロセスには、次の手順が含まれます。
- アップグレード設定を確認します。
- 元のインスタンスをバックアップします。
- サイドバイサイドアップグレード用に新しいインスタンスをデプロイします。
- Ansible コントローラーを使用して、新しいインスタンスにインスタンスグループを再作成します。
- 元のバックアップを新しいインスタンスに復元します。
- 実行ノードを設定し、インスタンスを Red Hat Ansible Automation Platform 2.1 にアップグレードします。
- アップグレードされたコントローラーインスタンスを設定します。
1.1. Ansible Automation Platform をアップグレードするための前提条件
Ansible Automation Platform のアップグレードを開始する前に、環境が次のノードと設定の要件を満たしていることを確認してください。
1.1.1. ノードの要件
Ansible Automation Platform のアップグレードプロセスに関係するノードには、次の仕様が必要です。
- コントローラーノード、データベースノード、実行ノード、およびホップノード用の 16GB の RAM
- コントローラーノード、データベースノード、実行ノード、およびホップノード用の 4 つの CPU
- データベースノード用に 150 GB 以上のディスク容量
- データベースノード以外のノード用に 40 GB 以上のディスク容量
- DHCP 予約では、無限リースを使用して、静的 IP アドレスを持つクラスターを展開
- すべてのノードの DNS レコード
- すべてのノードで Red Hat Enterprise Linux 8 以降 64 ビット (x86) がインストール済み
- Chrony はすべてのノードに設定済み
- すべてのコンテンツ依存関係については Python 3.8 以降
1.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
1.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
1.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
に作成されます。
このバックアップは、後でコンテンツを古いインスタンスから新しいインスタンスに移行するために必要になります。
1.3. サイドバイサイドアップグレード用の新規インスタンスのデプロイ
サイドバイサイドアップグレードプロセスを続行するには、同じインスタンスグループ設定で Ansible Tower 3.8.x の 2 番目のインスタンスをデプロイします。この新しいインスタンスは、元のインスタンスからコンテンツおよび設定を受け取り、後で Red Hat Ansible Automation Platform 2.1 にアップグレードされます。
1.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 設定を指定します。
1.3.2. 新しいインスタンスでのインスタンスグループの再作成
新しいインスタンスでインスタンスグループを再作成するには次の手順を実行します。
元の Tower インスタンスのすべてのインスタンスグループをメモします。新しいインスタンスでこれらのグループを再作成する必要があります。
- Tower の新しいインスタンスにログインします。
- ナビゲーションペインで、Administration → Instance groups を選択します。
- Create instance group をクリックします。
- を入力します。Name元のインスタンスのインスタンスグループと一致するもので、Save をクリックします。
- 元のインスタンスのインスタンスグループがすべて再作成されるまで繰り返します。
1.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.1 にアップグレードして、元のインスタンスを上書きせずに以前のすべてのデータを保持できるようにします。
1.5. Ansible Automation Platform 2.1 へのアップグレード
Ansible Tower のインスタンスを Ansible Automation Platform 2.1 にアップグレードするには、inventory
ファイルを元の Tower インスタンスから新しい Tower インスタンスにコピーし、インストーラーを実行します。Red Hat Ansible Automation Platform インストーラーは、2.1 より前のインベントリーファイルを検出し、アップグレードされたインベントリーファイルを提供して、アップグレードプロセスを続行します。
- Red Hat Ansible Automation Platform の最新のインストーラーを Red Hat Customer Portal からダウンロードします。
ファイルを展開します。
$ tar xvzf ansible-automation-platform-setup-<latest-version>.tar.gz
Ansible 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
ファイルを変更して、関連する変数、ノード、および関連するノード間ピア接続を割り当てて、自動化メッシュを設定します。注記自動化メッシュトポロジーの設計は、環境の自動化のニーズによって異なります。以下の例は、自動化メッシュ設計で考えられるシナリオの 1 つです。自動化メッシュトポロジーの設計は、使用する環境の自動化のニーズによって異なります。ニーズに合わせて設計する方法については、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
自動化メッシュ用に
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 自動化メッシュガイド を参照してください。
1.6. アップグレードされた Ansible Automation Platform の設定
1.6.1. 自動化コントローラーインスタンスグループの設定
Red Hat Ansible Automation Platform インスタンスをアップグレードした後、Automation Controller UI で設定を行って、元のインスタンスを対応するインスタンスグループに関連付けます。
- 新しい Controller インスタンスにログインします。
- 認証情報、ジョブ、インベントリーなどの古いインスタンスのコンテンツが、コントローラーインスタンスに表示されるようになります。
- Administration → Instance Groups に移動します。
- インスタンスグループをクリックして実行ノードを関連付けてから、 をクリックします。Instances タブに移動します。
- Associate をクリックします。このインスタンスグループに関連付けるノードを選択し、保存 をクリックします。
- デフォルトのインスタンスを変更して、新しい実行ノードの関連付けを解除することもできます。
第2章 自動化実行環境への移行
2.1. 自動化実行環境にアップグレードする理由
Red Hat Ansible Automation Platform 2.1 では、自動化実行環境が導入されています。自動化実行環境は、単一のコンテナー内で Ansible Automation を実行するために必要なすべてのものを含めることにより、Ansible の管理を容易にするコンテナーイメージです。自動化実行環境には、以下が含まれます。
- RHEL UBI 8
- Ansible 2.9 または Ansible Core 2.11
- Python 3.8 以降。
- Ansible コンテンツコレクション
- Python またはバイナリーの依存関係のコレクション
これらの要素を含めることで、Ansible はプラットフォーム管理者は、自動化が実行される環境を標準化して定義、構築、および配布できるようになります。
新しい自動化実行環境により、管理者がカスタムプラグインや自動化コンテンツを作成する必要がなくなりました。管理者は、これまでよりも短時間で、サイズのより小さい自動化実行環境を起動できるようになります。
すべてのカスタム依存関係は、管理およびデプロイメントフェーズではなく、開発フェーズで定義されるようになりました。コントロールプレーンから分離することで、開発サイクルの高速化、スケーラビリティ、信頼性、および環境間での移植性が実現します。自動化実行環境により、Ansible Automation Platform を分散アーキテクチャーに移行して、管理者が組織全体で自動化を拡張できるようになります。
2.2. レガシー venvs の自動化実行環境への移行について
古いバージョンの自動化コントローラーからバージョン 4.0 以降にアップグレードすると、コントローラーは、組織、インベントリー、およびジョブテンプレートに関連付けられた以前のバージョンの仮想環境を検出して、新しい自動化実行環境モデルに移行する必要があることを通知します。自動化コントローラーを新たにインストールすると、インストール中に 2 つの virtualenv が作成されます。1 つはコントローラーを実行し、もう 1 つは Ansible を実行します。従来の仮想環境と同様に、自動化実行環境では、コントローラーを安定した環境で実行できますが、Playbook を実行するために必要に応じて、自動化実行環境にモジュールを追加または更新できます。
自動化実行環境でのセットアップを、以前のカスタム仮想環境から新しい自動化実行環境に移行することで複製できます。このセクションの awx-manage
コマンドを使用して、以下を実行します。
-
現在のすべてのカスタムの仮想環境とそのパスを一覧表示する (
list_custom_venvs
) -
特定のカスタムの仮想環境に依存するリソースの表示する (
custom_venv_associations
) -
特定のカスタム仮想環境を、自動化実行環境への移行に使用できる形式にエクスポートする (
export_custom_venv
)。
以下のワークフローでは、awx-manage
コマンドを使用して、古い venvs から自動化実行環境に移行する方法を説明します。
2.3. 仮想環境を自動化実行環境に移行
Red Hat Ansible Automation Platform 2.0 および自動化コントローラー 4.0 にアップグレードしたら、移行プロセスの追加手順について、以下のセクションを使用します。
2.3.1. カスタムの仮想環境の構築
awx-manage
コマンドを使用して、自動化コントローラーインスタンスの仮想環境を一覧表示できます。
手順
自動コントローラーインスタンスに 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
2.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: []
2.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
フラグを渡します。
2.4. 関連情報
- 自動化実行環境への移行に関する詳細は、Red Hat Ansible Automation Platform Creator ガイド を参照してください。
第3章 Ansible コンテンツの移行
ansible-core
バージョンから ansible-core
2.12+ に移行する場合は、各バージョン間の変更と更新について理解できるように Ansible Core 移植ガイド を確認することを検討してください。Ansible Core 移植ガイドを確認するときは、ガイドの左上の列にある最新バージョンの ansible-core
または devel
を選択してください。
完全にサポートおよび認定された Ansible コンテンツコレクションのリストについては、console.redhat.com の Ansible Automation Hub を参照してください。
3.1. Ansible Playbook とロールの Core2.12 jへの移行
非コレクションベースのコンテンツからコレクションベースのコンテンツに移行する場合は、予期しない動作を回避するために、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'