【GCP】CloudBuildを利用して、仮想マシンをGCEインスタンスに移行してみた

2021.05.13

GCP
クラウド

はじめに

皆さん、こんにちは。入社2年目のクラウド基盤技術部のR.Aです。

弊社では昨年からGoogle Cloud Platform (以下、GCP)を使ったシステム提案/開発に注力しており、各種イベントやGCPサービスを展開しております。
技術ブログでもGCP関連のネタを随時公開していきますので、是非ご活用下さい。

今回はvSphere環境上の仮想マシンをGoogle Compute Engine (以下、GCE)インスタンスに移行する方法を説明します。

移行にあたり、GCPのサービスの一つであるCloud Buildを利用して、仮想ディスク（VMDKファイル）からGCEインスタンスとして起動できるイメージを作成します。

また、移行前の仮想マシンと移行した後のGCEインスタンスの変化しているOS設定を確認します。

そもそもCloud Buildって？

サーバーレスCI/CD (Continuous Integration / Continuous Delivery)プラットフォームで、特にCIである継続的インテグレーションを容易に実行できるGCPのサービスです。

ビルド構成ファイルなどに基づき、DockerイメージのビルドやPython、Javaなどのプログラミング言語で書かれたアプリケーションのビルド・テスト・デプロイに加え、ビルドの自動化やアーティファクト（成果物）の保存ができます。

今回の仮想ディスク（VMDKファイル）からGCEインスタンスとして起動できるイメージを作成する際には、ビルド構成ファイルなどの作成は必要なくGUI操作でポチポチするとGCE用のイメージが作成できます。

Cloud Buildについて詳しく知りたい方はGoogle公式サイトをご覧ください。
https://cloud.google.com/build

環境情報

vSphere環境（移行元）

移行対象の仮想マシンがあるvSphere環境情報です。

・ESXi 6.5

・vCenter 6.7

GCP環境（移行先）

仮想マシンの移行先であるGCP環境情報です。

Virtual Private Cloud（以下、VPC）、サブネット、ファイアウォールルールが既に作成してあるプロジェクトに移行します。

※赤枠で囲われているサービスを今回作成します。

移行対象仮想マシン情報

移行対象の仮想マシン情報です。

・CentOS 7.9

- ハードディスク1つ

- ネットワークアダプタ1つ

・動作確認用ミドルウェア

- Apache/2.4.6

前提条件

・移行対象の仮想マシンのVMDKファイルをダウンロードしていること

・移行対象先のプロジェクトやVPC、サブネット、ファイアウォールルールは事前に作成していること

・移行対象先のプロジェクトにアクセスできるIAMユーザーを有していること

・そのIAMユーザーにオーナー権限が付与されていること

大まかな仮想マシンの移行手順

以下の手順で、vSphere環境上の仮想マシンをGCP環境へ移行します。

１．VMDKファイルをGoogle Cloud Storage (以下、GCS)へアップロード

２．Cloud Buildを利用して、VMDKファイルからイメージの作成

３．作成したイメージからGCEインスタンスの作成

４．GCEインスタンスの動作確認

1. VMDKファイルをGCSへアップロード

このフェーズでは、VMDKファイルをアップロードするGCSバケットを作成しアップロードします。

ナビゲーションメニュー > [Cloud Storage] - [ブラウザ]を選択します。

画面上部にある[バケットを作成]を押下します。

ナビゲーションに従い、必要情報を入力し[作成]を押下します。下記は今回の入力・選択理由です。

名前 : 任意の名前を入力します。

ロケーションタイプ : 可用性は必要ないため、"Region"を選択します。

ストレージクラス : すぐにアクセスするため、"Standard"を選択します。

アクセス制御 : ACLでのアクセス管理は行わないため、"均一"を選択します。

バケットが作成されると自動的に作成したバケットに遷移します。

[ファイルをアップロード]を押下し、ダウンロード済みのVMDKファイルを選択します。

VMDKファイルがアップロードされたことを確認します。

2. Cloud Buildを利用して、VMDKファイルからイメージの作成

このフェーズでは、Cloud Buildを利用してGCEインスタンスのイメージ作成を行います。

ナビゲーションメニュー > [Compute Engine] - [イメージ]を選択します。

画面上部にある[イメージを作成]を押下すると、イメージ作成画面に遷移します。

必要情報を入力します。下記は今回の入力・選択理由です。

名前 : 任意の名前を入力します。

ソース : "仮想ディスク（VMDK、VHD）"を選択します。

Cloud Storageファイル : 参照からアップロードしたVMDKファイルを選択します。

仮想ディスクのオペレーティングシステム : 移行対象の仮想マシンのOSを選択します。

ゲストパッケージをインストールする : チェックを入れます。

[作成]を押下すると、 [Compute Engine] - [イメージ] > [イメージインポートの履歴]タブの画面に遷移します。

初めて実行する際には、、、

ソース : "仮想ディスク（VMDK、VHD）"を選択した際に、Cloud Build APIを有効化していないと以下の写真のポップアップが出てきます。

[Cloud Build APIを有効にする]を押下しAPIを有効化します。

Cloud Build APIを有効にすると、Cloud Buildサービスアカウントが自動的にプロジェクトに作成されます。

このCloud Buildサービスアカウントに以下のロールが必要なため、APIの有効化と同様に[付与]を押下しロールの付与を実施します。

・compute.admin（Conmpute 管理者）

・iam.serviceAccountUser（サービスアカウントユーザー）

API有効化とロール付与の確認

ポップアップが消えた時点でCloud Build APIの有効化とサービスアカウントにロール付与の実行は終了していますが、不安な方は以下の方法でそれぞれ確認してください。

　・Cloud Build APIが有効化されたか確認するには、以下のページにアクセスします。

　　ナビゲーションメニュー > [APIとサービス] - [ライブラリ] > "Cloud Build"と検索し、

　　検索結果の[Cloud Build API]を押下する。

　・Cloud Buildサービスアカウントにロールが付与されたか確認するには、以下のページにアクセスします。

　　ナビゲーションメニュー > [IAMと管理] - [IAM] > フィルタに"Cloud Build"を入力する。

少し本題からずれたため、説明を[イメージインポートの履歴]タブの画面に遷移した後に戻します。

画面遷移後、[Cloud Build ID]を押下すると、イメージインポートの詳細からCloud Buildのログを確認できます。

写真の[7a8fc911-5015-4c9c-a73d-487c5d08e79b]の部分を押下します。

もちろん、Cloud Buildの画面（ナビゲーションメニュー > [Cloud Build] - [履歴] ）からも、同等のログを確認できます。

[イメージインポートの履歴]タブの画面に戻り、緑アイコンに変わるとイメージが正常に作成された合図です。

念のためイメージが作成されたことを[イメージ]タブの画面に移動し確認します。

3. 作成したイメージからGCEインスタンスの作成

このフェーズでは、作成したイメージでインスタンスを作成します。

ナビゲーションメニュー > [Compute Engine] - [VMインスタンス]を選択します。

画面上部にある[インスタンスを作成]を押下し、必要情報を入力します。

設定項目が多いため重要部分のみ入力・選択理由を記載します。

左ペインが[新規VMインスタンス]になっていることを確認してください。

仮想マシン名には、任意の名前を入力します。

ブートディスクをカスタムイメージに変更するため、[変更]を押下します。

[カスタムイメージ]タブに移動し、[イメージ]のプルダウンから作成したイメージを選択します。

※作成したイメージがプルダウンに表示されない場合は、1つ上の[表示するイメージの取得元]を確認してください。

Apacheの動作確認を行うため、[ファイアウォール] - [HTTTPトラフィックを許可する]にチェックを入れます。

[ネットワーキング] > [ネットワークインターフェース]から、VPCやサブネットを変更できます。

Apacheの動作確認を行うため、外部IPを付与（[なし]以外を選択）します。

[作成]を押下し、 [Conmpute Engine] - [VMインスタンス] > [インスタンス]タブの画面に遷移します。

インスタンスが作成されるまで待ちます。

4. GCEインスタンスの動作確認

このフェーズでは、作成したインスタンスが起動すること、ミドルウェアが起動することを確認します。

インスタンスが起動すると、緑アイコンに変わります。

今回はTeraTermを使用して、外部IP宛てにSSHログインします。

※移行前にログインできていたユーザーとパスワードを使用します。

Apacheが無事動作していることをWebブラウザから確認できました。

仮想マシン（移行前）とGCEインスタンス（移行後）の変化

移行する前と移行した後で変化している部分をざっと確認しました。

rpmパッケージ

以下が移行後に追加されたrpmパッケージです。

移行後に削除されているrpmパッケージは確認できませんでした。

boost-regex-1.53.0-28.el7.x86_64

google-cloud-sdk-340.0.0-1.x86_64

google-compute-engine-20210204.00-g1.el7.noarch

google-compute-engine-oslogin-20210429.00-g1.el7.x86_64

google-guest-agent-20210223.01-g1.el7.x86_64

google-osconfig-agent-20210429.3-g1.el7.x86_64

gpg-pubkey-3e1ba8d5-558ab6a8

gpg-pubkey-836f4beb-5fc97e5e

nvme-cli-1.8.1-3.el7.x86_64

ユーザーとグループ

追加されているユーザーは確認できませんでしたが、以下のグループが追加されていました。

・/etc/group

google-sudoers:x:1000:

hostsファイル

下から2行分追加されています。コメントアウトは自動で記載してありました。

・/etc/hosts

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4

::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

192.168.100.2 migration-test-01.c.certain-math-279406.internal migration-test-01 # Added by Google

169.254.169.254 metadata.google.internal # Added by Google

名前解決と時刻同期設定

DNSサーバーと検索ドメインは、どちらも書き換えられていました。

・/etc/resolv.conf

# Generated by NetworkManager

search c.certain-math-279406.internal google.internal

nameserver 169.254.169.254

時刻同期設定は/etc/chrony.confを確認しましたが、変更されていませんでした。

ネットワーク

ネットワークは、移行前と移行後のコマンドの出力結果を比較して確認します。

移行前

・ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo