#はじめに
この記事は「Oracle Cloud Infrastructure（その2） Advent Calendar 2020」の12月24日の記事として投稿です。
メリークリスマス！！（イブッ）
ついに残すところ、あと１回。とりあえず、３日坊主にはならなかったです
そもそも無事に移行させることができるか…。今日の作業で準備ができるかにかかっています
。
さて、昨日からの続きです。今日から読む人たちのために、改めて、記載すると「今あるaws上のブログで使っているインスタンス2つをOCIへ移行させよう！そして、その先に待っているランニングコスト軽減を得るために！！」が目的になります。
今日は早速、移行先（OCI）にインスタンスを用意しようと思います。
#AWSからOCIへ移行をしてみる
昨日、計画した移行ステップは、下記の通り。
- OCI上でAWS同様の構成を用意する
- AWS と OCI を接続する（データ移行の経路を確保する）
- AWS上で稼働しているインスタンスのデータ抽出
- AWS から OCI へデータを転送する
- OCI環境で再構築（データ移行）する
今回は Oracle Cloud Infrastructure(OCI) の記事ではあるので、実際のブログ構築(WordPress)などは触れず、インフラ部分について記載します。ということで、今回は下記の赤いところについて触れていきます。
1. OCI上でAWS同様の構成を用意する
2. AWS と OCI を接続する（データ移行の経路を確保する）
3. AWS上で稼働しているインスタンスのデータ抽出
4. AWS から OCI へデータを転送する
5. OCI環境で再構築（データ移行）する
1. OCI上でAWS同様の構成を用意する
さて、OCI上で必要なサービスを用意してみます。早速、OCIへログインします。(https://www.oracle.com/jp/cloud/sign-in.html)
こちら先週開催していた Oracle Developer Days 期間中につくったので、トライアルクレジットとして55,000円をもらえていました
。Oracle主催のイベント時は特典
をもらえたりすることもあるので、興味がある方は Oracleのイベントなどもチェックしてみてください
さて、早速インスタンスを用意しようと思うのですが、今の OCI って簡単に構成できるようになっているので、今回の環境(Computeを外に向けて出すだけ）であれば、[VMインスタンスの作成]だけで作れてしまいます。とはいえ、あとで管理しづらくなるので、ちょっと仕分けしたいなぁ。ということで、コンパートメントを分けておこうと思います。
ここからは具体的な手順というよりかは、私が触っていった流れの紹介です
。
###コンパートメントを作成する
コンパートメントを分ける理由は、インスタンスの管理が楽になったりします。例えば、環境毎にアクセス管理をしたり、組織やチーム毎にアクセスできるリソースを分離したりなど。このあたりを大枠から制御するときに、コンパートメントを分けて管理すると運用が楽になります。今回は、この環境を触るのは私だけなので、とりあえず、AWSからの移行先としてまとめて管理したいので、１つコンパートメントを用意しました。
親コンパートメントとして[Blog]を用意して、子コンパートメントに[Production]（本番環境：フロントに立てるブログ）と[Development]（開発環境：機能拡張なり何かいじる環境）の2つを用意してみました。
ちょっとカッコよく？開発環境（Development）を用意してみましたけど、おそらく、今はProduction（本番環境）しか使わないと思います。気持ち（ノリ）は大事ということで…
###VCNの準備
次は、OCI上にBlog用のネットワークを用意します。（AWS でいう VPC になります）
コレがないと Compute の置き場がありませんので、用意する必要があります。
※Compute を作成するところからも VCN を用意することができますが、今回は VCN ウィザードから作成したいので、「仮想クラウド・ネットワーク」から「VCNウィザードの起動」をポチッとします。
ウィザードを選択すると、こんなメニューが表示されます。
移行するシステムはブログのため、外部（インターネット）から接続させたいので「インターネット接続性を持つVPN」を選択します。
ここで検討しないといけない情報は、VCN名とVCNのCIDRブロックぐらいです。
パブリック・サブネットとプライベート・サブネットのCIDRブロック、それと、DNS解決するかどうか。ぐらいが設定要素になります。あとは「作成」をポチッとして、しばらく待つとVCNの作成が完了します。
「ネットワークってなんだ？」という方でも、このウィザードがあれば簡単に作れます
VCNの画面に戻ると「インターネット接続性をもつVCN」が構成されています。ネットワーク構成はコレでOK！
###Computeの準備
クラウドリソースを管理するためのコンパートメント、ネットワークまで作成が完了したので、やっと AWS 上で稼働している EC２インスタンスの受け入れ先の Compute（無料枠）を用意したいと思います。
コンピュート・インスタンスの作成画面になりますので、「インスタンスの作成」をポチッとします。
そうすると、コンピュート・インスタンス作成画面になります。必須情報としては、特に難しい内容はありません。イメージを伝えたいので登録する情報を追っかけてみようと思います。
コンピュート・インスタンスの名前とコンパートメント選択がありましたので、そちらを登録、選択します。
[Configure placement and hardware]は、すでに無料提供のものを選択されているので、このままでもいいのですが、せっかくなので中身を見てみます。
展開すると、こんな画面になります。
2020年12月現在、東京リージョンには可用性ドメインは１つしかありませんので、他ドメインを選択することはありません。なお、フォルト・ドメインと呼ばれる可用性ドメイン内のハードウェアなどのインフラを共有するグループがありますが、こちらは明示的にドメインを指定することもできます。ただ今回は Compute １つだけで構成しているので、どこのフォルト・ドメインでも良いので選択しません（選択しない場合は、自動でどこかのフォルト・ドメインが選択されます）。
あとは、イメージの選択、並びに、シェイプの選択ができます。今回、無料枠は [VM.Standard.E2.1.Micro] 一択なので、こちらもそのまま。
次に「ネットワークの構成」と「SSHキーの追加」です。先に、SSHキーの追加の話をすると、用意しているSSHキーを使っても良いし、OCIにてSSHキーを作成することもできます。今回は、こちらで用意したSSHキーを登録します。
「ネットワーキングの構成」については展開すると、こんな感じです。
すでにVCNを作成しているので、先ほど作成したVCNの情報がデフォルトで選択されています。複数VCNを用意している場合は、利用したいVCNが設定されているか確認します。
あと、Blogサーバとして直接アクセスさせるので「パブリックIPアドレスの割当て」を選択します。
次に[Configure boot volume]の設定になります。
今回は、デフォルト（チェックなし）で進めます。これだけで Compute インスタンスの作成ができますが、せっかくなので「拡張オプション」も確認してみます。
「拡張オプション：管理」で設定できるのは、こちら。
初期化スクリプトや監視系の設定ができます。今回はデフォルトのままにします。
「拡張オプション：ネットワーキング」で設定できるのは、こちら。
プライベートIPやホスト名の設定ができます。こちらも今回は特に思いはないので、デフォルトのままにします。
「拡張オプション：イメージ」で設定できるのは、こちら。
今回はOSイメージでOL7.xを選択していますが、こちらの過去提供リリース（直近数件）を選択することができます。デフォルトは一番新しいものになります。これも、特に思いはないので、デフォルトのままにします。
「拡張オプション：Placement」で設定できるのは、こちら。
共有環境と専有環境の選択になりますが、こちらも共有環境でよいので、デフォルトのままにします。
拡張オプションを眺めてみましたが、今回はデフォルトにしましたので、コンピュート・インスタンスの作成でやったことはインスタンス名とSSHキーの登録ぐらいでした。非常に簡単だった。
さて、早速「作成」してみます。そうすると、コンピュート・インスタンスのプロビジョニングが始まります。
オレンジ色のアイコン中は、しばし待つと。。。
緑になり、インスタンス完成です。コンピュート・インスタンスの横に[Always Free]の文字が出ていますね。これで無料インスタンスを手に入れました！！
####もう一つ、Computeインスタンスの用意
こちらも同じようにインスタンスを用意しますが、今回は Lightsail（Wordpressを用意してくれるサービス）の移行先を作るのですが、せっかくなので、WordPressを構成しやすい KUSANAGI(CMS（Contents Management System）※パートナー提供のイメージ)を使ってみようと思います。
先ほど、OSイメージの選択で、イメージ変更を選択します。
ここで[パートナーイメージ]のタブを選択して[KUSANAGI for Oracle Cloud]を探します。
さあ！これで、できるかと思ったら・・・
あ、、、、。Always Free対象のインスタンスが使えない！！！。[KUSANAGI for Oracle Cloud]は、Intel のインスタンスでしか使えない様でした。KUSANAGI を使って WordPress の構築が楽になるかな？と期待していたのですが、仕方ありません。Always Free の Compute をもう１つ用意することにします。（Prime StrategyさんがAMDを対応してくれることを期待）
####Compute準備完了
下記の構成図にある Compute ２台準備完了。
VCN と Compute を用意したので、あとは、Object Storage を用意します。
###Object Storage の準備
最後は、ブログの画像データ格納先を用意します。メニューから[オブジェクト・ストレージ]-[オブジェクト・ストレージ]をポチッとします。
オブジェクト・ストレージの画面に遷移したら、[バケットの作成]をポチッとします。
バケットの作成では、バケット名ぐらいを設定します。あと、デフォルト・ストレージ層として標準（オブジェクト・ストレージ）とアーカイブ（アーカイブ・ストレージ）の選択ができますが、こちらは誤らないようにします。デフォルトは標準です。もちろん今回用意するのも「標準」になります。（※アーカイブ・ストレージは、すぐに取り出ししないような長期保存するようなデータを管理するときに向いています
）
特に難しいところはなく、これで作成できます。
####Object Storage準備完了
Blog-01 と Blog-02 のオブジェクト・ストレージが準備できました。
これで、AWS 上にあるサービスの代替（移行先）になるものを用意できました。
###AWSからOCIの受け皿完成
AWSから移行させるために必要なサービスは、すべて用意できました。長く書いてしまいましたが、やったことは、
１．コンパートメントを用意して、
２．そこにネットワークを構築して、
３．そのネットワーク上にComputeインスタンスを立てて、
４．Object Storageにバケットを用意
しただけです。
改めて、設定した状況を見直すと、こんな感じです。
####VCN
VCNはウィザードを利用して、サクッと用意
####Compute
無償で利用できるインスタンス２つ用意
####Object Storage
無償（10GBまで）で利用できるオブジェクト・ストレージを用意
OCI側の受け皿（移行先）としては、これで完成です。
#おわりに（その４）
ちょっと長くなってしまいましたけど、今日のお話は、ここまで。あとは、AWSからブログデータをOCIへ持ってきて構築すれば完成です。明日は aws から OCI へデータ転送の話を予定しています。