Red Hat Ansible Automation Platform 2 への移行を準備するための 5 つの方法

Red Hat® Ansible® Automation Platform 2 ではアーキテクチャの更新、新たなツールの導入、自動化チーム向けエクスペリエンスの向上が行われています。Ansible Automation Platform 2 にスムーズに移行できるよう、移行戦略の計画にあたってはこのチェックリストで説明している考慮事項を確認してください。

環境ごとにその構成は異なるので、移行前に綿密な技術評価を行うことが極めて重要です。

• 現在の Ansible Automation Platform 1.x のインストールを分析し、現在のデプロイメントパターン、統合、移行によって生じる複雑さなどを確認します。
• Ansible Automation Platform 2 の技術要件を満たすために環境で必要な変更を特定します。
• 移行の計画と実行に対してステークホルダーの準備ができているかを評価します。
• コンプライアンス、セキュリティポリシーの適用、監査を確実に行います。 

Ansible Automation Platform 2 では、移行戦略に影響を与える新しい要件が導入されています。これらの要件を満たす上で多大な労力が必要になる場合は、移行の段階的アプローチを導入することをお勧めします。

• Automation controller 4 (Ansible Tower に代わるもの) は、PostgreSQL 12 のみをサポートします。PostgreSQL 10 には対応していません。
• Ansible Automation Platform 2 では、物理環境および仮想環境のインストールに Red Hat Enterprise Linux® 8 (x86_64) が必要です。
• Automation execution environment が Python 仮想環境の代わりに使用されます。
• Ansible Automation Platform 2 の移行ツールは、最新の Ansible Automation Platform 1.x バージョンをサポートします。
• Ansible Automation Platform 2 には、Playbook の互換性を確保するための Ansible Core 2.9 と、実行環境を介して提供される最新バージョンが含まれます。

移行計画においては、組織全体への影響を考慮する必要があります。次のことをお勧めします。

• 移行の初期コスト、継続的なコスト削減、および収益の増加の概要を示すコストベネフィット分析を行います。
• 外部および内部のステークホルダーを特定し、全員のスケジュールを押さえます。
• リスク分析を行い、ビジネスプロセスとサービス提供に対する影響を把握します。
• プロジェクトの時間枠、マイルストーン、成果物を決定します。
• ステークホルダーに必要な変更管理とトレーニングを評価します。
• 移行の成功基準とそれに必要な測定指標を設定します。

移行計画においては、Ansible Role、Ansible Content Collections、Ansible Playbook、各種モジュールなど、現在の Ansible Automation Platform コンテンツを評価し、Ansible Automation Platform 2 との互換性をテストする必要があります。この評価では、少なくとも次のことを行う必要があります。

• 自動化コンテンツをテストし、Ansible Core 2.9 以降に対応するように更新します。
• コンテンツをバンドルして Ansible Core 2.9 で自動化を実行する場合と、実行環境で Ansible Core および認定またはサポートされているコレクションを使用する場合の技術要件を検討します。
  • Ansible Content Collections への移行は Ansible Core 2.9 では必要ありませんが、可能な限り早期に移行することをお勧めします。
• Python 仮想環境 (venv) を計画し、テストし、実行環境に移植します。
  • Ansible コンテンツの正常な実行に必要な依存関係に基づいて、ユーザー作成の実行環境が必要かどうかを判別します。
  • Ansible Automation Platform 2 が提供する移行支援ツールを利用します。
  • Python 仮想環境から Automation execution environment への移行について詳細を確認します。
•  既存の自動化コンテンツを保持するか、リファクタリングするか、またはその使用を終了します (コレクションのみのモデルへの移行や、使用されなくなったコンテンツの使用の終了など)。

移行計画には、既存システムへの統合を含める必要があります。また、現在の運用モデルへの影響があれば、それも評価します。移行を計画する際は、以下のことを確認しましょう。

コンテンツ・プロモーション・ワークフロー

• 組織のモデルにはどのような Automation execution environment のバージョン管理が適していますか？(テスト、ステージ、最新、リリース番号など)
• 組織に最適な Automation Hub (コンテナレジストリ) リポジトリ構造はどれですか？(Ansible Content Collections のリポジトリをテスト、開発、およびプロダクション用に個別に用意するなど)
• Automation Hub インスタンスはホステッドとプライベートのどちらを使用するのがよいですか？このインスタンスは誰が管理しますか？

プラットフォームの導入

• 外部のステークホルダーがこのプラットフォームを導入し、使用するためには、どのようなサポートが必要ですか？
• すべてのステークホルダーの準備を整えるためには、どのようなトレーニングと支援が必要ですか？
• 実行環境とコンテンツコレクションの管理を担当するのは誰ですか？これは一元管理しますか、それとも事業単位で管理しますか？

実行環境のライフサイクル管理

• ansible-builder 定義ファイルはどのように管理し、配信しますか？
• 実行環境の更新とセキュリティ提供はどのように行いますか？Common Vulnerabilities and Exposures (CVE) にパッチを適用し、準拠を維持するためのセキュリティ対応計画はどのようなものですか？

プラットフォームのライフサイクル管理

• 新しいクラスタのデプロイと最小要件の対応はどのように実施しますか？
• クラスタのアップグレードはどのように行いますか？アップグレードの頻度はどのくらいですか？
• 機能以外の要件は何ですか？また、これは設計にどのように影響しますか？(バックアップ、構成管理、障害復旧 (DR)、高可用性 (HA) など)

詳細は、新たなリファレンス・アーキテクチャ：Red Hat Ansible Automation Platform 2.1 のデプロイについて参照してください。