コンテナワークロードを Azure Red Hat OpenShift (ARO) から Red Hat OpenShift Service on AWS (ROSA) に移行する
Amazon Web Services、Naveen Ramasamy、Srikanth Rangavajhala、および Gireesh Sreekantan
概要
このパターンでは、Azure Red Hat OpenShift (ARO) から Red Hat OpenShift Service on AWS (ROSA)
ARO、他のクラウド、またはオンプレミスから ROSA にコンテナワークロードを移行するには、アプリケーション、設定、およびデータを、あるプラットフォームから別のプラットフォームに転送する必要があります。このパターンは、AWS クラウドサービス、セキュリティ、コスト効率を最適化しながらスムーズな移行を確保するのに役立ちます。ワークロードを ROSA クラスターに移行するための 2 つの方法として、CI/CD と Migration Toolkit for Containers (MTC) について説明します。
このパターンはどちらの方法にも当てはまります。移行プロセスの複雑さと確実性によって、選択する方法は異なります。アプリケーションの状態を完全に制御でき、パイプラインを通じて一貫したセットアップを確保できる場合は、CI/CD を使用することをお勧めします。ただし、アプリケーションの状態に不確実性、予期しない変更、または複雑なエコシステムが含まれる場合は、アプリケーションとそのデータを新しいクラスターに移行するため、信頼性の高い制御されたパスとして MTC を使用することをお勧めします。2 つの方法の詳細な比較については、「追加情報」セクションを参照してください。
ROSA に移行するメリット:
ROSA はネイティブサービスとして AWS とシームレスに統合されています。AWS マネジメントコンソールから簡単にアクセスでき、単一の AWS アカウントを通じて請求されます。他の AWS のサービスとの完全な互換性を提供し、AWS と Red Hat の両方からの連携サポートを提供します。
ROSA はハイブリッドデプロイとマルチクラウドデプロイをサポートします。これにより、オンプレミスのデータセンターや複数のクラウド環境にわたってアプリケーションを一貫して実行できるようになります。
ROSA は Red Hat のセキュリティ重視の恩恵を受けており、ロールベースのアクセス制御 (RBAC)、イメージスキャン、脆弱性評価などの機能を提供して、安全なコンテナ環境を確保します。
ROSA は、アプリケーションを簡単にスケールできるように設計されており、高可用性オプションを提供します。これにより、信頼性を維持しながら、必要に応じてアプリケーションを拡大できます。
ROSA は、手動のセットアップおよび管理方法と比較して、Kubernetes クラスターのデプロイを自動化して簡素化します。これにより、開発およびデプロイのプロセスが加速されます。
ROSA は AWS クラウドサービスの恩恵を受けており、データベースサービス、ストレージソリューション、セキュリティサービスなどの AWS サービスとシームレスに統合できます。
前提条件と制限
前提条件
アクティブな AWS アカウント。
ROSA が機能を提供するために依存する AWS のサービスに対して設定されたアクセス許可。詳細については、ROSA ドキュメントの「Prerequisites」を参照してください。
ROSA コンソール
で有効になっている ROSA。手順については、ROSA ドキュメントを参照してください。 インストールおよび設定済みの ROSA クラスター。詳細については、ROSA ドキュメントの「Get started with ROSA」を参照してください。ROSA クラスターをセットアップするためのさまざまな方法については、AWS 規範ガイダンスの「ROSA implementation strategies」を参照してください。
AWS Direct Connect (推奨) または AWS Virtual Private Network (Site-to-Site VPN) を介したオンプレミスのネットワークから AWS への確立済みネットワーク接続。
aws client、OpenShift CLI (oc) クライアント、ROSA クライアント、Git バイナリなどのツールをインストールするための Amazon Elastic Compute Cloud (Amazon EC2) インスタンスまたは別の仮想サーバー。
CI/CD での移行に関するその他の前提条件:
新しいパイプラインの作成、ステージの追加、OpenShift クラスターの追加、ビルドの実行を行うアクセス許可での、オンプレミスの Jenkins サーバーへのアクセス。
新しい Git ブランチを作成し、新しいブランチへのコミットを実行するアクセス許可での、アプリケーションのソースコードが維持されている Git リポジトリへのアクセス。
MTC での移行に関するその他の前提条件:
レプリケーションリポジトリとして使用される Amazon Simple Storage Service (Amazon S3) バケット。
ソース ARO クラスターへの管理アクセス。これは、MTC 接続をセットアップするために必要です。
機能制限
一部の AWS のサービスは、すべての AWS リージョンで利用できるわけではありません。各リージョンで利用できるサービスの詳細は、「AWS のサービス by Region
」をご確認ください。特定のエンドポイントについては、「Service endpoints and quotas」ページを参照して、サービスのリンクを選択してください。
アーキテクチャ
ROSA は、パブリック、プライベート、AWS PrivateLink の 3 つのネットワークデプロイパターンを提供します。Red Hat のサイト信頼性エンジニアリング (SRE) チームは、PrivateLink により、既存の VPC 内に存在するクラスターの PrivateLink エンドポイントに接続されたプライベートサブネットを使用してクラスターを管理できます。
PrivateLink オプションを選択すると、最も安全な設定が提供されます。そのため、機密性の高いワークロードや厳格なコンプライアンス要件の場合に使用することをお勧めします。パブリックとプライベートのネットワークデプロイオプションの詳細については、Red Hat OpenShift ドキュメント
重要
PrivateLink クラスターは、インストール時にのみ作成できます。インストール後に PrivateLink を使用するようにクラスターを変更することはできません。
次の図は、Direct Connect がオンプレミス環境と ARO 環境への接続に使用する ROSA クラスターの PrivateLink アーキテクチャを示しています。
ROSA に対する AWS のアクセス許可
ROSA に対する AWS のアクセス許可については、有効期間の短い動的トークンで AWS Security Token Service (AWS STS) を使用することをお勧めします。この方法では、最小特権の事前定義済みロールとポリシーを使用して、AWS アカウントで操作するための最小限のアクセス許可を ROSA に付与し、ROSA のインストール、コントロールプレーン、およびコンピューティング機能をサポートします。
CI/CD パイプラインの再デプロイ
CI/CD パイプラインの再デプロイは、成熟した CI/CD パイプラインを持つユーザーに推奨される方法です。このオプションを選択すると、任意の DevOps デプロイ戦略を使用して、アプリケーション負荷を ROSA 上のデプロイに徐々にシフトできます。
注記
以下の図は、この方法のワークフローを示しています。
MTC での移行
Migration Toolkit for Containers (MTC)
以下の図は、この方法のワークフローを示しています。
ツール
AWS のサービス
AWS DataSync は、ファイルまたはオブジェクトデータを AWS ストレージサービスとの間で移動したり、AWS ストレージサービス間で移動したりするのに役立つオンラインデータ転送および検出サービスです。
AWS Direct Connect は、お客様の内部ネットワークを Direct Connect ロケーションに、標準のイーサネット光ファイバーケーブルを介して接続するサービスです。この接続を使用すると、ネットワークパス内のインターネットサービスプロバイダーをバイパスしながら、パブリック AWS のサービスへの仮想インターフェイスを直接作成できます。
AWS PrivateLink は、仮想プライベートクラウド (VPC) から VPC 外のサービスへの一方向のプライベート接続を確立するのに役立ちます。
Red Hat OpenShift Service on AWS (ROSA) は、コンテナ化されたアプリケーションを Red Hat OpenShift ユーザーが AWS で構築、スケール、管理できるようにするマネージドサービスです。
AWS Security Token Service (AWS STS) を使用すると、ユーザー用の、権限が制限された一時的な認証情報をリクエストできます。
その他のツール
Migration Toolkit for Containers (MTC)
は、コンテナ化されたアプリケーションを ARO から ROSA に移行するためのコンソールと API を提供します。
ベストプラクティス
レジリエンスを確保するため、セキュリティコンプライアンスワークロードがある場合は、PrivateLink を使用するマルチ AZ ROSA クラスターをセットアップします。詳細については、ROSA ドキュメントを参照してください。
注記
インストール後に PrivateLink を設定することはできません。
レプリケーションリポジトリに使用する S3 バケットは、公開しないでください。適切な S3 バケットポリシーを使用してアクセスを制限します。
MTC での移行を選択した場合は、[ステージ] 移行オプションを使用して、カットオーバー中のダウンタイムウィンドウを短縮します。
ROSA クラスターをプロビジョニングする前と後で、サービスクォータを確認します。必要に応じて、要件に従ってクォータの引き上げをリクエストします。詳細については、Service Quotas ドキュメントを参照してください。
ROSA セキュリティガイドラインを確認し、セキュリティのベストプラクティスを実装します。
インストール後に、デフォルトのクラスター管理者を削除することをお勧めします。詳細については、Red Hat OpenShift のドキュメント
を参照してください。 マシンプールの自動スケーリングを使用して、ROSA クラスター内の未使用のワーカーノードをスケールダウンし、コストを最適化します。詳細については、「ROSA Workshop
」を参照してください。 OpenShift Container Platform 向け Red Hat Cost Management サービスを使用すると、クラウドとコンテナのコストをよりよく理解し、追跡することができます。詳細については、「ROSA Workshop
」を参照してください。 AWS のサービスを使用して ROSA クラスターインフラストラクチャサービスとアプリケーションをモニタリングおよび監査します。詳細については、「ROSA Workshop
」を参照してください。
エピック
| タスク | 説明 | 必要なスキル |
|---|---|---|
新しい ROSA クラスターを Jenkins に追加します。 |
| AWS 管理者、AWS システム管理者、AWS DevOps |
|
| AWS 管理者、AWS システム管理者、AWS DevOps |
新しい Git ブランチを作成します。 |
| AWS DevOps |
ROSA のイメージにタグを付けます。 | ビルドステージでは、別のタグを使用して、ROSA パイプラインから構築されたイメージを識別します。 | AWS 管理者、AWS システム管理者、AWS DevOps |
パイプラインを作成します。 | 既存のパイプラインと同様の新しい Jenkins パイプラインを作成します。このパイプラインでは、前に作成した | AWS 管理者、AWS システム管理者、AWS DevOps |
ROSA デプロイステージを追加します。 | 新しいパイプラインで、ステージを追加して ROSA クラスターにデプロイし、Jenkins グローバル設定に追加した ROSA クラスターを参照します。 | AWS 管理者、AWS DevOps、AWS システム管理者 |
新しいビルドを開始します。 | Jenkins で、パイプラインを選択して [Build now] を選択するか、Git の | AWS 管理者、AWS DevOps、AWS システム管理者 |
デプロイメントを確認する | oc コマンドまたは ROSA コンソール | AWS 管理者、AWS DevOps、AWS システム管理者 |
ターゲットクラスターにデータをコピーします。 | ステートフルワークロードの場合、AWS DataSync、または rsync などのオープンソースユーティリティを使用して、ソースクラスターからターゲットクラスターにデータをコピーするか、MTC での移行を行えます。詳細については、AWS DataSync のドキュメントを参照してください。 | AWS 管理者、AWS DevOps、AWS システム管理者 |
アプリケーションをテストする |
| AWS 管理者、AWS DevOps、AWS システム管理者 |
カットオーバーします。 | テストが成功した場合、適切な Amazon Route 53 ポリシーを使用して、トラフィックを ARO ホストアプリケーションから ROSA ホストアプリケーションに移動します。このステップを完了すると、アプリケーションのワークロードは ROSA クラスターに完全に移行されます。 | AWS 管理者、AWS システム管理者 |
| タスク | 説明 | 必要なスキル |
|---|---|---|
MTC 演算子をインストールします。 | ARO クラスターと ROSA クラスターの両方に MTC 演算子をインストールします。
| AWS 管理者、AWS DevOps、AWS システム管理者 |
ネットワークトラフィックをレプリケーションリポジトリに設定します。 | プロキシサーバーを使用している場合は、レプリケーションリポジトリとクラスター間のネットワークトラフィックを許可するように設定します。レプリケーションリポジトリは、MTC がデータを移行する際に使用する中間ストレージオブジェクトです。移行中、ソースクラスターとターゲットクラスターはレプリケーションリポジトリにネットワークアクセスできる必要があります。 | AWS 管理者、AWS DevOps、AWS システム管理者 |
MTC にソースクラスターを追加します。 | MTC ウェブコンソールで、ARO ソースクラスターを追加します。 | AWS 管理者、AWS DevOps、AWS システム管理者 |
レプリケーションリポジトリとして Amazon S3 を追加します。 | MTC ウェブコンソールで、Amazon S3 バケット (「前提条件」を参照) をレプリケーションリポジトリとして追加します。 | AWS 管理者、AWS DevOps、AWS システム管理者 |
移行プランを作成します。 | MTC ウェブコンソールで、移行プランを作成し、データ転送タイプとして [Copy] を指定します。これにより、MTC はソース (ARO) クラスターから S3 バケットにデータをコピーし、バケットからターゲット (ROSA) クラスターにデータをコピーするように指示されます。 | AWS 管理者、AWS DevOps、AWS システム管理者 |
移行プランを実行します。 | [Stage] または [Cutover] オプションを使用して、移行プランを実行します。
| AWS 管理者、AWS DevOps、AWS システム管理者 |
トラブルシューティング
| 問題 | ソリューション |
|---|---|
接続の問題 | コンテナワークロードを ARO から ROSA に移行する場合、移行を成功させるためには、解決する必要がある接続の問題が発生する可能性があります。移行中にこれらの接続の問題 (この表に記載) に対処するには、綿密な計画、ネットワークチームやセキュリティチームとの調整、徹底したテストが不可欠です。段階的な移行戦略を実装し、各ステップで接続を検証することで、潜在的な中断を最小限に抑え、ARO から ROSA へのスムーズな移行を実現できます。 |
ネットワーク設定の違い | ARO と ROSA では、仮想ネットワーク (VNet) 設定、サブネット、ネットワークポリシーなどのネットワーク設定が異なる場合があります。サービス間の適切な通信を行うには、ネットワーク設定が 2 つのプラットフォーム間で一致していることを確認してください。 |
セキュリティグループとファイアウォールルール | ROSA と ARO では、デフォルトのセキュリティグループとファイアウォールの設定が異なる場合があります。移行中にコンテナとサービス間の接続を維持する上で必要なトラフィックを許可するように、これらのルールを調整および更新してください。 |
IP アドレスと DNS の変更 | ワークロードを移行すると、IP アドレスと DNS 名が変更される場合があります。静的 IP または特定の DNS 名に依存するアプリケーションを再設定します。 |
外部サービスアクセス | アプリケーションがデータベースや API などの外部サービスに依存している状態では、場合によっては、ROSA の新しいサービスと通信できるように接続設定を更新する必要があります。 |
Azure Private Link の設定 | ARO で Azure Private Link またはプライベートエンドポイントサービスを使用する場合、リソース間のプライベート接続を確保するように ROSA で同等の機能をセットアップする必要があります。 |
Site-to-Site VPN または Direct Connect のセットアップ | オンプレミスネットワークと ARO の間に既存の Site-to-Site VPN または Direct Connect 接続がある場合、ローカルリソースとの通信が中断されないようにするには、ROSA と同様の接続を確立する必要があります。 |
Ingress とロードバランサーの設定 | Ingress コントローラーとロードバランサーの設定は、ARO と ROSA で異なる場合があります。これらの設定を再構成して、サービスへの外部アクセスを維持します。 |
証明書と TLS の処理 | アプリケーションで SSL 証明書または TLS を使用している場合、証明書が有効であり、ROSA で正しく設定されていることを確認します。 |
コンテナレジストリのアクセス | コンテナが外部コンテナレジストリでホストされている場合、ROSA に関する適切な認証とアクセス許可をセットアップします。 |
モニタリングとログ記録 | モニタリングとログ記録の設定を更新して、ROSA の新しいインフラストラクチャを反映し、コンテナのヘルスとパフォーマンスを継続的かつ効果的に監視できるようにします。 |
関連リソース
AWS のリファレンス
What is Red Hat OpenShift Service on AWS? (ROSA ドキュメント)
Get started with ROSA (ROSA ドキュメント)
Red Hat OpenShift Service on AWS implementation strategies (AWS 規範ガイダンス)
Red Hat OpenShift Service on AWS Now GA
(AWS ブログ記事)
Red Hat OpenShift ドキュメント
追加情報
MTC と CI/CD パイプラインの再デプロイオプションを選択する
ある OpenShift クラスターから別のクラスターにアプリケーションを移行するには、慎重に検討する必要があります。理想的には、CI/CD パイプラインを使用してアプリケーションを再デプロイし、永続ボリュームデータの移行を処理することで、スムーズな移行を行います。ただし、実際には、クラスター上で実行中のアプリケーションは、時間の経過とともに予期しない変更の影響を受けやすくなります。これらの変更により、アプリケーションが元のデプロイ状態から徐々に逸脱する可能性があります。名前空間の正確な内容が不明であり、すべてのアプリケーションコンポーネントを新しいクラスターにシームレスに移行することが重要であるシナリオの場合、MTC がソリューションを提供します。
適切な選択を行うには、特定のシナリオを評価し、各アプローチの利点を比較検討する必要があります。そうすることで、ニーズと優先順位に沿って、正常かつシームレスに移行できます。2 つのオプションから選択するための追加のガイドラインを以下に示します。
CI/CD パイプラインの再デプロイ
パイプラインを使用してアプリケーションを確実に再デプロイできる場合、推奨されるアプローチは CI/CD パイプラインの使用です。これにより、移行が制御されて予測可能になり、既存のデプロイ方法と一致するようになります。この方法を選択すると、ブルー/グリーンデプロイまたはカナリアデプロイ戦略を使用して、ROSA のデプロイにロードを徐々にシフトできます。このシナリオでは、このパターンは、Jenkins がオンプレミス環境からアプリケーションデプロイをオーケストレーションしていることを前提としています。
利点:
ソース ARO クラスターへの管理アクセスは必要ありません。また、ソースクラスターまたはターゲットクラスターに演算子をデプロイする必要もありません。
このアプローチは、DevOps 戦略を使用することでトラフィックを徐々に切り替える場合に役立ちます。
欠点:
アプリケーションの機能をテストするには、より多くの労力が必要です。
アプリケーションに永続データが含まれている場合は、AWS DataSync またはその他のツールを使用してデータをコピーする追加のステップが必要となります。
MTC の移行
実際には、実行中のアプリケーションに予期しない変更が発生し、初期のデプロイから逸脱してしまうことがあります。ソースクラスター上に存在するアプリケーションの現在の状態が不明な場合、MTC オプションを選択します。例えば、アプリケーションエコシステムがさまざまなコンポーネント、設定、データストレージボリュームにまたがっている場合、アプリケーションとその環境全体をカバーする完全な移行を確実に実行するには、MTC を選択することをお勧めします。
利点:
MTC は、ワークロードの完全なバックアップと復元を提供します。
ワークロードの移行中に、永続データをソースからターゲットにコピーします。
ソースコードリポジトリへのアクセスを必要としません。
欠点:
ソースクラスターとターゲットクラスターに MTC 演算子をインストールするには、管理者特権が必要です。
DevOps チームに、MTC ツールを使用して移行を実行するためのトレーニングが必要となります。
