TerraformでCompute Engineのデプロイを自動化する - 応用編
前回の記事では、Google CloudのCompute Engineに単発の仮想マシンをデプロイすることが出来ました。しかし、実際の現場では単体より、ベースになるVMを元に複数台用意してそれぞれに対して作業を行うことがあります。
また、Terraformは奥が深く、変数や処理を別のファイルに分けて管理したり、呼び出したりが可能であるため、今回はこの辺りに触れつつ、10台位の同一構成マシンを複製することにチャレンジしてみようと思います。
目次
今回使用するツール
前回のコードをベースに、今回は変数の利用、ファイル分け、スナップショットの取得、IPアドレスの連番割当、スナップショットを元に複数台を複製にチャレンジしています。
今回はLinuxの仮想マシンとしていますが、Google Workspace MigrateはWindows Serever 2019以上が必要なのでその点にも触れようと思います。環境構築は前回の記事内で記述していますのでご参照ください。
Terraformスクリプトを記述する
注意点
ディスク複製時の注意点
公式サイトにも記述されていますが、スナップショットからのディスク作成は「10分に1個まで」しか作成できず、何も考えずにTerraformのスクリプトでスナップショットから40個ディスクを作成しようとしたところ
|
1 2 |
ERROR: (gcloud.beta.compute.instances.create) Could not fetch resource: - Operation rate exceeded for resource '(マシンイメージのリソース名)'. Too frequent operations from the source resource. |
上記のようなエラーがでて5個くらい作った時点でエラーとなりました。
こちらの解説サイトによりますと、スナップショットからではなくディスクイメージを生成し、そこから新しいディスクを作る分には制限を回避できるとのこと。「スナップショットから新しいゾーン永続ディスクを作成する」というのがマズイようで。
故に、スナップショットではなくディスクイメージを作成し、そこからTerraformでディスクの複製とVMの作成を行わなければならないようだ。
図：制限に引っかかった様子
VMへ接続時の注意点
通常、defaultのネットワークに構築されるCompute Engineですが、VPCが別に用意されていてVPC経由でRDPに接続する場合、「ファイアウォールのルール」がセットされていないと全ての通信が遮断されて接続出来ません。(RDPだと0x204エラーが出て接続出来ない)
よって、ping、icmpやRDP以外にもGWMで使う場合、Internalなどにも気を配ってFirewallセットをしないと先に進めなくなるので要注意。
※但し、VPCのファイアウォールはデフォルトでOutbandの通信は制限しないので外に出ること自体は出来る。
図：VPCにファイアウォールを追加
各種テクニック
ここではTerraformで利用する小技についてまとめています。今回は以下の2つを利用しています。
ファイルの分割
main.tf１個に処理を順番に記述するわけですが、段々と色々な処理を増やしたり要素が増えると、1個のファイルが肥大化します。動作自体に問題はないですが、変数部分は別ファイルにしたいといったような要望が出てきます。
Terraformでは同じディレクトリ内にtfファイルを配置すれば起動時に自動で読みに行きますので、特にmain.tfから参照するようなコードを書く必要はありません。
今回はmain.tfと変数類を格納したvariable.tfの２つに分割しています。
※しかしあまり大量に分割してしまうと逆に効率が悪くなったり、1度のterraform applyで反映できずといったことにもなるため、分割方法は一考する必要があります。
図：2つのファイルに分割した
変数の利用
前回の記事では、各項目の値については直接指定していました。しかし、同じ値を何度も書いたり、変数として切り出しておけばmain.tfから探して書き換えるなんて不要になるため、変数を使うことでその後のメンテナンスが楽になります。前述のファイル分割と合わせて利用すると良いでしょう。
以下はその簡単な事例です。
variable.tf側
こちらは変数を定義したものを列挙しておくファイルです。variableと変数名を付けておきます。defaultの値が参照時に相手側に取得される実際の値になります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
#GCPのプロジェクトIDを格納する variable "project_id" { description = "メインで利用するGCPプロジェクトのIDです。" type = string default = "ここにGCPのプロジェクトIDを入れる" } #VMで利用するリージョンの指定 variable "region" { description = "GCEで利用するリージョンです。" type = string default = "ここにリージョンを入れる" } #VMで利用するゾーンの指定 variable "zone" { description = "GCEで利用するゾーンです。" type = string default = "ここにリージョンにぶら下がるゾーンを入れます。" } |
main.tf側
前述で規定した変数から値をとってきて各項目に当てはめます。変数の参照はvar.変数名で指定することになります。
|
1 2 3 4 5 |
provider "google" { project = var.project_id region = var.region zone = var.zone } |
非常にスッキリしました。variable.tf側の値を変えれば、main.tf側も参照してるのでapplyする際に変わります。main.tfは処理なども書かれている為、どこに対象の変数があるのか？なんて探す手間もなくなります。
その他
TerraformのCompute EngineにおけるBootdiskについての記述にはまだ試していないのですが、
- guest_os_featuresでsecure bootなどをオン・オフできるみたい。詳細はこちらに掲載のオプションを適用できるようだ。
- licensesという謎の項目がある。Windows Serverのライセンス認証関係かな？
スナップショット
スナップショットを取る
ベースになる仮想マシンから複製をするには、作成したVMのスナップショットが必要です。1台まずVMを立ててから、そのマシンよりスナップショットを取ることが必要です。
|
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 |
#1台まずはVMを立てる resource "google_compute_instance" "default" { name = "test-vm" machine_type = var.machinetype zone = var.zone boot_disk { initialize_params { image = var.image } } network_interface { network = "default" access_config { } } } # 作成したVMのディスクからスナップショットを取得 resource "google_compute_snapshot" "default" { name = "test-snapshot" source_disk = google_compute_instance.default.boot_disk[0].source zone = var.zone description = "test-vmからスナップショットを取ります" } |
- google_compute_instanceのdefaultとしてVMを1台立てています。
- google_compute_snapshotにて、スナップショットを取る処理をしています。google_compute_instance.default.boot_disk[0].sourceという形で、0台目のディスクをソースとして指定しています。
図：VM作成⇒Snapshot作成まで自動化
次項のスナップショットを元に複製する場合はこれを参照したり、すでにスナップショットを手動で作成してた場合は、スナップショットの名称を変数に格納しておいて、それを元にboot_diskのソースにしたりすることが可能です。
以下はスナップショットの名前を定義して、それを元にsourceで指定してる様子です。
スナップショットからVMを複製する
前述まででVM生成⇒スナップショットの取得が出来たので、次にこのスナップショットを元に指定台数分複製するものを構築します。スナップショットからまず新しいディスクを作成し、そのディスクを持って新しいVMを作成するという手順になります。
|
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 32 33 34 35 36 37 38 39 40 |
# 作成したVMのディスクからスナップショットを取得 # 手動で作成した場合は次の処理から実装する（この処理は前の処理からの継続の場合に利用する） resource "google_compute_snapshot" "vm_snapshot" { name = "vm-snapshot" #snapshotの名前 source_disk = google_compute_instance.default.boot_disk[0].source depends_on = [google_compute_instance.default] } #スナップショットから新しいディスクを作成 resource "google_compute_disk" "new_disk" { name = "new-disk" type = "pd-ssd" zone = "us-central1-c" snapshot = "vm-snapshot" #snapshotの名前を指定する size = 30 depends_on = [google_compute_snapshot.vm_snapshot] } # 新しいディスクを使用して新しいVMを作成 resource "google_compute_instance" "new_vm" { name = "new-vm" machine_type = "c2-standard-4" zone = "us-central1-c" allow_stopping_for_update = true boot_disk { source = google_compute_disk.new_disk.self_link } network_interface { network = "default" access_config { // テンポラリのグローバルIPがある場合 } } depends_on = [google_compute_disk.new_disk] } |
- google_compute_diskのnew_diskにてスナップショット名（vm_snapshot）を指定して、新しいディスクを生成しています。
- new_diskが作成されたら、新しいVMを構築時にboot_diskではgoogle_compute_disk.new_disk.self_linkという形でリンクさせています。
- depends_onは各項目への参照を定義してるメタデータです。
図：snapshot⇒ディスク作成⇒VM作成を自動化
スナップショットから複数台のVMを複製
さて、ここまでで単体であればスナップショットからVMを複製することが出来ました。問題は複数台複製が必要であるということ。for_eachというループで作成する方法もあるようなのですが、ちょっと違う方法で生成してみることにしました。
複数のディスクを作成し、それぞれからVMを作成する必要があります。
|
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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
# 作成したVMのディスクからスナップショットを取得 resource "google_compute_snapshot" "vm_snapshot" { name = "vm-snapshot" source_disk = google_compute_instance.default.boot_disk[0].source depends_on = [google_compute_instance.default] } # インスタンスの作成数 variable "instance_count" { type = number default = 3 } #スナップショットから新しいディスクを作成 resource "google_compute_disk" "new_disk" { count = var.instance_count name = "new-disk-${count.index}" type = "pd-ssd" zone = "us-central1-c" snapshot = "vm-snapshot" size = 30 depends_on = [google_compute_snapshot.vm_snapshot] } # 新しいディスクを使用して新しいVMを作成 resource "google_compute_instance" "new_vm" { count = var.instance_count name = "new-vm-${count.index}" machine_type = "c2-standard-4" zone = "us-central1-c" allow_stopping_for_update = true boot_disk { source = google_compute_disk.new_disk[count.index].self_link } network_interface { network = "default" access_config { // テンポラリのグローバルIPがある場合 } } depends_on = [google_compute_disk.new_disk] } |
- instance_countという変数を用意し、台数指定として今回は3台を指定しました。
- google_compute_diskに於いてこのinstance_countを元に、「new-disk-${count.index}」という形でスナップショットから複数台のディスクを生成させます。
- google_compute_instanceに於いてもこのinstance_countを元に、「new-vm-${count.index}」という形でVMを作成し、それぞれに対して、boot_diskでは「google_compute_disk.new_disk[count.index].self_link」で作成したディスクを指定しています。
これで、一気に3台分のVMの生成が可能になりました。
Google Workspace Migrateでは最大40台まで必要なので、これで40台分を作成すると良いでしょう。
図：複数台のVMが生成されました。
図：それぞれに適切なディスクも割当られてる
イメージから複数台のVMを複製
イメージの取得
しかし、冒頭の注意事項にもあるように、実際の現場でスナップショットから40台複製をしようとすると、エラーが出ます。Compute Engineの制限事項に引っかかってる為。
よって、以下の手順でイメージを取得して、そのイメージからディスクを複製してVMを構築することが必要です。
-
インスタンスを停止する
-
あらかじめ作っておいたVMを開き、編集画面を開いてインスタンス削除の削除ルールにおいて、「インスタンスを削除したときの動作」を「ディスクを維持」にする必要があります。
-
VMインスタンスは削除する
-
左サイドバーのストレージにあるディスクを開く
-
残ってるディスクの右端の「︙」をクリック⇒イメージを作成をクリック
-
名前を入力（これをTerraformで利用します）。ソースはディスクのままでオッケー（今回はvm-imageと命名）
-
作成をクリック
これで、ディスクイメージが取得できました。
図：VM削除してもディスクは削除しないように
図：イメージの作成手順
Terraformでイメージからディスク複製
基本は、スナップショットからの複製と殆ど変わらない
snapshot=ではなく、image=として、ここにイメージに付けた名前（vm-image）を入力して実行するだけ。今回はvariable.tfのimagenameの値を代入しています。
|
1 2 3 4 5 6 7 8 9 10 |
#イメージから新しいディスクを作成 #snapshotの場合は、image=ではなくsnapshot=となる resource "google_compute_disk" "new_disk" { count = var.instance_count name = "new-disk-${count.index}" type = "pd-ssd" zone = var.zone image = var.imagename size = var.disksize } |
|
1 2 3 4 5 6 |
#VMのイメージデフォルト名称 variable "imagename" { description = "スナップショットのデフォルトの名称" type = string default = "vm-image" } |
IPアドレスの連番割当
defaultネットワークの場合
前述までで、すでに元になるスナップショットからのVM複製を複数台できるようになりました。しかし、内部IPアドレスについては割当していないので適当に生成時に振られています。IPアドレスも連番で振られるように構築してみたいと思います。
但し、IPアドレスはすでに使われてる場合エラーとなるため、敢えて指定せずともよいのではないかと思ったりします。以下はその部分だけを掲載しています。
|
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 32 |
# インスタンスの作成数 variable "instance_count" { type = number default = 3 } #ベースIPアドレス variable "base_ip_address" { description = "VM用の内部IPアドレスを連番で振るためのベースIPアドレス" type = string default = "10.128.1.20/24" } # 新しいディスクを使用して新しいVMを作成 resource "google_compute_instance" "new_vm" { count = var.instance_count ・・・・省略・・・・ network_interface { network = "default" #内部IPに連番で振る network_ip = cidrhost(var.base_ip_address, count.index + 1) access_config { #外部IPに連番で振る #nat_ip = cidrhost(var.base_ip_address, count.index + 1) } } depends_on = [google_compute_disk.new_disk] } |
- base_ip_addressという変数を用意し、cidrでIPv4のアドレスを指定します（v6も使えるみたいだ）。自分はサブネット255.255.255.0である/24にて連番で生成させています。
- VM作成の画面にて、instance_countのcountを利用してnetwork_interfaceにてnetwork_ipが内部IPを指定する場所で、その下のaccess_config内のnat_ipが外部IPを指定する場所になります。
- network_ipにて、base_ip_addressを元にcidrhost関数を使って、count.indexを元に1ずつ連番でIPアドレスを生成して割当しています。
図：CIDRでのIPレンジの計算機
図：すでに使われてるIPを割り当てた時のエラー
図：無事連番でIPアドレス割り当て出来ました
VPCを利用する場合
指定のVPCを使う必要があり、すでに用意されている場合、そのネットワークに参加するようにVMを構築する必要なケースがあります。
この場合用意されてるVPCのネットワーク名、その下にぶら下がるサブネット名の2つを指定し、サブネットのルールに従って、ベースIPアドレスを指定する必要があります。
今回は192.168.1.0というVPCに対して、192.168.1.2/24より連番で割り当てます。
variable.tf
variable.tfの中身を書き換えたり追記が必要です。以下のようにベースIPアドレスのレンジがVPC指定のものを使うので書き換えます。また、vpcnameとvpcsubnetを用意しておきます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
#ベースIPアドレス（IPレンジを書き換え） variable "base_ip_address" { description = "VM用の内部IPアドレスを連番で振るためのベースIPアドレス" type = string default = "192.168.1.2/24" } #VPCの指定（追記） variable "vpcname" { description = "VM用の内部IPアドレスを連番で振るためのベースIPアドレス" type = string default = "VPCの名前を入力する" } #subnetの指定（追記） variable "vpcsubnet" { description = "VM用の内部IPアドレスを連番で振るためのベースIPアドレス" type = string default = "VPCにぶら下がるサブネットの名前を入力する" } |
main.tf
イメージから複製したディスクを元に新しいVMを作成するシーンに於いて、これまでdefault指定だった場所を変更すると共に、192.168.1.1がゲートウェイとしてすでに使われてるので、192.168.1.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 32 33 34 |
# 新しいディスクを使用して新しいVMを作成 resource "google_compute_instance" "new_vm" { count = var.instance_count name = "new-vm-${count.index}" machine_type = var.machine_type zone = var.zone hostname = "new-vm-${count.index}.${var.app_domain}" allow_stopping_for_update = true tags = ["rdp","http"] boot_disk { source = google_compute_disk.new_disk[count.index].self_link } network_interface { #VPCの指定 network = var.vpcname subnetwork = var.vpcsubnet #内部IPに連番で振る network_ip = cidrhost(var.base_ip_address, count.index + 2) access_config { #外部IPに連番で振る #nat_ip = cidrhost(var.base_ip_address, count.index + 1) } } service_account { email = var.service_account scopes = ["cloud-platform"] } depends_on = [google_compute_disk.new_disk] } |
- network_interfaceにて、networkはdefaultではなくvpcnameを指定します。
- subnetworkを追加して、値はvpcsubnetを指定します。
- network_ipはこれまでは1から指定していましたが2から指定したいので、「count.index + 2」として割当開始させます。
- このVPC自体も、以下のようにTerraformで作成することが可能です。
1234#VPCネットワークを作成するresource "google_compute_network" "vpc_network" {name = "super-netowork-vpc01"}
Windows Serverを利用する
VMを作成してみる
ここまではDebian GNU Linux 12を使った仮想マシンを構築していました。しかし、Google Workspace MigrateではWindows Server 2019以上を利用する必要があります。またマシンのタイプもノードのシステム要件を見てみると、4CPU, 32GB RAM以上となってるため、「n2-highmem-4」以上を利用する必要があります。
※但し、Google Workspace Migrateでは台数を増やせば処理能力はスケールしても、マシンスペックを上げても単純スケールしません。
この構成でマシンを作る場合は以下のようになります。
|
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 32 33 34 35 36 37 |
#Windows Server 2019の変数 variable "windows_2019_sku" { type = string description = "windows serverのSKU名になります" default = "windows-cloud/windows-2019" } #ドメインの指定 variable "app_domain" { type = string description = "ホスト名で利用するドメイン名" default = "hogehoge.com" } # Create VM resource "google_compute_instance" "new_vm" { count = var.instance_count name = "new-vm-${count.index}" machine_type = "n2-highmem-4" zone = "us-central1-c" hostname = "new-vm-.${var.app_domain}" tags = ["rdp","http"] boot_disk { initialize_params { image = var.windows_2019_sku size = 200 } } network_interface { network = "default" access_config { } } } |
- Windows Serverのimage名は「windows-cloud/windows-2019」になります。
- GWMで利用する場合ディスクサイズは200GB以上を推奨します。
- GWMで利用する場合はマシンタイプは「n2-highmem-4」以上を推奨します。
- マシン名やホスト名は重複しないようにセットします。
- Azureの場合はadminのusernameやpasswordがセットできるようですが、GCPにはそのような設定が見当たらず。
ライセンス認証
今回は特に自前のWindows Server 2019のライセンスを持ち込みしてるわけじゃないので、実際に作成したVMに対してRDPで接続してみましたが、Windows上ではアクティベーション済みとして確認できました。
このライセンス料含めて稼働時間で請求が来る仕組みになってるので、Linuxの場合よりもWindows ServerのVMのほうが高額になりますのでWindows Serverで運用する場合は注意が必要です。
また、Google Workspace Migrateはこの段階で内部IP間の通信はできる状態になっており、特に設定をしていなければアプリさえ入っていればノードサーバ等として利用が可能です（PC名でつなぎに行くわけではないのでドメイン指定も必要ありません）。RDPで接続する場合は、外部IPで接続することになります。
Terraformを実行する
さて、ここまででほぼ希望する内容が構築できました。これらをひとまとめにしたコードが以下のようになります。
variable.tf
以下は変数ファイルのサンプルになります。
|
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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 |
# インスタンスの作成数 variable "instance_count" { type = number default = 3 } #ベースIPアドレス variable "base_ip_address" { description = "VM用の内部IPアドレスを連番で振るためのベースIPアドレス" type = string default = "10.128.1.20/24" } #GCPのプロジェクトIDを格納する variable "project_id" { description = "メインで利用するGCPプロジェクトのIDです。" type = string default = "ここにGCPのプロジェクトIDを入れる（番号じゃないよ）" } #VMで利用するリージョンの指定 variable "region" { description = "GCEで利用するリージョンです。" type = string default = "us-central1" } #VMで利用するゾーンの指定 variable "zone" { description = "GCEで利用するゾーンです。" type = string default = "us-central1-c" } #VMで利用するマシンタイプ variable "machine_type" { description = "GCEで利用するマシンタイプを指定します" type = string default = "c2-standard-4" } #VMで利用するベースのVM名称 variable "gce_name" { description = "GCEで利用するベースVMの名称" type = string default = "gwmprj-20240813" } #サービスアカウントのJSONキーファイルの指定 variable "sa_keyfile"{ description = "JSONキーファイルのパスを指定" type = string default = "ここにJSONキーファイルの相対パスを入れる" } #サービスアカウントのアカウント名 variable "service_account" { description = "サービスアカウントのアドレスを入力" type = string default = "ここにサービスアカウントのメールアドレスを入れる" } #VMで利用するディスクイメージ名称 variable "diskimage" { type = string description = "OSイメージ名称を入れます" default = "debian-cloud/debian-12" #Windowsならばwindows-cloud/windows-2019 } #VMで利用するディスクサイズ variable "disksize" { type = number description = "ディスクサイズ" default = 30 } #VMのスナップショットデフォルト名称 variable "snapname" { description = "スナップショットのデフォルトの名称" type = string default = "vm-snapshot" } |
main.tf
以下は、これまでのまとめになります。variable.tfの変数の値に基づいてバッチリ作業してくれました。
|
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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 |
# terraformの設定（v5以上を指定にしてみた） terraform { required_providers { google = { source = "hashicorp/google" version = "~> 5.0" } } } # terraformで利用するプロバイダーの指定 provider "google" { #サービスアカウントのJSONキーファイルを指定する credentials = file(var.sa_keyfile) #プロジェクトIDと構築先のリージョン指定 project = var.project_id region = var.region #asia-northeast1なら東京 zone = var.zone #asia-northeast1-bなら東京配下 } #Compute Engine用のリソースの設定 resource "google_compute_instance" "default" { name = var.gce_name machine_type = var.machine_type zone = var.zone allow_stopping_for_update = true boot_disk { initialize_params { image = var.diskimage size = var.disksize } } network_interface { network = "default" access_config { //テンポラリのグローバルIPがある場合 } } service_account { email = var.service_account scopes = ["cloud-platform"] } } # 作成したVMのディスクからスナップショットを取得 resource "google_compute_snapshot" "vm_snapshot" { name = var.snapname source_disk = google_compute_instance.default.boot_disk[0].source depends_on = [google_compute_instance.default] } #スナップショットから新しいディスクを作成 resource "google_compute_disk" "new_disk" { count = var.instance_count name = "new-disk-${count.index}" type = "pd-ssd" zone = var.zone snapshot = var.snapname size = var.disksize depends_on = [google_compute_snapshot.vm_snapshot] } # 新しいディスクを使用して新しいVMを作成 resource "google_compute_instance" "new_vm" { count = var.instance_count name = "new-vm-${count.index}" machine_type = var.machine_type zone = var.zone allow_stopping_for_update = true boot_disk { source = google_compute_disk.new_disk[count.index].self_link } network_interface { network = "default" #内部IPに連番で振る network_ip = cidrhost(var.base_ip_address, count.index + 1) access_config { #外部IPに連番で振る #nat_ip = cidrhost(var.base_ip_address, count.index + 1) } } depends_on = [google_compute_disk.new_disk] } |
実行してみた。
上記の設定では30GBベースのVMを含めて4台VMを作成しています。実際に実行してみると
- ベースVMを作成
- ベースVMからスナップショット取得
- スナップショットから必要台数分のディスク生成
- 必要台数分のディスクからVMを新規作成で作成
- 各VMに連番で内部IPアドレスを割り振り
までを一気に行っています。わずか数分でこの作業が自動で行えてしまいます。
実際のGoogle Workspace Migrateで使う場合は、ノードサーバに対してID/PWの設定やNodeサーバ用のツールのインストールなどTerraformで出来ないことをやったベースVMに対して、スナップショット作成以下の自動化という手順になるため、このスクリプトの後半部分は改変して流用ができると思います。
図：サクッとVMが建てられました
検証が終わったらDestroyする
そして、このまま放置すると大変な金額が課金されてしまうので検証が終わったら、前回基礎編同様にterraform destroyしましょう。
- ベースで作ったVMが削除されます
- スナップショットが削除されます
- 複製したディスクもろとも全新規VMも削除されます。
これらが一発のコマンドで一括で削除されます。この手軽さがTerraformの良い所。
関連リンク
- KopiCloud/terraform-gcp-windows-vm
- Terraform を使用して Compute Engine リソースをプロビジョニングする
- gcloud CLI のインストールから基本的な使い方-GCP
- Google Cloud Compute EngineをTerraformで構築してみる
- Terraform で入門する Google Cloud【セットアップ編】
- Terraform インストールして GCP 向け設定と GCE でインスタンス構築
- 【初心者】Terraform importを使ってみる
- Google Cloud：コンソールで作成したリソースをTerraform importで取り込む
- Terraformのコードを読み取ってクラウド費用を推定してくれる「Infracost」にJetBrains拡張機能版が登場
- Terraformのかゆい所に手をのばす 〜 meta-arguments 〜
- Create Google Cloud Compute instance disk from snapshot #11770
- cidrhost Function - Terraform
- google_compute_disk - Terraform
- ネットワーク計算ツール
- ホスト名とは？ 調べ方・FQDNやIPアドレスの概要も併せて解説
- 【Terraform de Azure】 Windows10 の VM を作成し RDP してみました
- Terraformに入門したメモ
- ディスクのアーカイブ スナップショットと標準スナップショットを作成する
- Terraform連載 第4回：for_eachの使い方
- terraformファイル分割検討
- Terraform プロジェクトの効果的なディレクトリ構成パターン(ゼロから始める Terraform 講座～その2～)
- Windows Server VMのライセンス認証(設定編)
- #3 Terraformを使用して仮想マシンを作成する
- GCPにおけるOSライセンス管理のポリシーと手順：詳細な説明
- Terraform入門と便利ツールまとめ【一気に中級者へ】
-
【GCP/Terraform】VMインスタンスをサブネット内に作成し、Firewallで許可したIPからのみSSH接続する
