オレのブログを安く運用したい。（aws から Oracle Cloud へ移行（その４））

はじめに

この記事は「Oracle Cloud Infrastructure（その2） Advent Calendar 2020」の12月24日の記事として投稿です。

メリークリスマス！！（イブッ）ついに残すところ、あと１回。とりあえず、３日坊主にはならなかったですそもそも無事に移行させることができるか…。今日の作業で準備ができるかにかかっています。

さて、昨日からの続きです。今日から読む人たちのために、改めて、記載すると「今あるaws上のブログで使っているインスタンス2つをOCIへ移行させよう！そして、その先に待っているランニングコスト軽減を得るために！！」が目的になります。

今日は早速、移行先（OCI）にインスタンスを用意しようと思います。

AWSからOCIへ移行をしてみる

昨日、計画した移行ステップは、下記の通り。

1. OCI上でAWS同様の構成を用意する
2. AWS と OCI を接続する（データ移行の経路を確保する）
3. AWS上で稼働しているインスタンスのデータ抽出
4. AWS から OCI へデータを転送する
5. 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 へデータ転送の話を予定しています。