Ansible Automation Platform 2.6 へのアップグレードパスを計画する

Red Hat Ansible Automation Platform 2.6 のリリースは、重要なマイルストーンとなります。アップグレードを開始する前に、移行をよりスムーズにするために知っておくべき 3 つの重要なポイントがあります。

• Red Hat Ansible Automation Platform 2.6 は、RPM ベースのインストーラーを使用する最後のバージョンになります。RPM 方式を使用する Red Hat Ansible Automation Platform 2.6 は Red Hat Enterprise Linux (RHEL) 9 でのみ利用可能であり、RPM インストーラーの使用はこのリリース後に終了します。Ansible Automation Platform 2.7 は、コンテナ化されたインストール方法、Red Hat OpenShift operator、または当社のクラウドサービスのみをサポートするため、今こそ移行を開始するタイミングです。
• そのため、Ansible Automation Platform 2.6 は基盤となるリリースになります。プラットフォームの将来のバージョンへのすべてのアップグレードパスは、2.6 を経由する必要があります。これを回避する方法はありません。
• RHEL 8 はサポートされなくなりました。まだ RHEL 8 を使用している場合は、Ansible Automation Platform 2.6 にアップグレードする前に RHEL 9 (または RHEL 10) に移行する必要があります。

アップグレードの計画

Ansible Automation Platform 2.6 への移行を計画する際、アップグレード計画を策定する上で 2 つの重要な考慮事項があります。

一度に変更できるのは 1 つだけです。 基盤となるオペレーティングシステム (OS)、インストール方法、製品バージョンのいずれであっても、インストーラーは 1 回の実行につき 1 つの変更のみを処理します。つまり、インストーラーは複数回実行する必要がある場合があります。この仕組みの詳細については、公式ドキュメントを確認してください。

ほとんどの場合、新規インストールが必要になります。 同じアーキテクチャ上での 2.5 から 2.6 へのアップグレードや、特定の Red Hat OpenShift Operator のデプロイメントなど、いくつかの特定のシナリオを除き、新しい Ansible Automation Platform 2.6 インスタンスをデプロイしてから、構成をそこに移行する必要があります。

ここで、重要な疑問が生じます。つまり、既存の構成を新しいインスタンスにどのように取り込むかという点です。その答えは、Ansible Automation Platform の構成が PostgreSQL データベースに保存されていることを理解することから始まります。アップグレード戦略とは、そのデータをどのように移行させるかということです。

アップグレードへのアプローチ

Ansible Automation Platform 2.6 へのパスには、データベース中心の移行または API 中心の移行の 2 つがあります。適切な選択は、お客様の環境、要件、および何をトレードオフにするかによって決まります。

データベース中心のアプローチでは、Ansible Automation Platform を、データが信頼できる情報源であるステートフルなシステムとして扱います。API 中心のアプローチでは、プラットフォームを Configuration as Code (CaC) として扱い、信頼できる情報源は設定ファイルに存在します。各アプローチの技術的な検討事項を評価するには、以下の表を参照してください。

データベース中心の移行

データベース中心の移行は、アップグレードプロセスを通じてデータベース全体を保護し、移行する、文書化された完全にサポートされているパスです。これに関して考えられる課題としては、「アップグレードダンス」が挙げられます。RHEL 8 から RHEL 9 への移行、RPM からコンテナ化への移行、Ansible Automation Platform 2.4/2.5 から 2.6 への移行を行う場合がありますが、これらはそれぞれ独自のインフラストラクチャを必要とする別個のステップです。 

この場合、プロビジョニングと管理が必要な多くの中間環境が必要になる可能性があり、移行作業の開始点と最終目標、環境の規模 (つまり、データベースのサイズ) によっては、時間のかかるタスクになる可能性があります。

重要な注意点：この複雑さを避けるために Ansible Automation Platform のマネージドクラウドサービスを利用しようとする場合、データベースをマネージドサービスにアップロードするにはサポートチケットが必要になることに注意してください。このプロセスの詳細は、こちらに記載されています。これを各自で行う場合には、API 中心のアプローチを使用する必要があります。

API 中心の移行

このアプローチは Red Hat で正式にサポートされていません (ただし、この移行技術を可能にする個々のコンポーネントはサポートされています)。それでも、とくに大規模な環境では大幅に高速化できる可能性があります。ターゲットプラットフォームへの移行は一度だけで完了するため、中間的なインストールは必要ありません。

この方法では、API 呼び出しを使用して Ansible Automation Platform の設定をエクスポートし、設定ファイルや一時的なデータベースなどにローカルに設定を保存します。これらのファイルは必要に応じて変更し、API を介して別のプラットフォームで復元することもできます。この方法には、次のような便利な利点もあります。ワークフローに Configuration as Code (CaC) を導入し、CaC 手法を使用してプラットフォームを管理するための今後の基盤を提供します。

トレードオフとしては、ジョブ履歴が失われるため (外部のログアグリゲーターにより軽減されますが)、シークレットを注意深く扱う必要があります (外部のシークレットマネージャーにより軽減)。また、とくに private automation hub や Event-Driven Ansible オブジェクトの場合は、エクスポートした設定ファイルを編集して、インポート用に正しくフォーマットすることが必要になる場合もあります。

シークレットに関する注意事項

認証情報と通知のシークレットは設定データベースに保存され、データベースの SECRET_KEY によって暗号化されます。これらは暗号化されているため、その値は API を介してエクスポートされることはありません。したがって、設定のシークレットにアクセスするには、データベースサーバーへの root アクセスが必要です。これによりシークレットがプレーンテキストで公開されるため、シークレットを Ansible Vault に再暗号化するなど、細心の注意を払って取り扱う必要があります。 

ただし、HashiCorp Vault などの外部のシークレットマネージャーを使用している場合、それらのシークレットは Ansible Automation Platform 内に存在しないため、これは問題になりません。または、管理するシークレットが少ない場合は、新しいプラットフォームにシークレットを直接入力する方が簡単な場合もあります。

両方の方法についての検討事項

どのパスを選択する場合も、次の点に留意してください。外部統合と API トークンには注意が必要となる場合があります。 

Ansible Automation Platform 2.5 で導入された automation gateway は、automation controller、Ansible automation hub、および Event-Driven Ansible コントローラーを単一のインターフェースに接続する統合フロントエンドです。これにより、多くの API エンドポイントが新しいパスに移行しました。これらの統合エンドポイントの下位互換性はバージョン 2.6 で維持されていますが、今後のリリースではこれらを更新する必要があります。さらに、プラットフォームで発行されるほとんどのトークンを再生成して再配布する必要があり、追加のサーバーのプロビジョニングや、ロードバランサーの新しいゲートウェイサービスへの更新が必要になる場合があります。

外部で管理されているデータベース

外部で管理されているデータベースを使用しているお客様には、追加の考慮事項があります。  まず、Ansible Automation Platform 2.4 は Postgres 13 を使用します。これは 2.5 では Postgres 15 に、2.6 では PostgreSQL 15 にアップグレードされます。Ansible Automation Platform 2.6 では、お客様が提供する PostgreSQL 16 および 17 のデータベースもサポートしています。このデータベースのアップグレード手順は、移行と「アップデートダンス」における重要な考慮事項であり、お客様がこの更新プロセスを経ずに既存のデータベースを再利用できない主な理由です。  とくに Ansible Automation Platform 2.5 以降では、お客様が提供するデータベースで International Components for Unicode (ICU) を有効にする必要があります。これは EDB、Amazon Web Services Relational Database Service (AWS RDS)、Azure SQL Database など、ほとんどの主要なデータベースプロバイダーで利用可能ですが、デフォルトでは有効にされていません。このデータベースの互換性が、既存のデータベースのスキーマを更新するだけでは済まない理由です。

Playbook の互換性

Ansible Automation Platform をアップグレードすると、デフォルトの実行環境に同梱されている ansible-core のバージョンもアップグレードされます。幸いなことに、新しいバージョンのプラットフォーム上で常に古い実行環境を実行できるため、下位互換性は維持されますが、新しい機能やセキュリティ修正を利用するためにアップグレードすることを強くお勧めします。

実行環境をアップグレードすると、新しいバージョンの Ansible core にアップグレードされるため、いくつかの変更が生じる可能性があります。  想定される内容は以下のとおりです。

Ansible Automation Platform 2.4 から 2.6 への移行 (ansible-core 2.15 から 2.16 への移行)

これはマイナーアップグレードです。最も注目すべき変更点は、条件文の一部の警告がエラーとして扱われるようになったことです。それ以外の影響は最小限になることが見込まれます。

ansible-core 2.18 への移行 (Ansible Automation Platform 2.6 のオプションの実行環境) Ansible Automation Platform 2.6 のサポート対象であるオプションの実行環境として、このアップグレードは大幅な変更をもたらします。具体的には以下のとおりです。

• ターゲットノード上の Python 2.7 および 3.6 は、サポート対象のバージョンではなくなりました。つまり、この実行環境では RHEL 6 ホストをターゲットにできなくなります。RHEL 7 ホストを Ansible Automation Platform で自動化するには、Python 3.8 (Red Hat Software Collections から入手可能) が必要になります。
• Python 3.11 が、実行環境に含まれる Python バージョンになりました。カスタムおよびサードパーティの Python ライブラリは、3.11 と互換性のあるライブラリに更新する必要があります。
• Python の使われなくなったモジュール「dead batteries (デッドバッテリー）」のクリーンアップが進行中です。 PEP 594 により、今後の数回の Python リリースにおいて、メンテナンスされていないライブラリ、または安全でないま廃止されたライブラリが標準ライブラリから削除されます。非推奨の警告は Python 3.11 から始まります。一部のライブラリはバージョン 3.12 で削除され、バージョン 3.13 で一括削除が行われます。

大半のお客様にとって、これは差し迫った懸念事項ではありません。しかし、今後に整えるために、使用の終了に関する警告に留意してください。

サポートされている ansible-core バージョンの詳細については、Red Hat の公式サポートポリシーを参照してください。

Ansible Automation Platform 2.6 への移行は単なるバージョンアップデートではありません。これは次世代の自動化に備えるための戦略的な動きです。現在のインフラストラクチャに最適な移行パスを選択することで、自動化のレジリエンスを維持し、セキュリティを重視し、次に何が起きても対応できる状態を維持できます。

関連資料

• 記事： Python、AsyncIO、および一括操作による Ansible Automation Platform 2.6 アップグレードの自動化
• Ansible Automation Platform リリースノート 、およびドキュメント
• Ansible Automation Platform の新機能