翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# コンテナワークロードを Azure Red Hat OpenShift (ARO) から Red Hat OpenShift Service on AWS (ROSA) に移行する
<a name="migrate-container-workloads-from-aro-to-rosa"></a>

*Amazon Web Services、Naveen Ramasamy、Srikanth Rangavajhala、および Gireesh Sreekantan*

## 概要
<a name="migrate-container-workloads-from-aro-to-rosa-summary"></a>

このパターンでは、Azure Red Hat OpenShift (ARO) から [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/) にコンテナワークロードを移行するためのステップバイステップの手順を説明します。ROSA は、Red Hat が と共同で提供するマネージド Kubernetes サービスです AWS。Kubernetes プラットフォームを使用してコンテナ化されたアプリケーションをデプロイ、管理、スケーリングするのに役立ちます。また、Red Hat の Kubernetes に関する専門知識と AWS クラウド インフラストラクチャの両方を活用できます。

ARO、他のクラウド、またはオンプレミスから ROSA にコンテナワークロードを移行するには、アプリケーション、設定、およびデータを、あるプラットフォームから別のプラットフォームに転送する必要があります。このパターンは、 AWS クラウド サービス、セキュリティ、コスト効率を最適化しながら、スムーズな移行を確保するのに役立ちます。ワークロードを ROSA クラスターに移行するための 2 つの方法として、CI/CD と Migration Toolkit for Containers (MTC) について説明します。

このパターンはどちらの方法にも当てはまります。移行プロセスの複雑さと確実性によって、選択する方法は異なります。アプリケーションの状態を完全に制御でき、パイプラインを通じて一貫したセットアップを確保できる場合は、CI/CD を使用することをお勧めします。ただし、アプリケーションの状態に不確実性、予期しない変更、または複雑なエコシステムが含まれる場合は、アプリケーションとそのデータを新しいクラスターに移行するため、信頼性の高い制御されたパスとして MTC を使用することをお勧めします。2 つの方法の詳細な比較については、「[追加情報](#migrate-container-workloads-from-aro-to-rosa-additional)」セクションを参照してください。

ROSA に移行するメリット:
+ ROSA はネイティブサービス AWS として とシームレスに統合されます。を通じて簡単にアクセス AWS マネジメントコンソール でき、単一の を通じて請求されます AWS アカウント。他の との完全な互換性 AWS のサービス を提供し、 AWS と Red Hat の両方からの共同サポートを提供します。
+ ROSA はハイブリッドデプロイとマルチクラウドデプロイをサポートします。これにより、オンプレミスのデータセンターや複数のクラウド環境にわたってアプリケーションを一貫して実行できるようになります。
+ ROSA は Red Hat のセキュリティ重視の恩恵を受けており、ロールベースのアクセス制御 (RBAC)、イメージスキャン、脆弱性評価などの機能を提供して、安全なコンテナ環境を確保します。
+ ROSA は、アプリケーションを簡単にスケールできるように設計されており、高可用性オプションを提供します。これにより、信頼性を維持しながら、必要に応じてアプリケーションを拡大できます。
+ ROSA は、手動のセットアップおよび管理方法と比較して、Kubernetes クラスターのデプロイを自動化して簡素化します。これにより、開発およびデプロイのプロセスが加速されます。
+ ROSA は AWS クラウド サービスからメリットを得ており、データベースサービス、ストレージソリューション、セキュリティサービスなどの AWS サービスとシームレスに統合できます。

## 前提条件と制限
<a name="migrate-container-workloads-from-aro-to-rosa-prereqs"></a>

**前提条件**
+ アクティブ AWS アカウント。
+  AWS のサービス その ROSA 用に設定されたアクセス許可は、機能を提供するために に依存します。詳細については、ROSA ドキュメントの「[Prerequisites](https://docs.aws.amazon.com/rosa/latest/userguide/set-up.html)」を参照してください。
+ [ROSA コンソール](https://console.aws.amazon.com/rosa)で有効になっている ROSA。手順については、[ROSA ドキュメント](https://docs.aws.amazon.com/rosa/latest/userguide/set-up.html#enable-rosa)を参照してください。
+ インストールおよび設定済みの ROSA クラスター。詳細については、ROSA ドキュメントの「[Get started with ROSA](https://docs.aws.amazon.com/rosa/latest/userguide/getting-started.html)」を参照してください。ROSA クラスターをセットアップするためのさまざまな方法を理解するには、 AWS 「規範ガイダンスガイド」の[「ROSA 実装戦略](https://docs.aws.amazon.com/prescriptive-guidance/latest/red-hat-openshift-on-aws-implementation/)」を参照してください。
+ オンプレミスネットワークから (推奨) または [AWS Direct Connect](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect.html) ([AWS Virtual Private NetworkSite-to-Site VPN)](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html) 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 のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」ページを参照して、サービスのリンクを選択します。

## アーキテクチャ
<a name="migrate-container-workloads-from-aro-to-rosa-architecture"></a>

ROSA は、パブリック、プライベート、[AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) の 3 つのネットワークデプロイパターンを提供します。Red Hat のサイト信頼性エンジニアリング (SRE) チームは、PrivateLink により、既存の VPC 内に存在するクラスターの PrivateLink エンドポイントに接続されたプライベートサブネットを使用してクラスターを管理できます。

PrivateLink オプションを選択すると、最も安全な設定が提供されます。そのため、機密性の高いワークロードや厳格なコンプライアンス要件の場合に使用することをお勧めします。パブリックとプライベートのネットワークデプロイオプションの詳細については、[Red Hat OpenShift ドキュメント](https://docs.openshift.com/rosa/architecture/rosa-architecture-models.html#rosa-hcp-architecture_rosa-architecture-models)を参照してください。

**重要**  
PrivateLink クラスターは、インストール時にのみ作成できます。インストール後に PrivateLink を使用するようにクラスターを変更することはできません。

次の図は、 がオンプレミス環境と ARO 環境への接続 Direct Connect に使用する ROSA クラスターの PrivateLink アーキテクチャを示しています。

![\[AWS Direct Connect と AWS PrivateLink を使用する ROSA クラスター。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/527cedfb-ec21-42be-bf21-d4e4e4f9db51/images/eff9b017-6fc7-4874-b610-849a42071ef4.png)


**AWS ROSA への アクセス許可**

ROSA へのアクセス AWS 許可については、存続期間の短い動的トークンで AWS Security Token Service (AWS STS) を使用することをお勧めします。この方法では、最小特権の事前定義されたロールとポリシーを使用して、 で運用するための最小限のアクセス許可を ROSA に付与し AWS アカウント、ROSA のインストール、コントロールプレーン、コンピューティング機能をサポートします。

**CI/CD パイプラインの再デプロイ**

CI/CD パイプラインの再デプロイは、成熟した CI/CD パイプラインを持つユーザーに推奨される方法です。このオプションを選択すると、任意の [DevOps デプロイ戦略](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/deployment-strategies.html)を使用して、アプリケーション負荷を ROSA 上のデプロイに徐々にシフトできます。

**注記**  
このパターンは、オンプレミスの Git、JFrog Artifactory、および Jenkins パイプラインがある一般的なユースケースを前提としています。このアプローチでは、オンプレミスネットワークから AWS までネットワーク接続を確立し Direct Connect、[エピック](#migrate-container-workloads-from-aro-to-rosa-epics)セクションの指示に従う前に ROSA クラスターを設定する必要があります。詳細については、「[前提条件](#migrate-container-workloads-from-aro-to-rosa-prereqs)」セクションを参照してください。

以下の図は、この方法のワークフローを示しています。

![\[CI/CD での移行方法を使用してコンテナを ARO から ROSA に移行します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/527cedfb-ec21-42be-bf21-d4e4e4f9db51/images/f658590e-fbd9-4297-a02c-0b516694d436.png)


**MTC での移行**

[Migration Toolkit for Containers (MTC)](https://docs.openshift.com/container-platform/4.13/migration_toolkit_for_containers/about-mtc.html)** **を使用すると、コンテナ化されたワークロードを ARO から ROSA へなど、さまざまな Kubernetes 環境間で移行することができます。MTC は、いくつかの重要なタスクを自動化し、移行ライフサイクルを管理するための包括的なフレームワークを提供することで、移行プロセスを簡素化します。

以下の図は、この方法のワークフローを示しています。

![\[MTC での移行方法を使用してコンテナを ARO から ROSA に移行します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/527cedfb-ec21-42be-bf21-d4e4e4f9db51/images/979bbc7b-2e39-4dd1-b4f0-ea1032880a38.png)


## ツール
<a name="migrate-container-workloads-from-aro-to-rosa-tools"></a>

**AWS のサービス**
+ [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html) は、 AWS ストレージサービスとの間でファイルまたはオブジェクトデータを移動するのに役立つオンラインデータ転送および検出サービスです。
+ [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) は、標準イーサネット光ファイバケーブルを介して内部ネットワークを Direct Connect ロケーションにリンクします。この接続を使用すると、ネットワークパスでインターネットサービスプロバイダーをバイパス AWS のサービス しながら、パブリックに直接仮想インターフェイスを作成できます。
+ [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) は、仮想プライベートクラウド (VPC) から他の VPC 内のサービスへの単方向のプライベート接続の確立に役立ちます。
+ [Red Hat OpenShift Service on AWS (ROSA)](https://docs.aws.amazon.com/rosa/latest/userguide/what-is-rosa.html) は、Red Hat OpenShift ユーザーがコンテナ化されたアプリケーションを構築、スケーリング、管理できるようにするマネージドサービスです AWS。
+ [AWS Security Token Service (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) は、ユーザーの権限が制限された一時的な認証情報をリクエストするのに役立ちます。

**その他のツール**
+ [Migration Toolkit for Containers (MTC)](https://docs.openshift.com/container-platform/4.13/migration_toolkit_for_containers/about-mtc.html) は、コンテナ化されたアプリケーションを ARO から ROSA に移行するためのコンソールと API を提供します。

## ベストプラクティス
<a name="migrate-container-workloads-from-aro-to-rosa-best-practices"></a>
+ [レジリエンス](https://docs.aws.amazon.com/ROSA/latest/userguide/disaster-recovery-resiliency.html)を確保するため、セキュリティコンプライアンスワークロードがある場合は、PrivateLink を使用するマルチ AZ ROSA クラスターをセットアップします。詳細については、[ROSA ドキュメント](https://docs.aws.amazon.com/rosa/latest/userguide/getting-started-classic-private-link.html)を参照してください。
**注記**  
インストール後に PrivateLink を設定することはできません。
+ レプリケーションリポジトリに使用する S3 バケットは、公開しないでください。適切な S3 バケットポリシーを使用してアクセスを制限します。
+ MTC での移行を選択した場合は、**[ステージ]** 移行オプションを使用して、カットオーバー中のダウンタイムウィンドウを短縮します。
+ ROSA クラスターをプロビジョニングする前と後で、サービスクォータを確認します。必要に応じて、要件に従ってクォータの引き上げをリクエストします。詳細については、[Service Quotas ドキュメント](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)を参照してください。
+ [ROSA セキュリティガイドライン](https://docs.aws.amazon.com/ROSA/latest/userguide/security.html)を確認し、セキュリティのベストプラクティスを実装します。
+ インストール後に、デフォルトのクラスター管理者を削除することをお勧めします。詳細については、[Red Hat OpenShift のドキュメント](https://docs.openshift.com/container-platform/4.13/post_installation_configuration/cluster-tasks.html)を参照してください。
+ マシンプールの自動スケーリングを使用して、ROSA クラスター内の未使用のワーカーノードをスケールダウンし、コストを最適化します。詳細については、「[ROSA Workshop](https://catalog.workshops.aws/aws-openshift-workshop/en-US/5-nodes-storage/3-autoscale-machine-pool)」を参照してください。
+ OpenShift Container Platform 向け Red Hat Cost Management サービスを使用すると、クラウドとコンテナのコストをよりよく理解し、追跡することができます。詳細については、「[ROSA Workshop](https://catalog.workshops.aws/aws-openshift-workshop/en-US/10-cost-management)」を参照してください。
+ を使用して、ROSA クラスターインフラストラクチャサービスとアプリケーションをモニタリングおよび監査します AWS のサービス。詳細については、「[ROSA Workshop](https://catalog.workshops.aws/aws-openshift-workshop/en-US/8-observability)」を参照してください。

## エピック
<a name="migrate-container-workloads-from-aro-to-rosa-epics"></a>

### オプション 1: CI/CD パイプラインを使用する
<a name="option-1-use-a-ci-cd-pipeline"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| 新しい ROSA クラスターを Jenkins に追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS 管理者、AWS システム管理者、AWS DevOps | 
| `oc` クライアントを Jenkins ノードに追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS 管理者、AWS システム管理者、AWS DevOps | 
| 新しい Git ブランチを作成します。 | `rosa-dev` 用の Git リポジトリに新しいブランチを作成します。このブランチは、ROSA のコードまたは設定パラメータの変更を既存のパイプラインから分離します。 | AWS DevOps | 
| ROSA のイメージにタグを付けます。 | ビルドステージでは、別のタグを使用して、ROSA パイプラインから構築されたイメージを識別します。 | AWS 管理者、AWS システム管理者、AWS DevOps | 
| パイプラインを作成する | 既存のパイプラインと同様の新しい Jenkins パイプラインを作成します。このパイプラインでは、前に作成した `rosa-dev` Git ブランチを使用して、既存のパイプラインと同じ Git チェックアウト、コードスキャン、ビルドステージを含めるようにしてください。 | AWS 管理者、AWS システム管理者、AWS DevOps | 
| ROSA デプロイステージを追加します。 | 新しいパイプラインで、ステージを追加して ROSA クラスターにデプロイし、Jenkins グローバル設定に追加した ROSA クラスターを参照します。 | AWS 管理者、AWS DevOps、AWS システム管理者 | 
| 新しいビルドを開始します。 | Jenkins で、パイプラインを選択して **[Build now]** を選択するか、Git の `rosa-dev` ブランチに変更をコミットして新しいビルドを開始します。 | AWS 管理者、AWS DevOps、AWS システム管理者 | 
| デプロイメントを確認する。 | **oc** コマンドまたは [ROSA コンソール](https://console.aws.amazon.com/rosa)を使用して、アプリケーションがターゲット ROSA クラスターにデプロイされていることを確認します。 | AWS 管理者、AWS DevOps、AWS システム管理者 | 
| ターゲットクラスターにデータをコピーします。 | ステートフルワークロードの場合は、 AWS DataSync または **rsync** などのオープンソースユーティリティを使用して、ソースクラスターからターゲットクラスターにデータをコピーするか、MTC メソッドを使用できます。詳細については、[AWS DataSync のドキュメント](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)を参照してください。 | AWS 管理者、AWS DevOps、AWS システム管理者 | 
| アプリケーションをテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS 管理者、AWS DevOps、AWS システム管理者 | 
| カットオーバーします。 | テストが成功した場合、適切な Amazon Route 53 ポリシーを使用して、トラフィックを ARO ホストアプリケーションから ROSA ホストアプリケーションに移動します。このステップを完了すると、アプリケーションのワークロードは ROSA クラスターに完全に移行されます。 | AWS 管理者、AWS システム管理者 | 

### オプション 2: MTC を使用する
<a name="option-2-use-mtc"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| MTC 演算子をインストールします。 | ARO クラスターと ROSA クラスターの両方に MTC 演算子をインストールします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS 管理者、AWS DevOps、AWS システム管理者 | 
| ネットワークトラフィックをレプリケーションリポジトリに設定します。 | プロキシサーバーを使用している場合は、レプリケーションリポジトリとクラスター間のネットワークトラフィックを許可するように設定します。レプリケーションリポジトリは、MTC がデータを移行する際に使用する中間ストレージオブジェクトです。移行中、ソースクラスターとターゲットクラスターはレプリケーションリポジトリにネットワークアクセスできる必要があります。 | AWS 管理者、AWS DevOps、AWS システム管理者 | 
| MTC にソースクラスターを追加します。 | MTC ウェブコンソールで、ARO ソースクラスターを追加します。 | AWS 管理者、AWS DevOps、AWS システム管理者 | 
| レプリケーションリポジトリとして Amazon S3 を追加します。 | MTC ウェブコンソールで、Amazon S3 バケット (「[前提条件](#migrate-container-workloads-from-aro-to-rosa-prereqs)」を参照) をレプリケーションリポジトリとして追加します。 | AWS 管理者、AWS DevOps、AWS システム管理者 | 
| 移行プランを作成します。 | MTC ウェブコンソールで、移行プランを作成し、データ転送タイプとして **[Copy]** を指定します。これにより、MTC はソース (ARO) クラスターから S3 バケットにデータをコピーし、バケットからターゲット (ROSA) クラスターにデータをコピーするように指示されます。 | AWS 管理者、AWS DevOps、AWS システム管理者 | 
| 移行プランを実行します。 | **[Stage]** または **[Cutover]** オプションを使用して、移行プランを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS 管理者、AWS DevOps、AWS システム管理者 | 

## トラブルシューティング
<a name="migrate-container-workloads-from-aro-to-rosa-troubleshooting"></a>


| 問題 | ソリューション | 
| --- | --- | 
| 接続の問題 | コンテナワークロードを 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 の新しいインフラストラクチャを反映し、コンテナのヘルスとパフォーマンスを継続的かつ効果的に監視できるようにします。 | 

## 関連リソース
<a name="migrate-container-workloads-from-aro-to-rosa-resources"></a>

**AWS**** のリファレンス**
+ [とは Red Hat OpenShift Service on AWS](https://docs.aws.amazon.com/ROSA/latest/userguide/what-is-rosa.html) (ROSA ドキュメント)
+ [Get started with ROSA](https://docs.aws.amazon.com/ROSA/latest/userguide/getting-started.html) (ROSA ドキュメント)
+ [Red Hat OpenShift Service on AWS 実装戦略](https://docs.aws.amazon.com/prescriptive-guidance/latest/red-hat-openshift-on-aws-implementation/) (AWS 規範ガイダンス)
+ [Red Hat OpenShift Service on AWS Now GA](https://aws.amazon.com/blogs/aws/red-hat-openshift-service-on-aws-now-generally-availably/) (AWS ブログ記事)
+ [ROSA Workshop](https://catalog.workshops.aws/aws-openshift-workshop/en-US/0-introduction)
+ [ROSA FAQ](https://aws.amazon.com/rosa/faqs/)
+ [ROSA Workshop FAQ](https://www.rosaworkshop.io/rosa/14-faq/)
+ [ROSA の料金](https://aws.amazon.com/rosa/pricing/)

**Red Hat OpenShift ドキュメント**
+ [にクラスターをすばやくインストールする AWS](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-default.html)
+ [制限されたネットワーク AWS での へのクラスターのインストール](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-restricted-networks-aws-installer-provisioned.html)
+ [既存の VPC AWS に クラスターをインストールする](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-vpc.html)
+ [CloudFormation テンプレート AWS を使用して のユーザープロビジョニングインフラストラクチャにクラスターをインストールする](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-user-infra.html)
+ [ユーザーがプロビジョニングしたインフラストラクチャを使用して制限されたネットワーク AWS にクラスターをインストールする](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-restricted-networks-aws.html)
+ [カスタマイズ AWS を使用した へのクラスターのインストール](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-customizations.html)
+ [Getting started with the OpenShift CLI](https://docs.openshift.com/container-platform/4.13/cli_reference/openshift_cli/getting-started-cli.html)

## 追加情報
<a name="migrate-container-workloads-from-aro-to-rosa-additional"></a>

**MTC と CI/CD パイプラインの再デプロイオプションを選択する**

ある OpenShift クラスターから別のクラスターにアプリケーションを移行するには、慎重に検討する必要があります。理想的には、CI/CD パイプラインを使用してアプリケーションを再デプロイし、永続ボリュームデータの移行を処理することで、スムーズな移行を行います。ただし、実際には、クラスター上で実行中のアプリケーションは、時間の経過とともに予期しない変更の影響を受けやすくなります。これらの変更により、アプリケーションが元のデプロイ状態から徐々に逸脱する可能性があります。名前空間の正確な内容が不明であり、すべてのアプリケーションコンポーネントを新しいクラスターにシームレスに移行することが重要であるシナリオの場合、MTC がソリューションを提供します。

適切な選択を行うには、特定のシナリオを評価し、各アプローチの利点を比較検討する必要があります。そうすることで、ニーズと優先順位に沿って、正常かつシームレスに移行できます。2 つのオプションから選択するための追加のガイドラインを以下に示します。

**CI/CD パイプラインの再デプロイ**

パイプラインを使用してアプリケーションを確実に再デプロイできる場合、推奨されるアプローチは CI/CD パイプラインの使用です。これにより、移行が制御されて予測可能になり、既存のデプロイ方法と一致するようになります。この方法を選択すると、[ブルー/グリーンデプロイ](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html)またはカナリアデプロイ戦略を使用して、ROSA のデプロイにロードを徐々にシフトできます。このシナリオでは、このパターンは、Jenkins がオンプレミス環境からアプリケーションデプロイをオーケストレーションしていることを前提としています。

利点:
+ ソース ARO クラスターへの管理アクセスは必要ありません。また、ソースクラスターまたはターゲットクラスターに演算子をデプロイする必要もありません。
+ このアプローチは、DevOps 戦略を使用することでトラフィックを徐々に切り替える場合に役立ちます。

欠点:
+ アプリケーションの機能をテストするには、より多くの労力が必要です。
+ アプリケーションに永続データが含まれている場合は、 AWS DataSync または他のツールを使用してデータをコピーするための追加のステップが必要です。

**MTC の移行**

実際には、実行中のアプリケーションに予期しない変更が発生し、初期のデプロイから逸脱してしまうことがあります。ソースクラスター上に存在するアプリケーションの現在の状態が不明な場合、MTC オプションを選択します。例えば、アプリケーションエコシステムがさまざまなコンポーネント、設定、データストレージボリュームにまたがっている場合、アプリケーションとその環境全体をカバーする完全な移行を確実に実行するには、MTC を選択することをお勧めします。

利点:
+ MTC は、ワークロードの完全なバックアップと復元を提供します。
+ ワークロードの移行中に、永続データをソースからターゲットにコピーします。
+ ソースコードリポジトリへのアクセスを必要としません。

欠点:
+ ソースクラスターとターゲットクラスターに MTC 演算子をインストールするには、管理者特権が必要です。
+ DevOps チームに、MTC ツールを使用して移行を実行するためのトレーニングが必要となります。