search
LoginSignup
1

More than 1 year has passed since last update.

Organization

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

はじめに

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

メリークリスマス!!(イブッ):christmas_tree:ついに残すところ、あと1回。とりあえず、3日坊主にはならなかったです:sweat:そもそも無事に移行させることができるか…。今日の作業で準備ができるかにかかっています:muscle:

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

今日は早速、移行先(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)
 2020-12-17 20.12.36.png
こちら先週開催していた Oracle Developer Days 期間中につくったので、トライアルクレジットとして55,000円をもらえていました:smiley:。Oracle主催のイベント時は特典:gift:をもらえたりすることもあるので、興味がある方は Oracleのイベントなどもチェックしてみてください:sparkles:

さて、早速インスタンスを用意しようと思うのですが、今の OCI って簡単に構成できるようになっているので、今回の環境(Computeを外に向けて出すだけ)であれば、[VMインスタンスの作成]だけで作れてしまいます。とはいえ、あとで管理しづらくなるので、ちょっと仕分けしたいなぁ。ということで、コンパートメントを分けておこうと思います。

ここからは具体的な手順というよりかは、私が触っていった流れの紹介です:writing_hand:

コンパートメントを作成する

コンパートメントを分ける理由は、インスタンスの管理が楽になったりします。例えば、環境毎にアクセス管理をしたり、組織やチーム毎にアクセスできるリソースを分離したりなど。このあたりを大枠から制御するときに、コンパートメントを分けて管理すると運用が楽になります。今回は、この環境を触るのは私だけなので、とりあえず、AWSからの移行先としてまとめて管理したいので、1つコンパートメントを用意しました。
20201223-014.png
親コンパートメントとして[Blog]を用意して、子コンパートメントに[Production](本番環境:フロントに立てるブログ)と[Development](開発環境:機能拡張なり何かいじる環境)の2つを用意してみました。
20201223-001.png

ちょっとカッコよく?開発環境(Development)を用意してみましたけど、おそらく、今はProduction(本番環境)しか使わないと思います。気持ち(ノリ)は大事ということで…:sweat_drops:

VCNの準備

次は、OCI上にBlog用のネットワークを用意します。(AWS でいう VPC になります)
20201223-602.png
コレがないと Compute の置き場がありませんので、用意する必要があります。
※Compute を作成するところからも VCN を用意することができますが、今回は VCN ウィザードから作成したいので、「仮想クラウド・ネットワーク」から「VCNウィザードの起動」をポチッとします。
2020-12-23-003.png

ウィザードを選択すると、こんなメニューが表示されます。
 2020-12-23 16.37.34.png
移行するシステムはブログのため、外部(インターネット)から接続させたいので「インターネット接続性を持つVPN」を選択します。
 2020-12-23 16.39.31.png
ここで検討しないといけない情報は、VCN名とVCNのCIDRブロックぐらいです。
 2020-12-23 16.39.55.png
パブリック・サブネットとプライベート・サブネットのCIDRブロック、それと、DNS解決するかどうか。ぐらいが設定要素になります。あとは「作成」をポチッとして、しばらく待つとVCNの作成が完了します。
 2020-12-23 16.40.56.png
「ネットワークってなんだ?」という方でも、このウィザードがあれば簡単に作れます:sparkles:
VCNの画面に戻ると「インターネット接続性をもつVCN」が構成されています。ネットワーク構成はコレでOK!:v:
 2020-12-23 16.41.23.png

Computeの準備

クラウドリソースを管理するためのコンパートメント、ネットワークまで作成が完了したので、やっと AWS 上で稼働している EC2インスタンスの受け入れ先の Compute(無料枠)を用意したいと思います。
2020-12-23-004.png
コンピュート・インスタンスの作成画面になりますので、「インスタンスの作成」をポチッとします。
2020-12-23-005.png
そうすると、コンピュート・インスタンス作成画面になります。必須情報としては、特に難しい内容はありません。イメージを伝えたいので登録する情報を追っかけてみようと思います。
 2020-12-23 17.17.42.png
コンピュート・インスタンスの名前とコンパートメント選択がありましたので、そちらを登録、選択します。
[Configure placement and hardware]は、すでに無料提供のものを選択されているので、このままでもいいのですが、せっかくなので中身を見てみます。
展開すると、こんな画面になります。
 2020-12-23 17.20.52.png
2020年12月現在、東京リージョンには可用性ドメインは1つしかありませんので、他ドメインを選択することはありません。なお、フォルト・ドメインと呼ばれる可用性ドメイン内のハードウェアなどのインフラを共有するグループがありますが、こちらは明示的にドメインを指定することもできます。ただ今回は Compute 1つだけで構成しているので、どこのフォルト・ドメインでも良いので選択しません(選択しない場合は、自動でどこかのフォルト・ドメインが選択されます)。

あとは、イメージの選択、並びに、シェイプの選択ができます。今回、無料枠は [VM.Standard.E2.1.Micro] 一択なので、こちらもそのまま。

次に「ネットワークの構成」と「SSHキーの追加」です。先に、SSHキーの追加の話をすると、用意しているSSHキーを使っても良いし、OCIにてSSHキーを作成することもできます。今回は、こちらで用意したSSHキーを登録します。
 2020-12-23 17.20.04.png

「ネットワーキングの構成」については展開すると、こんな感じです。
 2020-12-23 17.21.08.png
すでにVCNを作成しているので、先ほど作成したVCNの情報がデフォルトで選択されています。複数VCNを用意している場合は、利用したいVCNが設定されているか確認します。
あと、Blogサーバとして直接アクセスさせるので「パブリックIPアドレスの割当て」を選択します。

次に[Configure boot volume]の設定になります。
今回は、デフォルト(チェックなし)で進めます。これだけで Compute インスタンスの作成ができますが、せっかくなので「拡張オプション」も確認してみます。
 2020-12-23 17.21.57.png
「拡張オプション:管理」で設定できるのは、こちら。
初期化スクリプトや監視系の設定ができます。今回はデフォルトのままにします。
 2020-12-23 18.42.51.png
「拡張オプション:ネットワーキング」で設定できるのは、こちら。
プライベートIPやホスト名の設定ができます。こちらも今回は特に思いはないので、デフォルトのままにします。
 2020-12-23 18.43.04.png
「拡張オプション:イメージ」で設定できるのは、こちら。
今回はOSイメージでOL7.xを選択していますが、こちらの過去提供リリース(直近数件)を選択することができます。デフォルトは一番新しいものになります。これも、特に思いはないので、デフォルトのままにします。
 2020-12-23 18.43.25.png
「拡張オプション:Placement」で設定できるのは、こちら。
共有環境と専有環境の選択になりますが、こちらも共有環境でよいので、デフォルトのままにします。
 2020-12-23 18.43.47.png
拡張オプションを眺めてみましたが、今回はデフォルトにしましたので、コンピュート・インスタンスの作成でやったことはインスタンス名とSSHキーの登録ぐらいでした。非常に簡単だった:sparkles:
さて、早速「作成」してみます。そうすると、コンピュート・インスタンスのプロビジョニングが始まります。
20201223-003.png
オレンジ色のアイコン中は、しばし待つと。。。
20201223-004.png
緑になり、インスタンス完成です。コンピュート・インスタンスの横に[Always Free]の文字が出ていますね。これで無料インスタンスを手に入れました!!:sparkles:

もう一つ、Computeインスタンスの用意

こちらも同じようにインスタンスを用意しますが、今回は Lightsail(Wordpressを用意してくれるサービス)の移行先を作るのですが、せっかくなので、WordPressを構成しやすい KUSANAGI(CMS(Contents Management System)※パートナー提供のイメージ)を使ってみようと思います。

先ほど、OSイメージの選択で、イメージ変更を選択します。
20201223-005.png
ここで[パートナーイメージ]のタブを選択して[KUSANAGI for Oracle Cloud]を探します。
20201223-006.png
さあ!これで、できるかと思ったら・・・
 2020-12-23 20.49.24.png
あ、、、、。Always Free対象のインスタンスが使えない!!!。[KUSANAGI for Oracle Cloud]は、Intel のインスタンスでしか使えない様でした。KUSANAGI を使って WordPress の構築が楽になるかな?と期待していたのですが、仕方ありません。Always Free の Compute をもう1つ用意することにします。(Prime StrategyさんがAMDを対応してくれることを期待:sparkles:

Compute準備完了

下記の構成図にある Compute 2台準備完了。
20201223-607.png
VCN と Compute を用意したので、あとは、Object Storage を用意します。

Object Storage の準備

最後は、ブログの画像データ格納先を用意します。メニューから[オブジェクト・ストレージ]-[オブジェクト・ストレージ]をポチッとします。
20201223-012.png
オブジェクト・ストレージの画面に遷移したら、[バケットの作成]をポチッとします。
20201223-011.png
バケットの作成では、バケット名ぐらいを設定します。あと、デフォルト・ストレージ層として標準(オブジェクト・ストレージ)とアーカイブ(アーカイブ・ストレージ)の選択ができますが、こちらは誤らないようにします。デフォルトは標準です。もちろん今回用意するのも「標準」になります。(※アーカイブ・ストレージは、すぐに取り出ししないような長期保存するようなデータを管理するときに向いています:thumbsup:
 2020-12-23 22.26.01.png
特に難しいところはなく、これで作成できます。

Object Storage準備完了

Blog-01 と Blog-02 のオブジェクト・ストレージが準備できました。
20201223-608.png
これで、AWS 上にあるサービスの代替(移行先)になるものを用意できました。

AWSからOCIの受け皿完成

AWSから移行させるために必要なサービスは、すべて用意できました。長く書いてしまいましたが、やったことは、
1.コンパートメントを用意して、
2.そこにネットワークを構築して、
3.そのネットワーク上にComputeインスタンスを立てて、
4.Object Storageにバケットを用意
しただけです。

改めて、設定した状況を見直すと、こんな感じです。

VCN

VCNはウィザードを利用して、サクッと用意
 2020-12-23 23.02.30.png

Compute

無償で利用できるインスタンス2つ用意
20201223-013.png

Object Storage

無償(10GBまで)で利用できるオブジェクト・ストレージを用意
 2020-12-23 22.26.41.png
OCI側の受け皿(移行先)としては、これで完成です:sparkles:

おわりに(その4)

ちょっと長くなってしまいましたけど、今日のお話は、ここまで。あとは、AWSからブログデータをOCIへ持ってきて構築すれば完成です。明日は aws から OCI へデータ転送の話を予定しています。:writing_hand:

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
1