OCIクラウド移行ガイドとは
オンプレミスやAWSなど、複数のプラットフォームからOracle Cloud Infrastructureへの移行プロジェクトに取り組んでいるクラウドエンジニア（@araidon,@kazunishi,@yama6,@tktk2712,@ritokuna,@nomu_kyou,@ora-777,@sshatari,@makoji,@miztana）による、OCI移行手順をまとめたシリーズ記事です。
各回、サンプルワークロードから対象サービスを取り上げ、移行手順をガイドいたします。
まとめ記事は以下になります。
移行するサービス：EC2
今回、移行対象とするのはAmazon EC2です。OSはAmazon Linux2023です。
過去、Amazon LinuxをOCI上で動かすためには、カスタムイメージを明示的に作成し、OCI側でそのイメージを指定してCompute VMを立ち上げる必要がありました。移行ガイドでも、この方式をCentOSで過去に検証しています。
今回は、2024年10月にGAされた、Oracle Cloud Migrations ServiceのAmazon EC2移行機能を利用し、Amazon Linuxを移行してみます。お手軽に移行可能なサービスです、とご紹介したいところですが、前提条件の作成や、移行フローを進める上で諸々詰まったところもあったので、そちらも含めてご紹介します。
一度うまくいけば、クセとコツを掴んでいただけるサービスではあると思います。
Oracle Cloud Migrations Service とは
Oracle Cloud Migrationsサービスは、VMware仮想マシンおよびAmazon Web Services (AWS) EC2インスタンスをOracle Cloud Infrastructure (OCI)コンピュートに移行するためのエンドツーエンドの包括的なセルフサービス・エクスペリエンスを提供します。
このサービスを使うと、AWS環境で自動的にインスタンスを検出し、そのデータをOCIにレプリケートできます。
AWS環境の認証情報をCloud Migrations Serviceの画面上で設定すれば、AWSのコンソール操作することなく、OCI側のコンソールでComputeの移行を実現することができます。
主要なワークフローは大きくわけて、下記3STEPから成り立ちます。
A. アセット管理：AWS環境との接続を確立し、移行対象のEC2を登録する。
B. 移行プロジェクトと移行プラン：ターゲットのインスタンスを設定し、ストレージをコピーする。
C. 移行の検証：ストレージとイメージからComputeVMを立ち上げ、接続を検証する。
これに加え、A. アセット管理を実行する前に「前提条件の作成」というフローが必要になります。本記事では、このステップに従って解説と検証を進めていきます。
どんな場面で利用できる？
本サービスを利用して起動したCompute VMのOSが、Oracleもしくは提供ベンダーからサポートされるのかという点ですが、公式ドキュメントにはサポートについて下記のように記載があります。
「Oracleの公式サポート・サービス(たとえば、Premier Support付きのOracle Linux)でカバーされているオペレーティング・システム・バージョン以外のバージョンでは、OCIによって、SSHを使用してインスタンスを起動およびアクセスできるように制限された、商業上合理的なサポートが提供されます。」
ここで言う「商業上合理的なサポート」とは、お客様のイメージ持ち込み作業をOracleがサポートすることを指し、OSがブートしてくるまでがサポート対象となります。つまり、所謂「OSサポート」を行うわけではなく、OS 自体のサポート契約にオラクルは関与しません。
つまり、Premier Supportの対象となるOracle Linuxを除いては、そのまま移行した状態では、OSはサポート対象外となります。ただし、お客様が特定のOSサポートベンダーと契約する、もしくはリポジトリをOCI Yum ServerにすることでサポートされるOSもあります。
OCI Compute VMにおけるサポート有無の詳細については下記をご参照ください。
よって、Cloud Migrations Serviceによる移行が適した条件は下記の通りとなります。
Cloud Migrations Serviceが移行に適した条件
- 移行対象のEC2が大量に存在するため、一括で移行して動作検証したい場合
- ベンダーからOSがサポートされなくても問題ない、塩漬けアプリケーションが移行対象の場合
- 別途OSサポートベンダーとの契約を結べるサーバーを移行対象とする場合
また、Amazon EC2からの移行で、Cloud Migrations Serviceに対応しているOSは下記の通りです。
| No | 対応するOS | OCI上でのサポート有無 |
|---|---|---|
| 1 | Amazon Linux 2 4.14/5.10 | サポートされない |
| 2 | Amazon Linux 2022 | サポートされない |
| 3 | Amazon Linux 2023 | サポートされない |
| 4 | CentOS 7/8/9 | サポートされる **1 |
| 5 | Clear Linux | サポートされる **2 |
| 6 | Debian 8 | サポートされる **2 |
| 7 | Debian 9/10/11/12 | サポートされる **2 |
| 8 | Oracle Linux 7/8/9 | Oracle社からサポートされる |
| 9 | RHEL 7/8/9 | RedHat社またはOracle社からサポートされる **3 |
| 10 | Rockey Linux | サポートされる **2 |
| 11 | SUSE Linux Enterprise Server 12 SP 1/2/3/4/5 | サポートされる **2 |
| 12 | SUSE Linux Enterprise Server 15 SP 1/2/3 | サポートされる **2 |
| 13 | Ubuntu 14.04/16.04/18.04/20.04/22.04/24.04 LTS | サポートされる **2 |
| 14 | Windows Server 2012 Standard/Datacenter | MS社からサポートされる **4 |
| 15 | Windows Server 2012 R2 Standard/Datacenter | MS社からサポートされる **4 |
| 16 | Windows Server 2016 Standard/Datacenter | MS社からサポートされる **4 |
| 17 | Windows Server 2019 Standard/Datacenter | MS社からサポートされる **4 |
| 18 | Windows Server 2022 Standard/Datacenter | MS社からサポートされる **4 |
**1：CentOS Streamを除き、リポジトリをOCI Yum Serverに変更することでOracle Linux Premier Supportを提供。
**2：お客様が別途OSサポートベンダーとサポート契約を結ぶことでサポート可能。
**3：RedHat社のサブスクリプション契約もしくは、更新の取得先をOCI Yum Serverに変更することでOracle Linux Premier Supportを提供。
**4：お客様がMicrosoft社とサポート契約を結ぶことでサポート可能
コンポーネント
OCM(Oracle Cloud Migrations Service)では、サービス固有のコンポーネント名がいくつか出てくること、また本サービスだけでリソースが完結しないため、検証しながら、公式ドキュメントや製品資料からOCMが扱うコンポーネントとOCIのリソースを整理しました。
概ね勘所は抑えていると思いますが、個人的な理解も入っているため、実際に検証を実施した上で、真偽をお確かめください。
全体像
リファレンスから読み解くと、Oracle Cloud Migrations Serviceが扱うコンポーネントは概ね下記のように整理されます。
ユニークな点としては、ユーザーのテナンシーだけでコンポーネントが完結せず、Oracle管理のOCB Tenancy, OCM Tenancyという2つのテナンシーを利用してサービスを構成している点です。
Oracle Cloud Migrations Serviceがユーザーテナンシー以外に扱うテナンシ
OCB Tenancy(Oracle Cloud Bridge Tenancy)はソース環境との接続を管理するためのテナンシ
OCM Tenancy（Oracle Cloud Migrations Tenancy）は移行プロジェクトを管理するためのテナンシ
上記のテナンシへのアクセス権は、後述する「前提条件の作成」でIAMリソースが作成されます。
前提条件の作成で作成されるリソース
OCMを実行するにあたり、ルート・コンパートメントにて、「前提条件の作成」を実行し、必要な権限や、サービスが扱うリソースを作成する必要があります。ひとつひとつ作成するのは骨が折れるので、コンソール画面からボタン押下し、リソース・マネージャを起動し、これらを作成していきます。
OCBテナンシとOCMテナンシを扱うために必要なIAMリソース、OCMが移行プロセスの中で利用する移行用のコンパートメント、AWS環境へ接続する際に使用する資格情報を格納するVault,Secretが作成されます。
A. アセット管理 で扱われるリソースとコンポーネント
移行対象として扱うコンポーネントの単位を「アセット」と呼びます。
移行対象とする環境、今回の場合はAWS上にあるEC2が「外部アセット」として扱われます。
外部アセットは、アセット検出によって外部ソースから抽出され、「インベントリ」という箱で管理されます。
アセット検出時、外部ソースに接続するための接続情報を「アセット・ソース」と呼びます。
B. 移行プロジェクトと移行プラン で扱われるリソースとコンポーネント
抽出されたアセットはインベントリに格納され、「インベントリ・アセット」と呼ばれます。
移行プロジェクトを作成する際に、インベントリから移行対象のアセットを選択します。このとき、「インベントリ・アセット」は「移行アセット」という名前に変わります。
移行アセットを基に、「移行プラン」を作成します。移行プランでは、OCI側で作成するCompute VMのShapeやスペックを決定します。これを「ターゲット・アセット」と呼びます。
アセットのレプリケートによって、ユーザーのテナンシーでHydration InstanceというCompute VMが一時的に起動され、移行アセットの情報を基に、EC2に紐づいているEBSに対してEBS Direct APIが実行され、データをレプリケートします。ここで作成されたBlock Volumeは、「Golden Volume」と呼ばれます。
C. 移行の検証 で扱われるリソースとコンポーネント
アセットのデプロイを行うと、リソース・マネージャが実行され、アセットのレプリケートで作成されたBoot Volumeを基に、インスタンスを作成します。再度Hydration Instanceが一時的に起動されます。
起動後、インスタンスに接続が検証できたら、「移行の完了」にチェックをつけて操作完了となります。
操作手順
1. 前提条件の作成
メニュー＞移行とディザスタ・リガバリ＞クラウド移行＞概要＞前提条件の作成
コンパートメントはルート・コンパートメントのまま操作します。
「前提条件の作成」ボタンを押下します。
スタック作成画面に遷移します。
「Oracle使用条件を確認した上でこれに同意します。」にチェックを付けます。
Nextボタンを押下します。
「変数の編集」に移動します。
| 画面項目 | 内容 |
|---|---|
| Migration Root Location | 作業コンパートメント (Migration および MigrationSecrets) が作成される親コンパートメント。 |
| Primary Prerequisite Stack | 作業コンパートメント、タグ名前空間、およびサービス ポリシーがすでにデプロイされている場合は、チェックを外します。（今回はデプロイされていないのでチェックを付けます。） |
| VMware 移行 | VMware 移行に必要なサービスポリシーを作成します。 |
| AWS EC2 移行 | AWS EC2 移行に必要なサービスポリシーを作成します。 |
| レプリケーション場所 | データ複製に使用する新しい Object Storage バケットを作成します。 |
| 移行サービス ユーザー グループ | 移行管理者と移行オペレーターの基本ポリシーを作成します。 |
| リモートエージェントアプライアンスのログを有効にする | リモート エージェント アプライアンスがログをアップロードできるようにするサービス ポリシーを作成します。 |
| ハイドレーションエージェントのログ記録を有効にする | Hydration エージェントがログをアップロードできるようにするサービス ポリシーを作成します。 |
注意点としては、VM移行のチェックボックスの選択が必要である点です。
EC2の移行を目的にしているため、EC2移行のチェックボックスだけでOKのようなUIをしていますが、VM移行にチェックを付けないまま後続のリソース・マネージャを実行すると下記エラーが出ます。
Error: Invalid index
on identity.tf line 668, in resource "oci_identity_policy" "remote_agent_logging"
668: "Endorse dynamic-group ${oci_identity_dynamic_group.remote_agent_dg[0].name} to { OBJECT_CREATE } in tenancy OCB-SERVICE"
├────────────────
│ oci_identity_dynamic_group.remote_agent_dg is empty tuple
The given key does not identify an element in this collection value: the collection has no elements.
理由としては、画面の仕様上、「VMware 移行」にチェックを付けないと、Oracle Cloud Bridge service tenancyのOCIDがリソース・マネージャの変数に反映されないためです。
他のリソースについても、VMware移行でのみ利用されるものもありそうでしたが、不要なエラーを出したくなかったこと、準備段階のリソースとして作成されてもデメリットがないため、一旦すべてにチェックを入れました。
Nextボタンを押下すると、スタックの作成 確認画面が出てきます。
「適用の実行」にチェックを入れて、作成ボタンを押下します。
リソース・マネージャのジョブの詳細画面に遷移し、Applyジョブが実行されます。
エラーになります。
OCM側で設定されたスタック内のTerraformファイルの記載に誤りのあるようなエラーが出ますが、ファイルは問題ありません。エラーの原因は、リソースの依存関係にあります。依存されるリソースが作成される前に、依存するリソースの作成処理が進んでしまい、エラーが出ます。
少し時間を置き、再度、ジョブを実行したおなじスタックの画面から、「適用」ボタンを押下します。
ジョブが成功します。
エラーが発生した、依存するリソースは作成されていない状況での再実行となりますが、僅差で依存される側のリソースが作成されるため、今度はエラーなくジョブが実行され、「前提条件の作成」で必要なリソースが作成されます。
今回は確認画面にて、「適用の実行」にチェックを入れて処理を進めました。未検証ですが、このチェックを外し、リソース・マネージャの画面に遷移して、リソース・マネージャーのパラレル度を下げて実行するとエラーは発生しないかもしれません。デフォルトでは、リソース・マネージャーのパラレル度（同時実行数）に10が設定されているところ、5など小さい値にして実行を試してみてください。
概要画面に戻ると、リソースが作成されたステータスとなっていることが確認できます。
また、リソース・マネージャ＞スタック＞スタック・リソース で画面遷移すると、作成されたリソースを確認できます。
「前提条件の作成」によって、合計39リソースが作成されました。（2025年2月28日現在）
2. AWS環境の準備
今回、移行対象とするAmazon Linux2023のイメージ概要は下記の通りです。
2-1. Virtioドライバを含むinitramfsの作成
移行に際し、事前にEC2側でVirtioドライバを含むinitramfsの作成が必要です。
これは、AWSはHVM(完全仮想化)に対し、OCIは準仮想化のため、ホストカーネルに接続するインターフェイスが異なるためです。
移行対象のAmazon Linux2023にSSH接続し、下記コマンドを実行します。
[ec2-user@ip-10-1-3-104 ~]$ uname -r
6.1.119-129.201.amzn2023.x86_64
[ec2-user@ip-10-1-3-104 ~]$ cat /etc/amazon-linux-release
Amazon Linux release 2023.6.20241212 (Amazon Linux)
[ec2-user@ip-10-1-3-104 ~]$ find /usr/lib | grep virtio_scsi
[ec2-user@ip-10-1-3-104 ~]$ sudo yum -y install kernel-modules-extra.x86_64
Last metadata expiration check: 1 day, 2:02:32 ago on Tue Jan 21 06:17:19 2025.Dependencies resolved.
・・・
Complete!
[ec2-user@ip-10-1-3-104 ~]$ find /usr/lib | grep virtio_scsi
/usr/lib/modules/6.1.119-129.201.amzn2023.x86_64/extra/drivers/scsi/virtio_scsi.ko
[ec2-user@ip-10-1-3-104 ~]$ sudo dracut -v -f --add-drivers "virtio virtio_pci virtio_scsi virtio_ring" /boot/initramfs-$(uname -r).img $(uname -r)
dracut[I]: Executing: /usr/bin/dracut -v -f --add-drivers "virtio virtio_pci virtio_scsi virtio_ring" /boot/initramfs-6.1.119-129.201.amzn2023.x86_64.img 6.1.119-129.201.amzn2023.x86_64
・・・
dracut[I]: *** Creating initramfs image file '/boot/initramfs-6.1.119-129.201.amzn2023.x86_64.img' done ***
Virtioドライバを設定するには、下記コマンドを実行してvirtio_scsiモジュールから設定すれば事足りるのですが、デフォルトではvirtio_scsiモジュールがインストールされていないため、インストールから実行しました。
sudo dracut -v -f --add-drivers "virtio virtio_pci virtio_scsi virtio_ring" /boot/initramfs-$(uname -r).img $(uname -r)
OCIの公式ドキュメントには、上記コマンド実行しか記載がないため、注意が必要です。
公式ドキュメントの記載は下記です。
Amazon Linux OS (Amazon Linux 2 v4.14、Amazon Linux 2 v5.10またはAmazon ECS-Optimized Linux 2 (AL2) AMI)を使用してEC2インスタンスをAWSからOCIに移行するには、レプリケーションの前に、Virtioドライバを含むinitramfsをEC2インスタンスで作成する必要があります。これを行うには、Amazon Linuxで次のコマンドを実行します。
sudo dracut -v -f --add-drivers "virtio virtio_pci virtio_scsi virtio_ring" /boot/initramfs-$(uname -r).img $(uname -r)
2-2. AWSの資格情報取得
AWSに接続するために資格情報が必要です。
今回は検証のため、管理者権限を持つユーザでアカウントにログインしました。
下記の通り、アクセスキーを作成します。
アクセスキー、シークレットアクセスキーをダウンロードします。
以上でAWS側の事前準備は完了です。
では、Oracle Cloud Migrations Serviceを実行していきましょう。
3. アセット管理
3-1. インベントリの作成
クラウド移行＞検出＞インベントリの作成 から、まずは、アセットを格納するためのコンポーネントである、「インベントリ」を作成します。
インベントリの作成 ボタンを押下すると、0%～100%まで実行ロード画面が表示され、インベントリが作成されます。インベントリ作成が完了すると、自動的にアセット・ソースの画面が表示されます。インベントリを一度作成すると、「検出」画面には戻れない画面仕様になっています。
（あまりにも速い作成だったため、画面キャプチャに失敗しました…）
3-2. アセット・ソースの作成
次に、AWS環境との接続情報を扱うためのコンポーネントである、「アセット・ソース」を作成します。
注意点としては、「前提条件の作成」で作成した移行用のコンパートメントに切り替えてから作成を行うことです。ここで別のコンパートメントで作業すると、のちに処理が失敗します。
クラウド移行＞検出＞アセット・ソース から、「アセット・ソースの作成」ボタンを押下します。
下記画面に遷移します。
各項目に値を設定していきます。
| 項目 | 設定値 |
|---|---|
| 名前 | アセット・ソース名（任意） |
| アカウントID | AWSのアカウントID |
| リージョン | ap-northeast-1（選択式） |
| コンパートメント | 現在のコンパートメント |
| ターゲット・コンパートメント | ターゲット・アセットを展開するコンパートメント(任意) |
| 項目 | 設定値 |
|---|---|
| 名前 | ソース環境名（任意） |
| コンパートメントに作成 | 移行用のコンパートメントを選択 |
| 項目 | 設定値 |
|---|---|
| 名前 | シークレット名（任意） |
| 説明オプション | （任意） |
| コンパートメントで選択 | Migration Secret コンパートメントを選択 |
| Migration Secretのボールト | ocm-secretを選択 |
| Migration Secretのマスター暗号化キー | ocm-key |
| アクセスキーID | 2-2.AWSの資格情報取得で取得した情報 |
| シークレット・アクセス・キー | 2-2.AWSの資格情報取得で取得した情報 |
| 項目 | 設定値 |
|---|---|
| レプリケーション資格証明オプション | 先ほど検出で作成した資格証明と同じものを使用するため、「検出資格証明の使用」を選択 |
| 検出スケジュール | 今回はスケジュールを利用しないため、「検出スケジュールなし」 |
| メトリック | 一旦なしで進める |
上記設定後、画面下の「アセット・ソースの作成」ボタンを押下します。
順次、アセット・ソースが作成されます。
作成が完了しました。
3-3. アセットの検出
AWSへの接続コンポーネントである「アセット・ソース」が作成できました。
「検出の実行」ボタンを押下し、AWS側の「外部アセット」を検出します。
検出がうまく行くと、下記のように作業リクエストが成功となります。
作業リクエストから、検出されたリソースを確認します。
EC2の仮想マシンと、EBSボリュームのメタデータが取得されていることがわかります。
クラウド移行 > インベントリ＞インベントリ・アセット の順でインベントリ・アセットの画面に移行すると、インベントリにアセットが登録されていることが確認できます。
4. 移行プロジェクトと移行プラン
4-1. 移行プロジェクトと移行プランの作成
移行対象のアセットがソース環境から検出できたので、移行プロジェクトと移行プランを作成してブートボリュームをコピーします。
クラウド移行＞移行プロジェクトに遷移し、「移行プロジェクトの作成」ボタンを押下します。
「移行の作成」ポップアップ画面にて、「初期移行プランを使用して移行プロジェクトを作成します」を選択すると、移行プランまで併せて作成する挙動になります。今回はこちらを選択します。
移行プロジェクトの作成画面に遷移します。
表示名に任意の値を入力し、コンパートメントに移行用のコンパートメントを選択します。
次へ ボタンを押下します。
アセット画面に遷移します。
「OCMインベントリから追加」ボタンを押下し、アセットの選択画面で、先ほど検出したEC2のアセットを選択します。選択後、「移行アセットの追加」ボタンを押下します。
レプリケーションの追加画面に遷移します。
画面右、「レプリケーション・バケット」のリスト右にある「選択」ボタンを押下し、「前提条件の作成」で作成したObject Storageを選択します。このObject StorageはAWS移行では使用しないリソースですが、OCMの仕様上、この項目に値が入っていないとエラーとなるため、便宜上入力します。
入力後、次へ ボタンを押下します。
初期移行プランの画面に遷移します。
ターゲットコンパートメントに任意のコンパートメントを指定します。
任意のターゲットコンパートメントに、予め作成したVCNとパブリックサブネットを指定します。
入力完了後、次へ ボタンを押下します。
確認画面に遷移します。
作成ボタンを押下します。
作成ボタン押下後、下記画面に遷移します。
移行プロジェクトの作成が完了すると、移行プランも作成されていることが確認できます。
ターゲット・アセット内の「使用中のシェイプ」がVM.Standard.E2.1.Micro に設定されていることがわかります。今回は VM.Standard.E4.Flexに変更してみます。
ターゲット・アセット画面のアクションから、構成を選択します。
ターゲット・アセットの一括構成から、シェイプを選択肢、VM構成から「システム構成の使用」を選択します。
「シェイプの変更」を選択し、AMDプロセッサを選択、"VM.Standard.E4.Flex"を選択します。
（そのうち、VM.Standard.E5.Flexを選択できるようになるはず…！）
補足
ターゲット・アセットの一括構成で、「サブネット」を選択し、設定したネットワークにパブリックIPアドレスを割り当てておきましょう。プライベートIPアドレスしか必要ないケースでは不要です。
選択が完了すると、確認画面に遷移します。
使用中のシェイプが"VM.Standard.E4.Flex"に変更されていることが確認できます。
プロパティの上書きを承諾するチェックボックスにチェックを入れ、「構成」ボタンを押下します。
移行プランの詳細画面から、ターゲット・アセットのサマリーが確認できます。
サマリーから、選択したシェイプの推定コスト/月を確認することができます。
4-2. アセットのレプリケート
クラウド移行＞移行プロジェクトから、移行プロジェクトの詳細画面に遷移し、レプリケートボタンを押下します。
確認のポップアップ画面が出てくるので、再度「レプリケート」ボタンを押下します。
30分くらい経過すると、レプリケートが完了します。
このレプリケートで作成された一時的なリソースを見ていきましょう。
コンピュート画面に遷移し、移行用のコンパートメントを選択します。
HydrationAgentと、vanilla-instanceという２つのインスタンスが作成されていることがわかります。
| リソース名 | 役割 |
|---|---|
| vanilla-instance | ブートボリュームを生成するためだけに起動され、ボリュームを生成できたらすぐに終了されるインスタンス |
| HydrationAgent | EBS Direct APIを実行し、ブートボリュームにEBSからデータを書き込むインスタンス |
どちらのインスタンスも、VM.Standard.E5.Flex, Oracle Linux 7.9で起動し、OCPU：1, Memory(GB)：12GBのスペックでした。これはサービス側で自動設定されるため、レプリケートするストレージの大きさや、ストレージの数でスケールアップするのかもしれません。
レプリケートによって生成された成果物を確認します。
移行用のコンパートメントを選択し、ブートボリュームを確認すると、G-から始まるボリュームが使用可能となっています。これが、ゴールデン・ボリュームと呼ばれる、このあと生成するCompute VMのブート・ボリュームです。
5. 移行の検証
最後に、レプリケートしたブート・ボリュームからインスタンスを作成します。
OCMの「アセットのデプロイ」をトリガに、リソース・マネージャ・スタックをApplyし、「アセットのレプリケート」で作成されたゴールデン・ボリュームから、指定したVCNに対してインスタンスを生成する流れになります。
5-1. ターゲット・アセットのデプロイ
クラウド移行＞移行プロジェクト＞詳細＞移行プラン＞移行プラン詳細 から、「RMSスタックの作成」のボタンを押下します。
RMSスタックの生成が完了すると、RMS（リソース・マネージャ・スタック）が作成されます。
移行は、OCMの画面とRMSの画面をそれぞれ別タブで開いて進めていくと、動きの理解が深まると思います。
「RMSスタックのデプロイ」ボタンが活性となるため、これを押下します。
押下すると、リソース・マネージャ側でジョブが動き出します。
RMSのジョブは30秒ほどで完了しました。
リソース・マネージャ＞スタック＞スタックの詳細＞Terraform構成のダウンロード から、このジョブで実行したTerraformファイルを確認してみます。
{
"output" : {
"ocid1_ocmtargetasset_oc1_ap-tokyo-1_amaaaaaa556ckoiavi7rn2fod3jhbgfizucrlaesbkfk3lbj65ys7ra4cjyq-id" : {
"value" : "${oci_core_instance.ocid1_ocmtargetasset_oc1_ap-tokyo-1_amaaaaaa556ckoiavi7rn2fod3jhbgfizucrlaesbkfk3lbj65ys7ra4cjyq.id}"
}
},
"resource" : {
"oci_core_instance" : {
"ocid1_ocmtargetasset_oc1_ap-tokyo-1_amaaaaaa556ckoiavi7rn2fod3jhbgfizucrlaesbkfk3lbj65ys7ra4cjyq" : {
"shape_config" : {
"ocpus" : 1.0,
"memory_in_gbs" : 8.0,
"baseline_ocpu_utilization" : "BASELINE_1_1"
},
"shape" : "VM.Standard.E4.Flex",
"availability_domain" : "CIgh:AP-TOKYO-1-AD-1",
"source_details" : {
"source_type" : "bootVolume",
"source_id" : "ocid1.bootvolume.oc1.ap-tokyo-1.abxhiljrmkoy7ztxpz2ps5adafynm4ctk22erbbqnfpmwntdbwmfofniqzvq"
},
"compartment_id" : "ocid1.compartment.oc1..aaaaaaaa36kjl3ncsgwhkdlpsqse6uam5ccnmopqlyfcpacbcpp6lci7veuq",
"freeform_tags" : {
"targetAssetName" : "postgre-test",
"targetAssetId" : "ocid1.ocmtargetasset.oc1.ap-tokyo-1.amaaaaaa556ckoiavi7rn2fod3jhbgfizucrlaesbkfk3lbj65ys7ra4cjyq"
},
"display_name" : "postgre-test",
"create_vnic_details" : {
"subnet_id" : "ocid1.subnet.oc1.ap-tokyo-1.aaaaaaaacifok62msxktzgcsj2wfjm6ttjwhxto2bjqw2jzqx5lbpkdtwlva",
"assign_public_ip" : true
}
}
}
}
}
shapeのプロパティで、ターゲット・コンパートメントで設定したVM.Standard.E4.Flexが設定されていることがわかります。
また、source_typeで、レプリケートして作成されたゴールデン・ボリュームが指定されていることがわかります。
5-2. 接続確認
では接続確認してみましょう。
接続手順
① AWSのCloudShellに保存してあるpemファイルをダウンロード
② OCIのCloud Shellにアップロード
③ 下記コマンドで接続。ユーザは “opc”ではなく、”ec2-user”であることに注意。
AWSから移行したAmazon Linux2023に接続できました！
5-3. 移行の完了
接続が確認できたところで、移行の完了をマークします。
クラウド移行＞移行プロジェクト から、「移行完了とマーク」ボタンを押下します。
以上で、OCMを利用したAmazon Linux2023の移行手順は終了です。
まとめ
サービスの仕様上、ハマりどころはありますが、コンポーネントやリソースなどの登場人物を把握した上で、一度成功させてしまえば、要領よく移行を進められると感じました。
AWSのEC2をそのまま持ってきたい場合、カスタムイメージの作成や、ボリュームのコピーなど明示的に必要な作業を抽象化して実施してくれるので、そのインスタンス数が多い場合などに役立つと思いました。
みなさまの移行作業の一助になれば幸いです。