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

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

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

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

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

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

【プロジェクトA】インスタンスを停止する。これは移行用のイメージを取得するために完全な静止点を作成するため。GCPの仕様上、インスタンスを起動したままでもイメージを取得できるが、イメージ取得中にデータの書き込みが発生するとイメージ内のデータ不整合が発生する恐れがある。
【プロジェクトA】インスタンスに付いているディスクからイメージを作成する。
【プロジェクトA】イメージをGCS（Google Cloud Storage）にファイルとして出力する。
【プロジェクトA】GCSからローカルPCにイメージファイルをダウンロードする。
【プロジェクトB】GCSにイメージファイルをアップロードする。
【プロジェクトB】GCSのファイルからイメージをインポートする。
【プロジェクトB】インポートしたイメージをベースに新たにインスタンスを作成する。
【プロジェクトB】固定IPアドレスをインスタンスに割り当て、インスタンスを起動する。
外部ドメインサーバ上でドメインの向き先を切り替える。

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

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

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

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

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

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