Ansible Automation Platform 2.1 のご紹介 Part2 - アップグレード編（その１）

皆さんこんにちは、Red Hat ソリューションアーキテクトの岡野です。 前回は AAP2.1 の大きな変更点であるコンテナ化された実行環境と、Ansible Automation Controller による実行方法についてご説明しました。今回、ansible-navigator のご説明をしよう！と思っていたのですが、ちょっと予定を変更して、旧バージョンからのアップグレードに関してご説明しようと思います。

旧バージョンである、AAP 1.2（Ansible Tower 3.8）は、2022年11月18日 でサポート終了（EOL）なのですが、実はこれを見越してか弊社サポートには、

『Ansible Tower 3.8 の11月18日以降のサポートってどうなるんですか!?』

というような問い合わせが複数来ている様です。勿論 EOL 後はサポートが無くなるので、AAP 2.1 へ早めの移行をお願いします！となるのですが、アップグレードへの不安も大きいのかなとも思い、

『ブログで早くご紹介しなければ』

と思い立ったというのが背景です。その方がお互いハッピーですしね。♬
まず、最初に申し上げておくと、AAP 1.2 → AAP 2.1 へのバージョンアップは決して難しくありません。

押さえておくべき点は以下の2つです。

• アップグレードの手法としては『インプレースアップグレード』または『バックアップ・リストア』が可能
  但し、使える手法は既存環境に依存
• 変更またはサポートされなくなった機能とその移行方法について理解する

AAP 1.2 と AAP 2.1 の『主な違い』は下記の通りです。

1. システム要件
   最小 4CPU/16GB など、OSはRHEL 8.4 or later のみサポート（RHEL 7.x / CentOS が非サポートに）
   ※Disk などその他の要件はマニュアルをご確認ください。

2. Python の仮想環境 (virtualenv) → execution environment
   virtualenv を使っている場合は実行環境への移行を検討

3. ansible engine 2.9 → ansible-core 2.12 モジュール提供方法の違い
   現在 AAP 1.2 環境で利用しているモジュールと AAP 2.1 での提供方法についての確認
   必要な場合は実行環境へのモジュールの追加

4. Isolated Node → Automation Mesh（その２でご紹介）
   Isolated Node を使っている場合は Automation Mesh の機能の理解と移行方法の確認

その他 AAP 2.0 以降サポートされなくなった機能に関しては以下のリリースノートをご確認ください。

docs.ansible.com

では、上記を考慮した具体的なアップグレード方法を見ていきます。

1. システム要件を考慮したアップグレード手法の選択
AAP 1.2 → AAP 2.1 へのバージョンアップの方法は以下の2つが提供されています。

1. インプレースアップグレード
2. バックアップリストア

簡単なのは『1』です。既存の AAP 1.2 環境に対する AAP 2.1 の上書きインストールなので、AAP 2.1 の新規インストールを理解した方であれば簡単です。但し、この方法は旧環境が AAP 1.2 であること、また、AAP 2.1 のシステム要件を旧環境が満たしている事が条件となります。例えば、Ansible Tower 3.7 (既にEOLですが...) をご利用の場合には、AAP 1.2 への事前アップグレード、RHEL 7.x をご利用の場合は、RHEL 8 へのアップグレード（以下のリンク参照）を事前に実施いただく必要があります。

access.redhat.com

既存 が CentOS の場合、また、既存は RHEL 7.x なんだけど、やっぱり RHEL 8 は新規でインストールしたい・・・、という場合など、新たな OS の上に AAP 2.1 をインストールする場合は、『2』 のバックアップリストアを行う事になります。この際の注意点は、

『バックアップ元の AAP とリストア先の AAP のバージョンは同一であること』

という条件がある事です。このため、以下のようなアップグレード手順となります。

• 新たに RHEL 8.4 (or later) をインストール
• 新環境に AAP 1.2 をインストール (./setup.sh)
• æ—§ AAP 1.2 のバックアップを取得 (./setup.sh -b)
• æ–° AAP 1.2 環境にバックアップイメージをリストア (./setup.sh -r)
• 新環境を AAP 1.2 → AAP 2.1 にインプレースアップグレード

AAP 1.2 のバクアップイメージを直接 AAP 2.1 環境にリストア出来ないため、手順が少し多くなりますが似たようなコマンド叩くだけなので難しいことはありません。Ansible Towerのバックアップリストアに関してはこちらもご参照ください。

rheb.hatenablog.com

2. Python の仮想環境 (virtualenv) → execution environment
3. ansible engine 2.9 → ansible-core 2.12 モジュール提供方法の違い
2 と 3 ですが、共に『実行環境をカスタムで作成する事』により対応します。前回 Part 1で、AAP 2.1 で利用するコンテナ化された実行環境は Red Hat Ecosystem Catalog より提供されるというご説明をしましたが、カスタムで作成する事も可能です。カスタムでの実行環境の作成が必要となるのは主に以下の二つのケースです。

• AAP 1.2 で利用している virtualenv の移行
• モジュールや依存パッケージのインストール

AAP 1.2 で Python の仮想環境である virtualenv を利用されている場合、AAP 2.1 では、その環境をコンテナ化された実行環境に移行するのがベストプラクティスです。また、既存の AAP 1.2 環境で ansible 2.9 に対して Collections を追加インストールしている様な場合は、それらを含む実行環境のカスタム作成が基本スタンスとなります。ただ、

『実行環境をカスタムで作成するって難しそう...』

・・・ですよね。でも、AAP 2.1 でサポートされた実行環境のカスタマイズツールである ansible-builder を使うと簡単です！ ansible-builder は AAP 2.1 とは別インストールの CLI ツールです。まずは、ansible-builder のコマンドラインから直接読み込まれる execution-environment.yml ファイルを作成し、さらにその中から最大4つのファイルを読み込んで実行環境を作成します。要はこのファイルの中に自分が追加したいコンポーネントを記載してコマンドを実行すればOK。考えるよりやってみると実は簡単です。

• execution-environment.yml
  コマンド実行時に指定するファイル。この中で以下のファイルを指定します。
  • ansible.cfg
    Collections のダウンロード先に関する情報とアクセストークン情報
  • requirements.yml
    ダウンロード対象の Collections の指定
  • requirements.txt
    Collections が必要とする Python モジュール
  • bindep.txt
    Collections が必要とする OS パッケージ

execution-environment.yml から読み込まれる4つのファイルについては必要なファイルのみ作成の上指定すればOKです。一例ですが、カスタマイズ用の最小のイメージ ee-minimal-rhel8 に vmware のコミュニティモジュール community.vmware を追加する場合はこんな感じでファイルを作成します。

・execution-environment.yml

version: 1
build_arg_defaults:
  EE_BASE_IMAGE: 'registry.redhat.io/ansible-automation-platform-21/ee-minimal-rhel8:latest'
  EE_BUILDER_IMAGE: 'registry.redhat.io/ansible-automation-platform-21/ansible-builder-rhel8:latest'

ansible_config: 'ansible.cfg'

dependencies:
  galaxy: requirements.yml
  python: requirements.txt
  system: bindep.txt

　
・ansible.cfg

url=https://cloud.redhat.com/api/automation-hub/
auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
token=<your_access_token_here>

※ アクセストークンはご自身の物に置き換えてください
　
・requirements.yml

collections:
  - community.vmware

※requirements.txt と bindep.txt は今回は空ファイルです。
　
ansible-builder 及び、ansible-navigator をインストールしていない場合はインストールしましょう。

$ sudo subscription-manager repos --enable ansible-automation-platform-2.1-for-rhel-8-x86_64-rpms
$ sudo dnf install ansible-navigator
$ sudo dnf install ansible-builer

### ベースイメージのダウンロードに必要な Red Hat Ecosystem Catalog へのログイン
$ podman login registry.redhat.io

ansible-builer build コマンドでビルドします！！

$ ansible-builder build -t com-vmware:0.0.1

podman コマンドで作成した実行環境イメージについて確認してみます。

$ podman images 
REPOSITORY                                                     TAG                IMAGE ID      CREATED         SIZE
localhost/com-vmware                                           0.0.1              7baa2662f467  53 minutes ago  553 MB
<none>                                                         <none>             724422227dd8  49 minutes ago  422 MB
<none>                                                         <none>             699ecae59108  49 minutes ago  403 MB

<none> はビルドに利用した中間イメージです。容量を食うので削除しておきましょう。♬

$ podman image prune

ansible-navigator による実行環境の詳細確認

$ ansible-navigator images --pp never

作成したイメージと、ビルドに利用した実行環境のイメージが一覧表示されます。詳細確認には左横の番号をキーボード入力ください。上記の場合は、『5』です。作成に利用したベースイメージは『10』ですね。

さらに、『2』を入力して、インストールされた Collections を確認してみてください。

community.vmware がインストールされていることが分かります。『esc』キーを使って元に戻り、さらに『3』を入力して、Python パッケージを確認してみてください。

community.vmware に必要な pyvmomi、vSphere-Automation-SDK がインストールされていることが分かります。興味ある方は、上記内容を、ベースとなったイメージと比べてみると良いと思います。これで、ansible-core 2.12 の実行環境にcommunity.vmware を組み込む事が出来ましたので、後はこの実行環境を使って実際の vSphere の環境を操作できるか確認すれば完了です！簡単ですよね♬

上記では簡単な例として、community.vmware モジュールを追加しましたが、ansible.posix、amazon.aws、ansible.windows を追加する場合は、requirement.yml を以下の様に編集しビルドすればOKです。

・requirements.yml

collections:
  - ansible.posix
  - amazon.aws
  - ansible.windows

慣れると簡単ですので、色々作成して遊んでみてください。♬

ansible-builder を使ってカスタムビルドの実行環境が出来る様になったら、virtualenv の移行も簡単です。以下のマニュアルに分かり易く記載されていますのでご確認いただければと思います。

access.redhat.com

基本的には、以下の手順となります。

• 既存環境で定義されている全てのカスタム仮想環境とそのパスを一覧表示 (list_custom_venvs)
• 移行予定のカスタム仮想環境に依存するAutomation Controller のリソースを表示 (custom_venv_associations)
• 移行予定のカスタム仮想環境を requirements.txt としてエクスポートする (export_custom_venv -q)。
• requirements.txt を使って実行環境をビルド

ちょっと長くなりましたので、Isolated Node → Automation Mesh については次回ご説明したいと思います。

まとめ
アップグレードを検討する際のポイントは以下となります。

• システム要件や機能など AAP 1.2 との差異を理解する
• サポートされなくなった機能の AAP 1.2 での利用の有無を確認する
• サポートされなくなった機能の移行とその方法について理解する
  virtualenv → execution environment
  Isolated Node → Automation Mesh （次回説明）など

ansible-builder の利用詳細については以下のマニュアルを参照ください。
access.redhat.com