Ansible Automation Platform 2で何が新しくなったのか：移行戦略の検討事項

Red Hat Ansible Automation Platform 2 は、アップデートされたアーキテクチャ、新しいツール、改良されながらも使い慣れたエクスペリエンスを自動化チームに導入します。しかし、現在のデプロイメントを Ansible Automation Platform 2 に移行するための計画と戦略には、いくつかの検討事項があります。

このドキュメントは、Ansible Automation Platform 移行のガイダンスの立案と実行を担当するすべてのステークホルダーに、その移行戦略において取り組むべき要素を示すガイドとなります。

このドキュメントで示されるアプローチは、あらゆる移行に対応するものではありません。それぞれの組織に特有な、さまざまな要素が、必須の取り組みや、これに関わるステークホルダー、そして納入プランに影響を及ぼすでしょう。

移行する前に検討するべきこと

私たちは、さまざまなニーズにそれぞれ特有の多くの要因が、移行に対する評価と計画に影響を及ぼすことを理解しています。このセクションでは、移行の準備ができているかどうか、また、どのようなアプローチが組織に最も適しているかを判断するための重要な要素について説明します。

現在の環境を評価

それぞれの環境に固有の設定があるであろうから、徹底的な技術評価を行うことが重要です。私たちは、以下を評価に盛り込むことを推奨します。

• 現在の Ansible Automation Platform の設定状況を分析し、現在のデプロイ・パターン、統合状況、移行に関連する複雑さなどを確認

• Ansible Automation Platform 2 の技術的要件を満たすために、環境に必要な変更を判定

• 移行の計画・実行に際して、ステークホルダーの準備状況を評価

• コンプライアンス、セキュリティポリシーの施行、監査の実施状況を確認

これをさらに深く掘り下げたい場合は、さらに以下の記事をご覧ください。

Ansible Automation Platform installation guide

Ansible Automation upgrade and migration guide

Migration Technical Considerations Checklist

もしも今すぐにすべての移行が実施できない場合は？

すべての移行が現時点では不可能な場合もあるかもしれません。しかし、Ansible Automation Platform 2 は、段階的なやり方で移行を行うことができます。この方法により、各チームは新しいツールに慣れ、移行時に必要なタスク数を減らすことが可能です。

以下の各タスクを評価し、もし実行可能であれば、Ansible Automation Platform 2 の完全なデプロイに備えてそれらを実装することをおすすめします。

これをさらに深く掘り下げたい場合は、さらに以下の記事をご覧ください。

Red Hat Ansible Platform Creator Guide

Ansible Builder Guide

Ansible Navigator Creator Guide

移行戦略の検討事項

評価を完了し、Ansible Automation Platform 2 への移行が可能であると判断します。

次は、アーキテクチャ、低レベルの設計、および配信計画を開発するフェーズへと進みます。このフェーズでは、検討事項に以下を盛り込むことを推奨します。

Ansibleコンテンツの移行

移行計画では、現在の Ansible 自動化コンテンツ（役割、コレクション、プレイブック、モジュールなど）を評価し、さらにそれぞれの Ansible Automation Platform 2 との互換性をテストする必要があります。

この評価には、少なくとも以下が含まれている必要があります。

• 自動化コンテンツをテストし、アップデートして、Ansible 2.9 以降をサポート

• 同梱コンテンツを含む Ansible Engine 2.9 vs Ansibleコアおよび認定/サポートされたCollection で比較しながら、それぞれを実行環境において使用して自動化を実行する技術的な検討事項

  • Ansible Engine 2.9 では、Ansible Content Collection への移行は不要。ただし、可及的速やかに Ansible Content Collection に移行することが推奨される

• Python 仮想環境（venvs）を立案・テストし、実行環境に移植

  • Ansible コンテンツを正常に実行するために必要な依存関係に基づいて、カスタム実行環境が必要かどうかを判定

  • Ansible Automation Platform 2 は、移行を支援するツールを提供する

• Collection のみのモデルへの移行や、使用しなくなったコンテンツの破棄など、既存の自動化コンテンツに対し、保持、リファクタリング、破棄を実施する

環境やオペレーティング・モデルへの統合

移行計画には、既存のシステムへの統合が含まれており、また、現在の運用モデルへの影響がある場合、それを評価する必要があります。計画に盛り込む推奨項目は以下の通りです。

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

• テスト、ステージ、最新、リリースの No. など、自分のモデルに適合するのは、どの実行環境コンテナのバージョンか？

• Ansible Content Collection のテスト、開発、本番用の個別のリポジトリなど、自動化ハブ（コンテナ・レジストリ）リポジトリ構造を決定

• ホスト型またはプライベートの自動化ハブ・インスタンスを使用する必要があるか？

プラットフォームの採用

• ステークホルダーがプラットフォームを採用して使用するために必要なサポートは何か？また、使用開始時の研修プロセスはどのようなものか？

• どのようなトレーニングと機能の有効化が必要か？

• 実行環境とコンテンツ・コレクションの管理は誰が担当するのか？この管理は、一元的になされるのか？それとも、ビジネスユニットごと、またはチームごとになされるのか？

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

• ansible-builder 定義ファイルをどのように管理・配布すればよいのか？

• 実行環境のアップデートと保護は、どのように実施すればよいのか？Common Vulnerabilities and Exposure（CVE）にパッチを適用し、コンプライアンス準拠を維持するには、どのようなセキュリティ対応計画を立てればよいか？

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

• どのように新しいクラスターをデプロイし、最低要件を提供すればよいか？

• クラスターをアップグレードする方法は？また、どのような頻度でアップグレードできるか？

• 非機能要件とは何か？これは設計にどう影響するのか？ 例として、バックアップ、コンフィグレーション管理、障害復旧（DR）、高可用性（HA）など

コンテンツ配信モデル

• クラスター展開を、複数にするか単一にするかの決定など、どのような自動化コントローラーの設計にするのが適切か？

• マルチジオ・シナリオでコンテンツを配布する方法は？

観測可能性、ロギング、およびメトリクス

• プラットフォームの正常性を判断するには、どのような指標を測定すればよいか？

• プラットフォームを監査できるようにするには、どのような変更が必要か？

• プラットフォームを既存のロギング・レポートシステムに統合する方法は？

参考文献：

Ansible Core Documentation

ブログ：What's new in Ansible Automation Platform 2: automation content navigator

ブログ：What's new in Ansible Automation Platform 2: private automation hub

次のステップ

• Ansible Automation Platform 2.0 の公式ドキュメントをご覧ください。

• また、今後公開予定の無料のウェビナー「Red Hat Ansible Automation Platform brings you a new way to automate」にご登録されることをおすすめします。これは、11月4日に生配信され、その後オンデマンドでご視聴いただけます。

• Red Hat は、上記の過程でお客様をご支援できるよう専門家によるガイダンスとサービスを提供します。詳細については、最寄りのRed Hat 担当者にお問い合わせください。