皆さんこんにちは、Red Hat ソリューションアーキテクトの岡野です。 前回で AAP2.1 への移行の考え方と手法についてご紹介しました。今回、Isolated Node の移行についてご説明します。Automation Controller から直接アクセスできないホストに対するジョブ実行に関しては、AAP 1.2 では Isolated Node がサポートされていました。この方法は Python の virtualenv を使っていたため、実行環境がコンテナ化された AAP 2.1 では利用できなくなってしまったのですが、それを置き換える機能として新たに『automation mesh』が実装されました！単に Isolated Node を置き換えるだけではなく、Automation Controller のスケーラビリティや管理性を飛躍的に向上させる凄く魅力的な機能です。♪
automation mesh 詳細
automation mesh を一言で言うと、Automation Controller の分割実装です。
『 4 種類のノードを必要に応じてメッシュ状に組み合わせて Automation Controller を構成できる』
これが automation mesh です。4 種類のノードは以下の通りです。
- ハイブリッドノード
コントロールノードと実行ノードの機能を併せ持つノード。旧 Ansible Tower ノードに相当します。 - コントロールノード
ダッシュボードや API、ジョブスケジュール、実行ログ、通知などバックエンドの処理を行うノード。PostgreSQL に接続される。ユーザージョブの実行は自身では行わず実行ノードに転送し実行する。 - 実行ノード
コントロールノードやハイブリッドノードから転送されたジョブをコンテナ化された実行環境内で実行する。 - ホップノード
コントロールノードやハイブリッドノードからのジョブ実行命令を実行ノードに転送する。
つまり、Automation Controller を、『コントロールプレーン』、『実行プレーン』、そして『転送プレーン』に分割して構成できるのが automation mesh です。この機能により、
- 『 ホップノード』を使った分離されたネットワークへのジョブ転送
- 『実行ノード』追加による容易なスケールアウト（管理対象ノードが増えてきた時など）
- 『ハイブリッドノード』または『コントロールノード』による実行環境の集中コントロール
が可能となりました。
AAP 1.2 では分離されたネットワークへの対応は Isolated ノードを使ってジョブ実行を行っていました。Isolated Node への接続は ssh (port 22) で、必要に応じ Jumphost で多段接続するようなちょっとした『力技』を使っていましたが、AAP 2.1 では各ノードの接続用に receptor (port 27199) という仕組みが組み込まれ、ジョブが receptor を通じで必要な実行ノードに転送され、実行されます。
automation mesh の構築に関してはインストール時のインベントリーファイルにノードの種別と接続先を入力するだけ。インストール後に変数等の設定を行う必要も無いため簡単です。
また、AAP 1.2 の Isolated ノードは、Python の virtualenv を使っていたため、実行環境の更新やカスタム化された実行環境が必要になった場合、各 Isolated Node を手動で更新する必要がありましたが、AAP 2.1 では実行環境がコンテナ化されたために集中管理できるようになり、管理性が大幅に向上しました。管理対象ノードが増えてきた際は、実行ノードを簡単に追加できるため拡張性にも優れます。
AAP 1.2 の Isolated Node と AAP 2.1 の automation mesh の比較は以下の通りです。
Automation Controller の構成（例）と構成するためのインベントリーファイルの例（抜粋）を 3つ示します。勿論これ以外にも柔軟に構成は可能です。
1. 『ハイブリッドノード』のみで構成した例
ハイブリッドノードを Cluster で構成していますが、実行ノードやホップノードを含まない基本的な構成例です。旧 AAP 1.2 でも同様の構成が可能です。
[automationcontroller] aac00.example.com aac01.example.com aac02.example.com aac03.example.com [database] db00.example.com ...以下略...
2. 『コントロールノード』+『実行ノード』で構成した例
管理系はコントロールノード、ユーザーのジョブ実行は実行ノードで分けて構成した例です。AAP 1.2 の Isolated ノードに近い構成です。赤で示したコンテナ化された実行環境 ee は、ユーザージョブを実行する実行ノードだけでなく、管理系のジョブを実行するコントロールノードにもダウンロードされます。
[automationcontroller] aac00.example.com node_type=control peers=execution_nodes aac01.example.com node_type=control peers=execution_nodes aac02.example.com node_type=control peers=execution_nodes [execution_nodes] ee00.example.com node_type=execution ee01.example.com node_type=execution ee02.example.com node_type=execution ee03.example.com node_type=execution [database] db00.example.com ...以下略...
※ node_type でノード種別 control、execution、hop を明示的に指定します。
メッシュによるノード間接続に関しては、 peers で、『送信元側』に『接続先』として記述します。上記例ではコントロールノードに接続先として実行ノードを指定しています。上記例では、peers でグループ名 execution_nodes を接続先として指定していますがホスト個別での指定も可能です。
3. 『コントロールノード』と『実行ノード』を『ホップノード』で接続した例
ネットワークが多段に分離されている場合に有用な構成例です。ジョブ転送のみ行うホップノードを組み込んでいます。ホップノードはジョブ実行を行わないため実行環境のダウンロードは行われません。
[automationcontroller] aac00.example.com node_type=control peers=hop00.example.com,hop01.example.com aac01.example.com node_type=control peers=hop00.example.com,hop01.example.com aac02.example.com node_type=control peers=hop00.example.com,hop01.example.com [execution_nodes] hop00.example.com node_type=hop peers=ee00.example.com,ee01.example.com,ee02.example.com hop01.example.com node_type=hop peers=ee00.example.com,ee01.example.com,ee02.example.com ee00.example.com node_type=execution ee01.example.com node_type=execution ee02.example.com node_type=execution [database] db00.example.com ...以下略...
こちらは、peers でグループ名を使わずホスト個別に記述しています。
Isolated Node を含む AAP 1.2 環境のアップグレードの際の注意点
2022年4月時点（Ansible Tower 3.8.5-3 / AAP 2.1.1）で以下のことが分かっています。Isolated Node を含む、AAP 1.2 のアップグレードを行う際はご注意ください。
AAP 1.2 から AAP 2.1 へはインプレースアップグレードが出来るので、単純に考えると、Ansible Tower 3.8 + Isolated Node の構成を以下の様にアップグレードしたくなるかも知れません・・・、が、実はこのアップグレード、実行すると失敗します。つまり現時点では出来ません。
Ansible Tower 3.8 ---> AAP 2.1 ハイブリッドノード
Isolated Node ---> AAP 2.1 実行ノード
これは、AAP 1.2 の Isolated Node にインストールされている ansible-runner v1 から、AAP 2.1 の ansible-runner v2 へのアップグレードがサポートされていない、つまり失敗する事に起因する様です。
では、どうすれば良いかというと、AAP 2.1 の実行ノードを新規で準備（可能ならIsolated Node と同一ホスト名、IP アドレスで準備*）し、インプレースアップグレードを行えば OK です。以下のような感じです。
Ansible Tower 3.8 ---> AAP 2.1 ハイブリッドノード
新規 RHEL 8.4 or later ---> AAP 2.1 実行ノード
つまり、旧 Isolated Node はアップグレードホストとしては利用しない、という事ですね。
*アップグレードではインスタンスグループの情報も維持されるため、AAP 2.1 環境へのアップグレード後、インスタンスグループの再設定が不要で手間が省けます。
まとめ
今回、AAP 1.2 環境で、Isolated Nodeを利用している場合の移行方法と、AAP 2.1 注目の新機能、automation mesh についてご説明させていただきました。automation mesh は拡張性と管理性に優れた魅力的な機能を提供します。AAP 1.2 で Isolated Nodeをご利用の方は是非、AAP 2.1 の automation mesh に移行いただければと思います。♬
automation mesh の詳細については以下のマニュアルを参照ください。
