GCPでプロジェクトをまたぐインスタンスの移行をした（Ver.1）

GCP（Google Cloud Platform）でプロジェクトをまたぐインスタンスの移行をしたので作業ログとして記事にしました。

ちなみに今回移行したインスタンスはこのブログ自身です。このブログはWordPressで構築しているため、WordPressの移行をしたいという方の参考になるかもしれません。

前提事項

今回紹介する手順は以下を前提事項としています。

• GCPでプロジェクトをまたぐインスタンスの移行（違うクラウドへの移行ではない）
• インスタンス上ではWordPressが稼働しており、MySQLも同居。シングル構成。
• DNS設定は外部ドメインサーバで実施。
• あくまでも個人ブログであるため数時間のダウンタイムは許容。
• 今回の移行パスはとりあえず移行できれば良しとし、最短ルートであることは求めない。

移行手順

それでは早速移行手順を紹介します。

こちらが移行パスのイメージとなります。丸数字は作業順番を表しており、この後順番に説明します。

1. $1
2. $1
3. $1
4. $1
5. $1
6. $1
7. $1
8. $1
9. $1

上記の一連の手順でプロジェクトをまたぐインスタンスの移行がとりあえずできます。

プロジェクトをまたぐことで、プロジェクトAでは容易にSSH接続できていたがプロジェクトBではSSH接続するのに苦戦するかと予想していましたが、何も特別な作業をせずにプロジェクトBでもSSH接続できたので、それは大変な驚きでした。（GCPが良きに計らってくれたと思うが、なぜか気になるところ・・・）

一連の作業を終えるのに私の環境（ディスク使用量数GB）で約2時間を要しました。より詳細を見ていくと⑤＆⑥の作業時間が大部分を占めていました。

振り返り

冒頭でも触れた通り、今回紹介した手順は最短ルートではないので、最短ルート（ダウンタイムを極力ゼロにする）で移行するために今後挑戦するのは以下と考えています。

• ローカルPCを使わずにGCP内のインスタンスを使ってGCS間のファイルコピーをしてみる。
• プロジェクトAのGCSをプロジェクトBから参照できるようにしてみる。
• プロジェクト間でイメージを共有してみる。（共有可能という情報あり）
• WordPressのアプリケーションレベルでの移行（MySQLのエクスポート＆インポート等）を試してみる。
• DNSのTTLを移行タイミングだけ短くしておく。これによりDNS切り替えの反映が早くなる。今回はこの対応をしなかったので⑨実施後も接続できるようになるまでに約1時間要した。
• （最短ルートとの関連は薄いが）GCP以外に移行したり、複数台構成を移行してみる。

まだまだまだまだ改善の余地がありますが、思ったよりすんなり移行できたのでとりあえず良かったです。