前回のおさらい
Part1で以下のように実施することを確認しました。今回は、これら3点の実現可能性や実施方法を実際に手を動かして確認します。
- Cloudflareの導入およびネームサーバの変更
- DNS切り替え・リダイレクト設定の向き先変更の動作確認
- バックアップファイルからのリストア確認
やりたいことの全体像
とてつもなく簡略化すると、以下のような絵になります。
青色の線が移行前、赤色の線が移行中を示します。IPアドレスを()内に示します。実際はこんな値は取らないですが、便宜上わかりやすいようにこう示します。

- サーバA
-
ブログを現行運用しているサーバ
- サーバB
-
メンテナンスページを表示するサーバ
- DNS(Domain Name System)
-
ドメイン名に対応するIPアドレスを示す
文字で書くと以下の内容になります。
- DNS部分をCloudflareに置き換えて、レコード管理を行う。
- Cloudflare経由の通信にすることでhttps通信を維持できる。
- Cloudflareのルール機能により、移行期間中のブログURLに対する全リクエストをメンテナンス用サーバへ流す。
- mixhostの新規契約&サーバリストアが完了したら、DNSのAレコードを新サーバのIPアドレスにして移行完了
事前検証#1 ネームサーバの移行
作業自体はそんなに難しいことはなく、ナビゲーションに沿ってサクサク進みました。
Cloudflareの登録
まずはアカウント登録をします。登録後、サイトを登録します。

自分の所有するサイトを登録します。

大層なサポートはいらないので、Freeプランを選択します。

今登録しているDNSレコードを読んできて登録してくれるようです。ありがたいですね!

こんな感じでDNSレコードが表示されるので、取り込みます。mixhostで設定していたDNSのレコードのお掃除については、Part3でお話しします。

GoogleDomainsの設定
こんな感じでDNSレコードが表示されるので、取り込みます。mixhostで設定していたDNSのレコードのお掃除については、Part3でお話しします。

Cloudflareさんもネクストアクションを教えてくれます。

証明書の確認
左がmixhostの証明書で、右側がCloudflareで利用できる証明書です。切り替わりには少し時間がかかると思います。
事前検証#2-1 DNS切り替えの動作確認
フォローアップ
DNS周りのお話が出てくるのですが、あまり詳しくない方向けに少し補足していきます。今回を機にDNSに興味をもった方は、『DNSがよくわかる教科書』がオススメです。私も持っていますが、すごく丁寧にDNSについて書かれており良書だと思います。
Aレコード切り替え
本番移行するブログのドメインで試すことはできないので、当ドメイン(erotech-savvy.com)で、Aレコード切り替えにどれくらいかかるかの調査を行いました。
切り替えもと・切り替え先の計2つのwebサーバを用意しました。切り替わっていることがわかりやすいよう、Apacheとnginxを利用しました。
erotech-savvy.comにnginxのサーバのIPアドレスをAレコードに登録しました。20分ほどで反映されwebページが表示されました。その後、apache側のページが表示されるようにDNSのAレコードを変更します。割とすぐに反映されました。
Cloudflareに問い合わせしにいくようにさえ設定しておけば、あまり時間がかからずに向き先変更できそうなことを確認しました。
CNAMEの追加
erotech-savvy.comのAレコードを削除して、CNAMEで移行対象のブログのドメイン名を入れるとどうなるか、気になったので検証してみました。結果としてはcPanelのsorryページが出てくるのでこの方法ではできませんでした。
これに関しては、私の設定の仕方が間違ってたんじゃないかなと思います。CNAMEについてもっと勉強し直してきます。
※IPアドレスでmixhostのサーバにアクセスしたら403Forbittenが返ってくるパターンと類似なのかなと勝手に思っています。

事前検証#2-2 リダイレクト設定の向き先変更の動作確認
ページルールを追加し、/*のパスに対してリダイレクトされて表示されるかを確認します。DNSレコードをあまりいじらなくてもいいので、この方法がお手軽かもしれません。
準備するもの
切り替え確認用に先程のwebサーバ(nginx)内に表示確認ページを用意しました。
- https://erotech-savvy.com/
- https://erotech-savvy.com/test-1.html
- https://erotech-savvy.com/test-2.html
- https://erotech-savvy.com/test-3.html(存在しないページ)
以下の内容について確認しました。設定は保存して置けるので、本番移行の際はONにしておくだけなので楽ですね。
- テスト環境→移行対象のブログへのリダイレクト…OK
- 移行対象のブログ→テスト環境のリダイレクト…OK
- 設定変更の反映までの時間…OK(体感で数十秒でした。)
以下はnginxでのページの準備順なので、興味があれば見てください。
Cloudflareの設定
erotech-savvy.com宛にきたアクセスをanal-peropero.comに流れるように設定留守には、ページルールを利用します。

設定は以下のように行なっております。一時的なリダイレクトなので302を選択しました。設定内容を確認し、問題なければ「保存してデプロイする」をクリックします。

以下のように作成されるので、リダイレクトするタイミングで有効にします。

事前検証#3 バックアップファイルからのリストア確認
事前準備
AWSのクレジットが余っていたので、Lighsailを使ってリストアするためのWordpressサーバを準備しました。お手軽にwordpress環境ができるのでおすすめです。以下の記事を参考にしました。
https://qiita.com/tomokei5634/items/9719731e355ad5299fc2
/wp-adminのページのログインにはuserがユーザ名、sshにはbitnamiがユーザ名で少々混乱しました。
ログインするためのパスワード情報を知るために、sshでログインします。
ssh -i xxxxxx.pem [email protected]アドレス
ログイン後、以下のコマンドを実行しWordpressの管理画面にログインするパスワードを確認します。
cat bitnami_application_password
これで、リストアするための器となるWordpressサーバの準備が整いました。
バックアップテスト(All-in-One WP Migration)
mixhostのサポートからおすすめされたやり方で確認しました。
結果としては、問題なくリストアできました。
以下、さりげなく怖いこと書いていますので、バックアップデータのサイズが大きい方はご注意ください。
※ SIZEが512MBを超えている場合は、無料版のプラグインではインポートする事ができません。
https://help.mixhost.jp/hc/ja/articles/115003733931
また、Part3で詳しく記載しますが、All-in-One WP Migrationのバージョンによってリストア時のバックアップファイルのアップロードサイズが異なります。つまり、ファイルサイズによっては、バックアップできるがリストアできないという状況がありうるということです。
上記の制限値を超える場合は、有償版を買うのが一番早くて楽だと思います。タダで頑張りたい方はFTPでファイルをダウンロード&アップロードする方法もネットで探せば出てきますが、ファイルのパーミッションとか色々ハマりそうな気がします。
データのバックアップ
All-in-One WP Migrationのエクスポートの画面から、エクスポート先にファイルを選択します。

エクスポートするファイルを生成するので少し待ちます。

ファイル作成が完了しダウンロードできるようになるので、緑のボタンを押してダウンロードします。

バックアップファイルからのリストア
バックアップしたファイルをインポートします。

以下のように、データをバックアップデータの内容で上書きする胸の警告が出るので、問題なければPROCEEDをおします。(日本語なら続行などと出ているかもしれません。)

リストアが始まりますので、少し待ちます。

以下のように表示されれば、リストアの完了です。

バックアップテスト(BackupGuard)
All-in-One WP Migration同様に、何の問題もなくリストア成功しました。
余談ですが、私は普段BackupGuardをバックアップに利用しています。プランとしてはGoldになります。
https://backup-guard.com/pricing
BackupGuardを使ったリストア方法は以下の記事を参照ください。
https://backup-guard.com/products/backup-wordpress/doc/restore-website
あまり需要がないかもしれませんが、BackupGuardのリストアについても記載します。
バックアップファイルからのリストア
リストア画面から、Full restoreを選択します。部分的に戻す場合は他の選択肢を選択してください。

リストアが始まりますのでしばらく待ちます。

無事にリストアされて、ブログが表示されることを確認しました。

リストア検証結果まとめ
どちらのプラグインも、バックアップファイルをアップロードしてリストア実行するだけなので、難しい手順はありませんでした。また、記事やアップロード画像これまで使っていたユーザ情報が戻っており、2FAの設定も有効でした。
本番移行後に気づいたのですが、バックアップのスケジュール設定などがデフォルトに戻っていました。外部サービスと連携している系のものは注意して確認したほうが良いかもしれません。
検証結果のまとめ
- DNSレコードの変更内容は短時間で反映されることを確認
- リダイレクトのためのルール設定が想定通りの動作をすることを確認
- プラグインによるバックアップ・リストアが問題なく動作することを確認。
一通り確認できたので、残すはドキドキ・ワクワクする移行作業のみです。
興味のある方は次のPart3の記事で詳しく書きますので、ぜひご確認ください。

コメント