OCIクラウド移行ガイドとは
オンプレミスやAWSなど、複数のプラットフォームからOracle Cloud Infrastructureへの移行プロジェクトに取り組んでいるクラウドエンジニア(@araidon,@kazunishi,@yama6)による、OCI移行手順をまとめたシリーズ記事です。
各回、サンプルワークロードから対象サービスを取り上げ、移行手順をガイドいたします。
まとめ記事は以下になります。
移行したいサンプルワークロード
日々の業務でよく目にするサービスを中心に、サンプルワークロードとしてまとめてみました。このシリーズでは、主にAWSからの移行を取り上げます。
このワークロードは、ユーザがログインして、Web上で写真を共有するWebサービスをイメージしています。
移行するサービス:Amazon VPC内のリソース群
今回は下記記事の続編として、VPCとVCNのDNS相互参照の手順をガイドします。
相互DNS参照(相互ドメイン名解決)は、異なるクラウドプラットフォームや異なるネットワーク環境において、複数のドメインやサービスがお互いに名前解決を行えるようにするための仕組みです。これにより、異なるクラウド環境やネットワーク間でのシームレスな通信や連携が可能になります。
移行方式
AWSのVPCとOCIのVCN間でプライベートDNSピアリング接続を作成します。
OCIでは、VCNから直接アクセス可能なプライベートDNSリゾルバが提供されています。
この機能により、異なるクラウドプラットフォームのDNSと連携し、DNSクエリの転送ルール(リゾルバ・ルール)に基づき名前解決を行うことができます。
作成後、AWSのプライベートサブネットにあるEC2と、OCIのプライベートサブネットにあるComputeVMのそれぞれが持つ内部FQDN(AWSで言うプライベートIP DNS名)に対してpingを送り合って相互参照を確認します。
前提条件
前提条件は、前述した記事でAWSとOCI間でVPN接続が確立されていることです。
IPアドレスはそのまま引き継いで記事を作成しているので、VPN接続から作成される方はご参照ください。
また、Amazon EC2,OCI ComputeVMのプライベートIPアドレスに対してpingが通ることを確認してください。
Amazon EC2→OCI Compute
[ec2-user@ip-10-1-1-66 ~]$ ping 10.2.1.214
PING 10.2.1.214 (10.2.1.214) 56(84) bytes of data.
64 bytes from 10.2.1.214: icmp_seq=1 ttl=61 time=5.23 ms
64 bytes from 10.2.1.214: icmp_seq=2 ttl=61 time=5.03 ms
64 bytes from 10.2.1.214: icmp_seq=3 ttl=61 time=5.09 ms
64 bytes from 10.2.1.214: icmp_seq=4 ttl=61 time=5.12 ms
64 bytes from 10.2.1.214: icmp_seq=5 ttl=61 time=6.56 ms
OCI Compute→Amazon EC2
[opc@toaws-instance ~]$ ping 10.1.1.66
PING 10.1.1.66 (10.1.1.66) 56(84) bytes of data.
64 bytes from 10.1.1.66: icmp_seq=1 ttl=125 time=4.89 ms
64 bytes from 10.1.1.66: icmp_seq=2 ttl=125 time=5.24 ms
64 bytes from 10.1.1.66: icmp_seq=3 ttl=125 time=4.73 ms
64 bytes from 10.1.1.66: icmp_seq=4 ttl=125 time=4.89 ms
64 bytes from 10.1.1.66: icmp_seq=5 ttl=125 time=4.93 ms
移行手順
- ドメイン名の確認
- OCI Private DNSリゾルバの設定
- Amazon Route 53 Resolverの設定
- OCI Private DNS リゾルバ・ルールの設定
- Amazon Route 53 リゾルバ・ルールの設定
- OCIセキュリティリストとAWS セキュリティグループの設定
- 疎通確認
1. ドメイン名の確認
のちの設定、疎通確認で必要となるリソースのドメイン名を確認します。
1-1. VPCとVCNのDNS ドメイン名確認
まずは、AWS,OCIそれぞれで仮想ネットワークのDNS名を確認します。
1-1-1. VPCのDNS ドメイン名確認
VPCの画面から、DHCP オプションセットをクリックします。
domain-nameを確認します。
ここに表示されるドメイン "ap-northeast-1.compute.internal" が、VPCのDNSドメインになります。
米国東部(バージニア北部)リージョンでは、domain-nameが"ec2.internal"になります。
1-1-2. VCNのDNS ドメイン名確認
ネットワーキング>仮想クラウド・ネットワークから、仮想クラウド・ネットワークの詳細画面に遷移します。
DNSドメイン名を確認します。
ここに表示されるドメイン "testvcn.oraclevcn.com" が、VCNのDNSドメイン名になります。
1-2. Computeリソースのドメイン名確認
次に、Computeリソースのドメイン名を確認します。
本トピックの最後に、DNS設定前にホスト名(FQDN)での接続ができない状態であることを確認します。
1-2-1. Amazon EC2のドメイン名確認
EC2>インスタンスから、インスタンス概要画面に遷移します。
プライベートIP DNS名を参照します。
1-2-2. OCI Computeリソースのドメイン名確認
コンピュート>インスタンスから、インスタンスの詳細画面に遷移します。
内部FQDNの表示ラベルをクリックし、表示されたドメイン名を確認します。
それぞれのドメイン名に対してpingコマンドを実行します。
Amazon EC2→OCI Compute
[ec2-user@ip-10-1-1-66 ~]$ ping toaws-instance.testprisubnet.testvcn.oraclevcn.com
ping: toaws-instance.testprisubnet.testvcn.oraclevcn.com: Name or service not known
OCI Compute→Amazon EC2
[opc@toaws-instance ~]$ ping ip-10-1-1-66.ap-northeast-1.compute.internal
ping: ip-10-1-1-66.ap-northeast-1.compute.internal: Name or service not known
どちらも"Name or service not known"と表示され、ホスト名では疎通ができないことがわかります。
2. OCI Private DNSリゾルバの設定
Private DNSリゾルバを設定していきます。
VCNの詳細画面から、DNSリゾルバのラベルをクリックします。
プライベート・リゾルバの詳細画面に遷移します。
画面左の「リソース」から、「エンドポイント」を押下します。
エンドポイントの画面に遷移します。
「エンドポイントの作成」ボタンを押下します。
すると、画面右にエンドポイント作成画面が表示されます。
ここから、DNS相互参照するVCN内のサブネットに下記の2つのエンドポイントを作成していきます。
エンドポイント | 役割 |
---|---|
リスナー | VCNのプライベートDNSドメイン名に対する外部リクエストをリスニングする |
フォワーダー | 内部リソースから外部プライベートDNSドメイン名にリクエストを転送する |
詳細は、公式ドキュメントのリゾルバ・エンドポイントのページをご参照ください。
2-1. リスナー(リスニング)エンドポイントの作成
リスナーを作成していきます。
名前を入力し、対象のプライベートサブネットを選択します。
エンドポイント・タイプで「リスニング」を選択します。
2-2. フォワーダー(転送)エンドポイントの作成
名前を入力し、対象のプライベートサブネットを選択します。
エンドポイント・タイプで「転送」を選択します。
リスナー、フォワーダー双方のエンドポイントが作成されました。
3. Amazon Route 53 Resolverの設定
次に、AWSでもエンドポイントを作成していきます。
AWSでは、DNSサービスであるRoute 53を用いて設定していきます。
Route 53のサービスページに遷移した後、左上のハンバーガーメニューから、「リゾルバー」の「インバウンドエンドポイント」、「アウトバウンドエンドポイント」にそれぞれ遷移します。
3-1. インバウンドエンドポイントの作成
遷移後、「インバウンドエンドポイントの作成」ボタンを押下します。
インバウンドエンドポイントの作成画面が表示されます。
下記の通り、項目を入力、選択していきます。
入力後、「インバウンドエンドポイントの作成」ボタンを押下します。
IDラベルをクリックすると、この操作で作成されたIPアドレスが表示されます。
3-2. アウトバウンドエンドポイントの作成
同様に、アウトバウンドエンドポイントを作成していきます。
「アウトバウンドエンドポイントの作成」ボタンを押下します。
下記の通り、項目を入力、選択していきます。
入力後、「アウトバウンドエンドポイントの作成」ボタンを押下します。
IDラベルをクリックすると、この操作で作成されたIPアドレスが表示されます。
課金注意
Amazon Route 53 リゾルバーエンドポイントは、0.125USD ENI / 時間で課金が発生します。
https://aws.amazon.com/jp/route53/pricing/
インバウンド、アウトバウンドでそれぞれ4つのエンドポイントを作成したため、1時間当たり0.5USDの課金となり、1日で12USDほどになります。
検証用途で作成される方は、無駄な課金を防ぐために速やかな削除を推奨します。
なお、OCIのエンドポイントは無償で提供されています。
4. OCI Private DNS リゾルバ・ルールの設定
前章までで、それぞれのクラウドにおいてエンドポイントを作成しました。
これらを使って、転送ルールであるリゾルバ・ルールを設定していきます。
まずは、OCIから設定していきます。
さきほど「OCI Private DNSリゾルバの設定」で表示した「プライベート・リゾルバの詳細」画面の、左下「リソース」から「ルール」を選択します。
「ルールの管理」ボタンを押下します。
下記の内容を設定します。
項目 | 入力内容 |
---|---|
ルール条件 | ドメイン |
ドメイン | ap-northeast-1.compute.internal(「1-1-1. VPCのDNS ドメイン名確認」で確認したVPCのFQDN) |
ソース・エンドポイント | AWSForwarder(「2-2. フォワーダー(転送)エンドポイントの作成」で作成したフォワーダー) |
宛先IPアドレス | 「3-1. インバウンドエンドポイントの作成」で生成されたインバウンドエンドポイントのIPアドレス(どちらかひとつ) |
「変更の保存」ボタンを押下します。
すると、下記のようにルールが作成されます。
設定した内容をざっくりご説明すると、VPCのFQDNに対して、OCIのフォワーダーから、AWSのインバウンドエンドポイントを通ってDNSクエリを転送するよというものです。
5. Amazon Route 53 リゾルバ・ルールの設定
次に、AWS側でも転送ルール(リゾルバ・ルール)を設定していきます。
左上のハンバーガーメニューから、「リゾルバー」の「ルール」に遷移します。
「ルールの作成」のボタンを押下します。
「送信」ボタンを押下します。
新しいルールが正常に作成されました。
6. OCIセキュリティリストとAWS セキュリティグループの設定
VPC,VCNそれぞれのセキュリティグループ、セキュリティリストのインバウンドで53番ポート、UDP,TCPプロトコルを通す設定を行う必要があります。
6-1. AWSのインバウンド設定
疎通を行うEC2からセキュリティグループに遷移します。
AWS側での設定は下記のとおりです。
今回、pingを使用した疎通を行うためICMPプロトコルを許可しています。
また、ポート範囲53で、UDP,TCPを許可しています。
6-2. OCIのインバウンド設定
疎通を行うVCNからセキュリティリストに遷移します。
OCI側での設定は下記のとおりです。
AWSのVPC(10.1.0.0/16)から、ICMPプロトコル、宛先ポート53でUDP,TCPを許可しています。ルールの追加は、「イングレスルールの追加」から行ってください。
7. 疎通確認
では最後に、疎通確認を行います。
それぞれCloud shellからプライベートサブネット上のインスタンスにログインし、「1-2. Computeリソースのドメイン名確認」で確認したインスタンスのFQDN(ホスト名)にpingコマンドを実行します。
AWS→OCI
[ec2-user@ip-10-1-1-66 ~]$ ping toaws-instance.testprisubnet.testvcn.oraclevcn.com
PING toaws-instance.testprisubnet.testvcn.oraclevcn.com (10.2.1.214) 56(84) bytes of data.
64 bytes from ip-10-2-1-214.ap-northeast-1.compute.internal (10.2.1.214): icmp_seq=1 ttl=61 time=5.22 ms
64 bytes from ip-10-2-1-214.ap-northeast-1.compute.internal (10.2.1.214): icmp_seq=2 ttl=61 time=5.33 ms
64 bytes from ip-10-2-1-214.ap-northeast-1.compute.internal (10.2.1.214): icmp_seq=3 ttl=61 time=5.35 ms
64 bytes from ip-10-2-1-214.ap-northeast-1.compute.internal (10.2.1.214): icmp_seq=4 ttl=61 time=5.23 ms
64 bytes from ip-10-2-1-214.ap-northeast-1.compute.internal (10.2.1.214): icmp_seq=5 ttl=61 time=5.36 ms
OCI→AWS
[opc@toaws-instance ~]$ ping ip-10-1-1-66.ap-northeast-1.compute.internal
PING ip-10-1-1-66.ap-northeast-1.compute.internal (10.1.1.66) 56(84) bytes of data.
64 bytes from 10.1.1.66 (10.1.1.66): icmp_seq=1 ttl=125 time=5.45 ms
64 bytes from 10.1.1.66 (10.1.1.66): icmp_seq=2 ttl=125 time=5.48 ms
64 bytes from 10.1.1.66 (10.1.1.66): icmp_seq=3 ttl=125 time=5.39 ms
64 bytes from 10.1.1.66 (10.1.1.66): icmp_seq=4 ttl=125 time=5.21 ms
64 bytes from 10.1.1.66 (10.1.1.66): icmp_seq=5 ttl=125 time=5.46 ms
疎通確認結果
AWS→OCI | OCI→AWS |
---|---|
8.まとめ
異なるクラウド間で相互DNS参照を設定することで、動的なIPアドレスを持つプライベートリソースに対して、リソースのホスト名を接続先に指定して、セキュアなアクセスを実現できます。
移行作業を行う上でも、相互のクラウド間でホスト名指定によるリソースの通信が役立つことがあります。
マルチクラウド構成の実現、移行作業を行う上でこの記事が一助になりましたら幸いです。
参考記事