「システム基盤構築のプロフェッショナル」レック・テクノロジー・コンサルティングJapanese | English

レック・テクノロジー・コンサルティング株式会社

技術ブログ

~技術ブログ ~

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

はじめに

皆さん、こんにちは。入社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)、サブネット、ファイアウォールルールが既に作成してあるプロジェクトに移行します。
※赤枠で囲われているサービスを今回作成します。

migration-test-01(1).png

移行対象仮想マシン情報

移行対象の仮想マシン情報です。
・CentOS 7.9
- ハードディスク1つ
- ネットワークアダプタ1つ
・動作確認用ミドルウェア
- Apache/2.4.6



前提条件

・移行対象の仮想マシンのVMDKファイルをダウンロードしていること
・移行対象先のプロジェクトやVPC、サブネット、ファイアウォールルールは事前に作成していること
・移行対象先のプロジェクトにアクセスできるIAMユーザーを有していること
・そのIAMユーザーにオーナー権限が付与されていること



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

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

1.VMDKファイルをGoogle Cloud Storage (以下、GCS)へアップロード
2.Cloud Buildを利用して、VMDKファイルからイメージの作成
3.作成したイメージからGCEインスタンスの作成
4.GCEインスタンスの動作確認



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

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

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

GCS01.png

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

GCS02.jpg

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

名前 : 任意の名前を入力します。
ロケーションタイプ : 可用性は必要ないため、"Region"を選択します。
ストレージクラス : すぐにアクセスするため、"Standard"を選択します。
アクセス制御 : ACLでのアクセス管理は行わないため、"均一"を選択します。

GCS04 (1).png
GCS04 (2).png

バケットが作成されると自動的に作成したバケットに遷移します。
[ファイルをアップロード]を押下し、ダウンロード済みのVMDKファイルを選択します。

GCS05 (2).png

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

GCS06.png



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

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

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

GCB01.png

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

GCB02.png

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

名前 : 任意の名前を入力します。
ソース : "仮想ディスク(VMDK、VHD)"を選択します。
Cloud Storageファイル : 参照からアップロードしたVMDKファイルを選択します。
仮想ディスクのオペレーティングシステム : 移行対象の仮想マシンのOSを選択します。
ゲストパッケージをインストールする : チェックを入れます。

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

GCB03.png

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

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

GCE00-1.png

Cloud Build APIを有効にすると、Cloud Buildサービスアカウントが自動的にプロジェクトに作成されます。
このCloud Buildサービスアカウントに以下のロールが必要なため、APIの有効化と同様に[付与]を押下しロールの付与を実施します。
compute.admin(Conmpute 管理者)
・iam.serviceAccountUser(サービスアカウントユーザー)

GCE00-2.png

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

ポップアップが消えた時点でCloud Build APIの有効化とサービスアカウントにロール付与の実行は終了していますが、不安な方は以下の方法でそれぞれ確認してください。
 ・Cloud Build APIが有効化されたか確認するには、以下のページにアクセスします。
  ナビゲーションメニュー > [APIとサービス] - [ライブラリ] > "Cloud Build"と検索し、
  検索結果の[Cloud Build API]を押下する。

GCE00-3.png

 ・Cloud Buildサービスアカウントにロールが付与されたか確認するには、以下のページにアクセスします。
  ナビゲーションメニュー > [IAMと管理] - [IAM] > フィルタに"Cloud Build"を入力する。

GCE00-4.png

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

画面遷移後、[Cloud Build ID]を押下すると、イメージインポートの詳細からCloud Buildのログを確認できます。
写真の[7a8fc911-5015-4c9c-a73d-487c5d08e79b]の部分を押下します。

GCB04 (2).png

GCB05.png

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

GCB06 (2).png

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

GCB07 (2).png

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

GCB08 (2).png


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

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

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

GCE01.png

画面上部にある[インスタンスを作成]を押下し、必要情報を入力します。
設定項目が多いため重要部分のみ入力・選択理由を記載します。

GCE02.png

左ペインが[新規VMインスタンス]になっていることを確認してください。
仮想マシン名には、任意の名前を入力します。
ブートディスクをカスタムイメージに変更するため、[変更]を押下します。

GCE03.png

[カスタムイメージ]タブに移動し、[イメージ]のプルダウンから作成したイメージを選択します。
※作成したイメージがプルダウンに表示されない場合は、1つ上の[表示するイメージの取得元]を確認してください。

GCE04 (2).png

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

GCE05.png

[ネットワーキング] > [ネットワークインターフェース]から、VPCやサブネットを変更できます。
Apacheの動作確認を行うため、外部IPを付与([なし]以外を選択)します。

GCE06.png

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


GCE07.png

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

GCE08.png


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

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

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

GCE09.png

今回はTeraTermを使用して、外部IP宛てにSSHログインします。
※移行前にログインできていたユーザーとパスワードを使用します。

GCE10 (2).png
GCE11 (2).png

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

GCE12.png


仮想マシン(移行前)と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
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:50:56:91:d9:ad brd ff:ff:ff:ff:ff:ff
inet 10.80.80.200/24 brd 10.80.80.255 scope global noprefixroute ens192
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe91:d9ad/64 scope link
valid_lft forever preferred_lft forever

移行後

・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
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc mq state UP group default qlen 1000
link/ether 42:01:c0:a8:64:02 brd ff:ff:ff:ff:ff:ff
inet 192.168.100.2/32 brd 192.168.100.2 scope global noprefixroute dynamic eth0
valid_lft 77587sec preferred_lft 77587sec
inet6 fe80::4001:c0ff:fea8:6402/64 scope link
valid_lft forever preferred_lft forever

インターフェース名がens192からeth0に変化しているため、使用するインターフェースが変更されていそうです。

新たに/etc/sysconfig/network-scripts/
ifcfg-eth0ファイルが追加されていました。
移行前に使用していた/etc/sysconfig/network-scripts/ifcfg-ens192ファイルは残ったまま、
NetworkManagerでeth0をアクティベートしてありました。

・/etc/sysconfig/network-scripts/ifcfg-eth0

BOOTPROTO=dhcp
DEVICE=eth0
ONBOOT=yes
TYPE=Ethernet
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
DHCP_HOSTNAME=localhost
IPV4_FAILURE_FATAL=no
NAME="System eth0"
MTU=1460
PERSISTENT_DHCLIENT="y"
ip aコマンドとifcfg-eth0ファイルからMTU値が1500から1460に変更されてることが確認できます。
これは今回の移行先のVPCのMTU値が1460に設定されているためです。

net01.png

IPアドレスが変更されているため、デフォルトゲートウェイも確認します。

移行前

・ip route

default via 10.80.80.254 dev ens192 proto static metric 100
10.80.80.0/24 dev ens192 proto kernel scope link src 10.80.80.200 metric 100

移行前

・ip route

default via 192.168.100.1 dev eth0 proto dhcp metric 100
192.168.100.1 dev eth0 proto dhcp scope link metric 100
192.168.100.2 dev eth0 proto kernel scope link src 192.168.100.2 metric 100

IPアドレスが変更されているため、デフォルトゲートウェイも変更されていることが確認できました。
これもMTU値の変更と同様に移行先の依存関係による変更です。
以下の写真からも確認できる通り、移行先のサブネットのデフォルトゲートウェイが192.168.100.1に設定されているためです。

net02.png


おわりに

今回はCloud Buildを利用して、vSphere環境上の仮想マシンをGCEインスタンスに移行する方法を説明し、OS設定の変更点を確認しました。

移行の作業はすべてGUI操作で行ったため、GCPを扱うことが初めてでも直感的に移行することができました。
仮想マシンを手軽にGCPクラウド環境へ移行できるので、是非お試しください。


資料請求・お問い合わせはこちら

▲ ページトップに戻る

技術ブログ

2021年5月
« 2月  
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
採用に関するお問い合わせはこちら