はじめまして。GMOアドマーケティングでインフラを担当しているa.sです。
今回はTerraformを用いて、GCP上に検証環境を構築する機会がありましたので、構築に伴う一連の作業をご紹介します。
構築内容
既存のオンプレミス環境から接続可能なKVSサーバ環境を構築します。
目的として、オンプレミス環境上に構築しているKVSサーバを物理的にスケールする作業のコストを
クラウド化することで下げたいというものです。
以下のような構成になります。
- KVSサーバはGCPで提供されているCentOS7のイメージを使用して構築します。
- オンプレミス環境とGCP環境の通信はVyOSとGCP上のVPN Gatewayで暗号化して行います。
- KVSへの接続は内部ロードバランサを介して各KVSサーバにバランシングする設計としています。
- Terraformのtfstateファイルの管理はGCS(Google Cloud Storage)上で行います。
- Terraformで作成したインスタンスのミドルウェア等の管理は踏み台サーバ(bastion Server)上からansibleで行います(本ブログでは触れません)。
残念ながら、VPN環境は現時点では構築できていないため、その他のGCPリソースをTerraform化したもののご紹介となります。
Terraformを使用する事前準備
予め用意しておくもの
- TerraformとCloud SDKをインストール可能な環境
弊社ではCentOS7の環境で実施します。 - GCPのプロジェクト
GCPの環境を構築するためにGCP上でプロジェクトを作成しておきます。 - 作成したGCPのプロジェクトでAPIを有効化
こちらを参考に、作成したGCPプロジェクトで「Google Compute Engine API」を有効化しておきます。
Google Cloud Console上からTerraform用のサービスアカウントを作成する
TerraformとCloud SDKのAPI認証用にGoogle Cloud Console上からサービスアカウントを作成します。
1.Google Cloud Consoleログイン後、画面左側から「IAM & admin」を選択し、「Service accounts」を選択します。
2.遷移した画面上部にある「CREATE SERVICE ACCOUNT」を選択します。
3.「Service account name」に適当な名前を入力し、「Role」部で必要な権限を選択します。
今回はGCE(Google Compute Engine)及びGCSを操作するために、
「Compute Admin (beta)」及び「Storage Admin」を付与します。
鍵が必要になるので、json形式の鍵を選択して、「CREATE」を選択します。
この鍵は再ダウンロードが出来ないので、大切に保管します。
※鍵の再設定は可能なので、万が一鍵を紛失した際は再設定を行います。
何かと使えるのでGCP用のCloud SDKのインストールと認証
※本ブログではGoogle Cloud Storageのbucket作成にしか使いません
Terraform実行サーバでCloud SDKのインストール及び、認証作業を実施します。
公式ドキュメントの「yum(Red Hat と CentOS)」部を参考にしています。
1.リポジトリを登録します
1 2 3 4 5 6 7 8 9 10 |
# tee -a /etc/yum.repos.d/google-cloud-sdk.repo << EOM [google-cloud-sdk] name=Google Cloud SDK baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64 enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOM |
2.yumでCloud SDKをインストールします
1 |
# yum install google-cloud-sdk |
3.Cloud SDK及びTerraformを操作するユーザにスイッチし(任意)、作成したサービスアカウントのjsonを設置します
1 |
$ vim /path/to/gcp-managemant-key.json |
4.Cloud SDKで作成したサービスアカウント及びGCPのプロジェクトを認証します
1 2 |
$ gcloud auth activate-service-account gcp-managemant@example.iam.gserviceaccount.com --key-file /path/to/gcp-managemant-key.json $ gcloud config set project example-project |
5.認証した情報を確認します。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
$ gcloud auth list Credentialed Accounts ACTIVE ACCOUNT * gcp-managemant@example.iam.gserviceaccount.com To set the active account, run: $ gcloud config set account `ACCOUNT` $ gcloud config list [core] accont = gcp-managemant@example.iam.gserviceaccount.com disable_usage_reporting = True project = example-project Your active configuration is: [default] |
tfstateファイルをGoogle Cloud Storage上で管理するため、保存するためのバケットを作成する
Terraformはデフォルトだと「terraform.tfstate」という名前のファイルで管理対象のインフラの状態を保存しています。
Terraformはこのファイルに基づいて、インフラの構成の変更などを検知し、必要に応じてリソースの作成や削除、変更などを行っています。
チームでTerraformを運用する場合、各々でtfstateファイルの状態が異なると矛盾が生じてしまうため、今回の場合はGCS上にtfstateファイルを保持することで情報の一貫性を保ちます。
Cloud SDKインストール時に併せてインストールされるgsutilコマンドを用いてGCS上にtfstateファイルを保存しておくためのバケットを作成します。
1 |
$ gsutil mb -p example-project -c multi_regional -l Asia gs://example_tf-state-prod/ |
gsutilコマンドの各オプションの意味は以下の通りです。
- mb
バケットを作成します - -p
作成するバケットの対象プロジェクト名を指定します - -c
作成するストレージクラスを指定します - -l
バケットロケーションを指定します - gs://example_tf-state-prod/
「gs://バケット名/」として作成するバケットを指定します
Terraformのインストール
Terraformのインストールを行います。
今回はTerraform実行ユーザの「~/terraform」以下にインストールします。
1 2 3 4 5 6 7 8 |
$ wget https://releases.hashicorp.com/terraform/0.10.4/terraform_0.10.4_linux_amd64.zip $ mkdir ~/terraform $ mv terraform_0.10.4_linux_amd64.zip ~/terraform $ cd ~/terraform $ unzip terraform_0.10.4_linux_amd64.zip $ rm terraform_0.10.4_linux_amd64.zip $ echo 'export PATH=$HOME/terraform:$PATH' >> ~/.bash_profile $ source ~/.bash_profile |
インストール後、以下コマンドでバージョンが確認できればインストールに成功しています。
1 2 |
$ terraform -v Terraform v0.10.4 |
Terraformのコードを書く
Terraformの実行環境が整ったところで、ここからは実際にTerraformのコードを書いていきます。
Terraform構成の構文はHashiCorp Configuration Language、HCLという言語で記述します。
「*.tf」という拡張子を持つファイルにコードを書くことで、Terraformがそれをテンプレートとして自動的に認識します。
Terraform用に適当なディレクトリを作成して、その中に設定ファイルを作成していきます。
今回作成する「*.tf」ファイルの構成は以下の通りです。今回は分かりやすくするために各機能ごとにファイルを分けました。
1 2 3 4 5 6 7 8 9 10 |
gcp ├── backend.tf # GCSにtfstateファイルを保存するための設定 ├── bastion.tf # bastionServerを構築するための設定 ├── firewall.tf # GCP上のファイアウォールルールを設定 ├── instancegroupes.tf # 構築するKVSサーバをインスタンスグループに登録する設定 ├── internallb.tf # 内部ロードバランサ用の設定 ├── kvs.tf # KVSサーバを構築するための設定 ├── network.tf # カスタムVPCネットワークを構築する設定 ├── provider.tf # GCPに接続するための資格情報、プロジェクト名、リージョンを設定 └── variables.tf # 各設定ファイル内で使用する変数を設定 |
以下からは個別に設定ファイルと、設定内容の詳細を記載します。
provider.tf
1 2 3 4 5 |
provider "google" { credentials = "${file("/path/to/gcp-managemant-key.json")}" project = "example-project" region = "asia-northeast1" } |
接続するプロバイダー(今回はGCP)を設定します。
- provider
接続先を設定します。今回はgoogleとなります - credentials
認証情報を設定します。作成したサービスアカウントから発行されたjsonのkeyのパスを指定します - project
対象のプロジェクトを設定します - region
対象のリージョンを設定します
backend.tf
1 2 3 4 5 6 7 |
terraform { backend "gcs" { bucket = "example_tf-state-prod" path = "terraform.tfstate" credentials = "/path/to/gcp-managemant-key.json" } } |
tfstateファイルをGCS上で管理するための設定です。
- backend
対象のバックエンドサービス(gcs)を指定します - bucket
作成したバケットを指定します - path
対象のtfstateファイルのパスを指定します - credentials
認証情報を指定します。作成したサービスアカウントから発行されたjsonのkeyのパスを指定します
variables.tf
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
variable "region" { default = "asia-northeast1" } variable "region_zone" { default = "asia-northeast1-a" } variable "bastion_ssh_keys" { type = "string" default = <<EOF exampleadmin:ssh-rsa 〜 EOF } variable "kvs_ssh_keys" { type = "string" default = <<EOF exampleadmin:ssh-rsa 〜 EOF } |
各設定ファイル内で使用する変数を設定します。
変数は “${var.変数名}” の形で使用します。
- variable “region”
「asia-northeast1」を変数”region”に登録します - variable “region_zone”
「asia-northeast1-a」を変数”region_zone”に登録します - variable “bastion_ssh_keys”
“bastion_ssh_keys”という変数に「exampleadmin」ユーザと、そのユーザ用の公開鍵(ssh-rsa 〜)を登録しています。
ここで登録したユーザはsudo権限が与えられた状態でサーバに設定され、併せて公開鍵を登録しているので秘密鍵ログインが可能になります - variable “kvs_ssh_keys”
「variable “bastion_ssh_keys”」と同様です
network.tf
1 2 3 4 5 6 7 8 9 10 11 |
resource "google_compute_network" "example" { name = "example" } resource "google_compute_subnetwork" "subnet1" { name = "subnet1" ip_cidr_range = "192.168.10.0/24" network = "${google_compute_network.example.name}" description = "example.subnet1" region = "${var.region}" } |
カスタムVPCネットワークを設定します。
- resource “google_compute_network” “example”
ネットワークリソースを作成します
・name
ネットワークの一意の名前を設定します。ここでは「example」としています - resource “google_compute_subnetwork” “subnet1”
サブネットワークリソースを作成します
・name
サブネットワークの一意の名前を設定します。ここでは「subnet1」としています
・ip_cidr_range
作成するネットワークレンジを設定します。ここでは「192.168.10.0/24」を設定しています
・network
このサブネットワークが属する親ネットワークを設定します。ここでは直前で作成した「example」ネットワークを設定しています
※「${google_compute_network.example.name}」とは、「google_compute_network」というリソースの中の「example」というリソースの中の「name」に当たるものという意味で、ここでは
「resource “google_compute_network” “example”」内で設定されている「name = “example”」を指定しているということになります。
・description
このサブネットワークの説明となります
・region
このサブネットワークが属するリージョンを設定します
bastion.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 |
resource "google_compute_address" "bastion01" { name = "bastion01" region = "${var.region}" } resource "google_compute_instance" "bastion01" { name = "bastion01" machine_type = "f1-micro" zone = "${var.region_zone}" tags = ["server", "bastion"] boot_disk { initialize_params { image = "centos-cloud/centos-7" } } metadata_startup_script = <<EOT yum install -y policycoreutils-python semanage port -a -t ssh_port_t -p tcp 10022 sed -i 's/^#Port 22/Port 22\nPort 10022/' /etc/ssh/sshd_config systemctl restart sshd timedatectl set-timezone Asia/Tokyo EOT network_interface { address = "192.168.10.2" subnetwork = "${google_compute_subnetwork.subnet1.name}" access_config { # static external ip nat_ip = "${google_compute_address.bastion01.address}" } } metadata { "block-project-ssh-keys" = "true" "sshKeys" = "${var.bastion_ssh_keys}" } } |
GCEでbastion Serverを構築するための設定です。
- resource “google_compute_address” “bastion01”
bastion Serverに割り当てる静的グローバルIPアドレスリソースを設定します
・name
一意の「bastion01」というリソース名を設定します
・region
静的グローバルIPアドレスリソースを作成するリージョンを設定します。 - resource “google_compute_instance” “bastion01”
作成するGCEインスタンスリソースの情報を設定します
・name
一意の「bastion01」というリソース名を設定します
・machine_type
作成するインスタンスのマシンタイプを設定します
・zone
インスタンスを作成するゾーンを設定します
・tags
インスタンスに付与するタグのリストを設定します
・boot_disk
インスタンス作成に使用するOSイメージを設定します
・metadata_startup_script
サーバ起動時に流すコマンドを設定できます
ここではSSHのポートを10022で使用できるようにし、GCPのCentOS7のイメージはデフォルトUTCなためJSTに変更しています
・network_interface
インスタンスに接続するネットワークを設定します
ここではnetwork.tfで作成したネットワークからの静的プライベートIPを割り振り、
「resource “google_compute_address” “bastion01” 」で作成した静的グローバルIPを割り振ります。
・metadata
ここではSSH用の公開鍵を登録しています。個別にインスタンスに公開鍵を登録するため「block-project-ssh-keys」を有効化します。「sshKeys」には変数で登録した公開鍵を指定します
kvs.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 |
resource "google_compute_instance" "kvs01" { name = "kvs01" machine_type = "n1-standard-2" zone = "${var.region_zone}" tags = ["server", "kvs"] boot_disk { initialize_params { image = "centos-cloud/centos-7" size = "50" type = "pd-ssd" } } network_interface { address = "192.168.10.3" subnetwork = "${google_compute_subnetwork.subnet1.name}" access_config { } } metadata_startup_script = <<EOT timedatectl set-timezone Asia/Tokyo EOT metadata { "block-project-ssh-keys" = "true" "sshKeys" = "${var.kvs_ssh_keys}" } } resource "google_compute_instance" "kvs02" { name = "kvs02" machine_type = "n1-standard-2" zone = "${var.region_zone}" tags = ["server", "kvs"] boot_disk { initialize_params { image = "centos-cloud/centos-7" size = "50" type = "pd-ssd" } } network_interface { address = "192.168.10.4" subnetwork = "${google_compute_subnetwork.subnet1.name}" access_config { } } metadata_startup_script = <<EOT timedatectl set-timezone Asia/Tokyo EOT metadata { "block-project-ssh-keys" = "true" "sshKeys" = "${var.kvs_ssh_keys}" } } resource "google_compute_instance" "kvs03" { name = "kvs03" machine_type = "n1-standard-2" zone = "${var.region_zone}" tags = ["server", "kvs"] boot_disk { initialize_params { image = "centos-cloud/centos-7" size = "50" type = "pd-ssd" } } network_interface { address = "192.168.10.5" subnetwork = "${google_compute_subnetwork.subnet1.name}" access_config { } } metadata_startup_script = <<EOT timedatectl set-timezone Asia/Tokyo EOT metadata { "block-project-ssh-keys" = "true" "sshKeys" = "${var.kvs_ssh_keys}" } } |
GCEで3台のKVS Serverを構築するための設定です。3台とも同スペックで構築するためリソース名に変数を使って一つの設定で3台分のインスタンスを作成することも出来るのですが、このように1台1台個別に設定しないと後述の「instancegroupes.tf」で設定するインスタンスグループに登録できなかったためこのような記述となりました
静的グローバルIPアドレスリソースの設定が無いことを除いて、こちらの説明は「bastion.tf」と重複するため割愛します
firewall.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 |
resource "google_compute_firewall" "allow-icmp" { name = "allow-icmp" network = "${google_compute_network.example.name}" allow { protocol = "icmp" } source_ranges = ["xxx.xxx.xxx.xxx/xx"] target_tags = ["bastion"] } resource "google_compute_firewall" "allow-tcp-10022" { name = "allow-tcp-10022" network = "${google_compute_network.example.name}" allow { protocol = "tcp" ports = ["10022"] } source_ranges = ["xxx.xxx.xxx.xxx/xx"] target_tags = ["bastion"] } resource "google_compute_firewall" "allow-tcp-8091" { name = "allow-tcp-8091" network = "${google_compute_network.example.name}" allow { protocol = "tcp" ports = ["8091"] } source_ranges = ["xxx.xxx.xxx.xxx/xx"] target_tags = ["kvs"] } resource "google_compute_firewall" "allow-internal" { name = "allow-internal" network = "${google_compute_network.example.name}" allow { protocol = "tcp" ports = ["0-65535"] } allow { protocol = "udp" ports = ["0-65535"] } allow { protocol = "icmp" } source_ranges = ["192.168.10.0/24"] target_tags = ["server"] } resource "google_compute_firewall" "allow-internal-lb" { name = "allow-internal-lb" network = "${google_compute_network.example.name}" allow { protocol = "tcp" ports = ["11210"] } source_ranges = ["10.128.0.0/20"] target_tags = ["kvs"] } resource "google_compute_firewall" "allow-health-check" { name = "allow-health-check" network = "${google_compute_network.example.name}" allow { protocol = "tcp" ports = ["0-65535"] } source_ranges = ["35.191.0.0/16","130.211.0.0/22"] target_tags = ["kvs"] } |
ファイアウォールルールを設定します。項目が多いためそれぞれピックアップして説明します。
「xxx.xxx.xxx.xxx/xx」となっている箇所は弊社固定IPになります。
- resource “google_compute_firewall” “allow-icmp”
「example」ネットワーク内の「bastion」タグが付いたリソースに対してソースIPからicmpを許可しています - resource “google_compute_firewall” “allow-tcp-10022”
「example」ネットワーク内の「bastion」タグが付いたリソースに対してソースIPから10022番ポートを許可しています - resource “google_compute_firewall” “allow-tcp-8091”
「example」ネットワーク内の「kvs」タグが付いたリソースに対してソースIPから8091番ポートを許可しています - resource “google_compute_firewall” “allow-internal”
「example」ネットワーク内の「server」タグが付いたリソースに対してソースIPから全ての通信を許可しています - resource “google_compute_firewall” “allow-internal-lb”
- resource “google_compute_firewall” “allow-health-check”
これらの設定は内部ロードバランサ及びヘルスチェックのアクセスを、「example」ネットワーク内の「kvs」タグが付いたリソースに対して許可しています。内部ロードバランサからのアクセスを許可する設定は公式ドキュメントを参考にしています
instancegroupes.tf
1 2 3 4 5 6 7 8 9 10 |
resource "google_compute_instance_group" "kvs-group" { name = "kvs-group" description = "kvs instance group" zone = "${var.region_zone}" instances = [ "${google_compute_instance.kvs01.self_link}", "${google_compute_instance.kvs02.self_link}", "${google_compute_instance.kvs03.self_link}", ] } |
内部ロードバランサから各インスタンスにバランシングさせるためには、対象のインスタンスをインスタンスグループとして登録する必要があります。今回は非マネージドインスタンスグループとして作成します。インスタンスグループに関して詳しくは公式ドキュメントをご参照下さい。
- resource “google_compute_instance_group” “kvs-group”
インスタンスグループを作成します。
・name
インスタンスグループの名前を設定します
・description
作成するインスタンスグループの説明です
・zone
インスタンスグループを作成するゾーンを指定します
・instances
インスタンスグループに登録するインスタンスを指定します
今回はkvs.tfで作成するインスタンスを指定しますが、他のケースで使用する場合にも基本的には以下の形で指定の形で問題ないと思います
${google_compute_instance.インスタンス名.self_link}
※self_linkとは、作成されたリソースのURIを示します。基本的にTerraform側でGCP側から動的に取得してくれます。
internallb.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 |
resource "google_compute_health_check" "kvs-health-check" { name = "kvs-health-check" check_interval_sec = 1 timeout_sec = 1 tcp_health_check { port = "11210" } } resource "google_compute_region_backend_service" "kvs-int-lb" { name = "kvs-int-lb" health_checks = ["${google_compute_health_check.kvs-health-check.self_link}"] protocol = "TCP" timeout_sec = 10 session_affinity = "NONE" region = "${var.region}" backend { group = "${google_compute_instance_group.kvs-group.self_link}" } } resource "google_compute_forwarding_rule" "kvs-int-lb-forwarding-rule" { name = "kvs-int-lb-forwarding-rule" load_balancing_scheme = "INTERNAL" ports = ["11210"] region = "${var.region}" network = "${google_compute_network.example.self_link}" subnetwork = "${google_compute_subnetwork.subnet1.self_link}" backend_service = "${google_compute_region_backend_service.kvs-int-lb.self_link}" ip_address = "192.168.10.100" } |
内部ロードバランサの設定を行います。ここでは実際の内部ロードバランサの設定とともに、ヘルスチェックと転送ルールも併せて設定しています。
- resource “google_compute_health_check” “kvs-health-check”
内部ロードバランサが使用するヘルスチェックリソースを設定します
・name
ヘルスチェックリソースの一意の名前を設定します
・check_interval_sec
ヘルスチェックの間隔を設定します
・timeout_sec
接続失敗を判断するまでの秒数を設定します
・tcp_health_check
ヘルスチェック接続先のポートを設定します - resource “google_compute_region_backend_service” “kvs-int-lb”
内部ロードバランサを設定します
・name
バックエンドサービスの名前を設定します
・protocol
使用するプロトコルを設定します。ここではTCPを指定しています
・health_checks
使用するヘルスチェックリソースを設定します。ここでは先程設定した「kvs-health-check」を指定しています
・timeout_sec
接続要求が失敗したと判断するまで待機する時間を設定します
・session_affinity
使用するアフィニティ機能を設定します。詳細はTerraformの公式ドキュメントと、GCPの公式ドキュメントを参照して下さい
・region
バックエンドが存在するリージョンを設定します。ここでは「variables.tf」で設定した変数を利用しています
・backend
作成する内部ロードバランサを利用するインスタンスグループを設定します - resource “google_compute_forwarding_rule” “kvs-int-lb-forwarding-rule”
内部ロードバランサが利用する転送ルールを設定します
・name
転送リソースの一意の名前を設定します
・load_balancing_scheme
使用するロードバランシングのタイプを設定します。今回は内部ロードバランサなので「INTERNAL」を指定しています
・ports
内部ロードバランサに使用するポートを設定します。このポート宛のパケットが、この転送ルールで指定したバックエンドサービス(kvs-int-lb)に転送されます
・region
転送ルールを使用するリソースが存在するリージョンを設定します
・network
負荷分散対象のネットワークを設定します。ここでは「network.tf」で作成した「example」ネットワークを指定します
・subnetwork
負荷分散対象のサブネットワークを設定します。ここでは「network.tf」で作成した「subnet1」ネットワークを指定します
・backend_service
転送ルールに一致したパケットの転送先のバックエンドサービスを設定します。ここでは先程作成した「kvs-int-lb」を指定します
・ip_address
パケットを最初に受信する静的IPを設定します。この場合だとクライアント側からは「192.168.10.100:11210」宛にKVS用のパケットを送信することになります。
ここまででTerraformのコードの準備が出来ました。
Terraformの実行
コードの準備ができたら、実際にTerrafomを実行してGCP上にリソースを構築します。
・コードの検証
先ずは 「terraform validate」コマンドを使用して作成したコードの構文チェックを行います。
1 |
$ terraform validate |
実行した結果、何も表示されなければ構文に問題はありません。
エラーが出た場合はその内容に沿ってコードの修正を行う必要があります。
・実行計画
構文に問題がなければ、次に「terraform plan」コマンドを実行してGCP上のリソースにどのような変更を加えるか、実行計画を確認します。このコマンドを実施しても実際のGCPリソースに変更は加えられません。
1 |
$ terraform plan |
実行した内容を確認し、実際にコードの内容通りに変更が加えられるかどうかなどをチェックします。
・適用
実行計画に問題がなければ、「terraform apply」コマンドを使用して実際にコードをGCPリソースに適用します。
1 |
$ terraform apply |
実行した内容を確認し、エラーなどが出ていなければGCP上にリソースが作成されているはずです。
後は実際にGoogle Cloud Console上や、「terraform show」コマンドなどでリソースの情報を確認してみましょう。
Terraformで作成したリソースの削除
Terraformで作成したリソースを全て削除する場合は以下の通り実行します
・リソースの削除計画の確認
先ず「terraform plan -destroy」コマンドを使用してどのリソースを削除するのかを確認しておきます。このコマンドを実施しても実際のGCPリソースに変更は加えられません。
1 |
$ terraform plan -destroy |
実行した内容を確認し、削除対象に問題がないことを確認します。
・リソースの削除
「terraform destroy」コマンドを使用して実際に削除処理を行います。実行後確認プロンプトが出てくるはずなので、「yes」を入力して実行を進めます。
1 |
$ terraform destroy |
実行した内容を確認し、エラーが出ていないことと、対象リソースが削除されていることを確認します。
また、Google Cloud Console上でも同様にリソースが削除されていることを確認できると思います。
まとめ
今回はGCP上のリソースをTerraformで作成する場合の一連の作業と、各設定ファイルの詳細、リソースを削除するまでをご紹介しました。
Terraformはまだ検証のみの使用であるため、ご紹介できた機能はごく一部だと思いますが、同じようにGCPリソースをTerraformで管理を始めたような方に少しでもご参考になれば幸いです。