2017年11月16日0件のコメントはじめまして。GMOアドマーケティングでインフラを担当しているa.sです。今回はTerraformを用いて、GCP上に検証環境を構築する機会がありましたので、構築に伴う一連の作業をご紹介します。既存のオンプレミス環境から接続可能なKVSサーバ環境を構築します。目的として、オンプレミス環境上に構築しているKVSサーバを物理的にスケールする作業のコストをクラウド化することで下げたいというものです。以下のような構成になります。KVSサーバはGCPで提供されているCentOS7のイメージを使用して構築します。Gatewayで暗号化して行います。KVSへの接続は内部ロードバランサを介して各KVSサーバにバランシングする設計としています。Storage)上で行います。Server)上からansibleで行います(本ブログでは触れません)。残念ながら、VPN環境は現時点では構築できていないため、その他のGCPリソースをTerraform化したもののご紹介となります。弊社ではCentOS7の環境で実施します。GCPのプロジェクトGCPの環境を構築するためにGCP上でプロジェクトを作成しておきます。API」を有効化しておきます。Console上からサービスアカウントを作成します。accounts」を選択します。ACCOUNT」を選択します。name」に適当な名前を入力し、「Role」部で必要な権限を選択します。Admin」を付与します。鍵が必要になるので、json形式の鍵を選択して、「CREATE」を選択します。この鍵は再ダウンロードが出来ないので、大切に保管します。※鍵の再設定は可能なので、万が一鍵を紛失した際は再設定を行います。SDKのインストール及び、認証作業を実施します。CentOS)」部を参考にしています。example-project5.認証した情報を確認します。Storage上で管理するため、保存するためのバケットを作成するTerraformはデフォルトだと「terraform.tfstate」という名前のファイルで管理対象のインフラの状態を保存しています。Terraformはこのファイルに基づいて、インフラの構成の変更などを検知し、必要に応じてリソースの作成や削除、変更などを行っています。チームでTerraformを運用する場合、各々でtfstateファイルの状態が異なると矛盾が生じてしまうため、今回の場合はGCS上にtfstateファイルを保持することで情報の一貫性を保ちます。SDKインストール時に併せてインストールされるgsutilコマンドを用いてGCS上にtfstateファイルを保存しておくためのバケットを作成します。gs://example_tf-state-prod/gsutilコマンドの各オプションの意味は以下の通りです。mbバケットを作成します-p作成するバケットの対象プロジェクト名を指定します-c作成するストレージクラスを指定します-lバケットロケーションを指定しますgs://example_tf-state-prod/「gs://バケット名/」として作成するバケットを指定しますTerraformのインストールTerraformのインストールを行います。今回はTerraform実行ユーザの「~/terraform」以下にインストールします。~/.bash_profileインストール後、以下コマンドでバージョンが確認できればインストールに成功しています。v0.10.4Terraformのコードを書くTerraformの実行環境が整ったところで、ここからは実際にTerraformのコードを書いていきます。Language、HCLという言語で記述します。「*.tf」という拡張子を持つファイルにコードを書くことで、Terraformがそれをテンプレートとして自動的に認識します。Terraform用に適当なディレクトリを作成して、その中に設定ファイルを作成していきます。今回作成する「*.tf」ファイルの構成は以下の通りです。今回は分かりやすくするために各機能ごとにファイルを分けました。以下からは個別に設定ファイルと、設定内容の詳細を記載します。"asia-northeast1"}接続するプロバイダー(今回はGCP)を設定します。provider接続先を設定します。今回はgoogleとなりますcredentials認証情報を設定します。"/path/to/gcp-managemant-key.json"}}tfstateファイルをGCS上で管理するための設定です。backend対象のバックエンドサービス(gcs)を指定しますbucket作成したバケットを指定しますpath対象のtfstateファイルのパスを指定しますcredentials認証情報を指定します。〜EOF}各設定ファイル内で使用する変数を設定します。〜)を登録しています。"${var.region}"}カスタムVPCネットワークを設定します。“example”ネットワークリソースを作成します・nameネットワークの一意の名前を設定します。“subnet1”サブネットワークリソースを作成します・nameサブネットワークの一意の名前を設定します。ここでは「subnet1」としています・ip_cidr_range作成するネットワークレンジを設定します。ここでは「192.168.10.0/24」を設定しています・networkこのサブネットワークが属する親ネットワークを設定します。“example”」を指定しているということになります。Serverを構築するための設定です。Serverに割り当てる静的グローバルIPアドレスリソースを設定します・name一意の「bastion01」というリソース名を設定します・region静的グローバルIPアドレスリソースを作成するリージョンを設定します。」で作成した静的グローバルIPを割り振ります。・metadataここではSSH用の公開鍵を登録しています。個別にインスタンスに公開鍵を登録するため「block-project-ssh-keys」を有効化します。Serverを構築するための設定です。["kvs"]}ファイアウォールルールを設定します。項目が多いためそれぞれピックアップして説明します。「xxx.xxx.xxx.xxx/xx」となっている箇所は弊社固定IPになります。“allow-health-check”これらの設定は内部ロードバランサ及びヘルスチェックのアクセスを、「example」ネットワーク内の「kvs」タグが付いたリソースに対して許可しています。["${google_compute_instance.kvs01.self_link}","${google_compute_instance.kvs02.self_link}","${google_compute_instance.kvs03.self_link}",]}内部ロードバランサから各インスタンスにバランシングさせるためには、対象のインスタンスをインスタンスグループとして登録する必要があります。今回は非マネージドインスタンスグループとして作成します。インスタンスグループに関して詳しくは公式ドキュメントをご参照下さい。“kvs-group”インスタンスグループを作成します。・nameインスタンスグループの名前を設定します・description作成するインスタンスグループの説明です・zoneインスタンスグループを作成するゾーンを指定します・instancesインスタンスグループに登録するインスタンスを指定します今回はkvs.tfで作成するインスタンスを指定しますが、他のケースで使用する場合にも基本的には以下の形で指定の形で問題ないと思います${google_compute_instance.インスタンス名.self_link}※self_linkとは、作成されたリソースのURIを示します。基本的にTerraform側でGCP側から動的に取得してくれます。"192.168.10.100"}内部ロードバランサの設定を行います。ここでは実際の内部ロードバランサの設定とともに、ヘルスチェックと転送ルールも併せて設定しています。“kvs-int-lb”内部ロードバランサを設定します・nameバックエンドサービスの名前を設定します・protocol使用するプロトコルを設定します。ここではTCPを指定しています・health_checks使用するヘルスチェックリソースを設定します。ここでは先程設定した「kvs-health-check」を指定しています・timeout_sec接続要求が失敗したと判断するまで待機する時間を設定します・session_affinity使用するアフィニティ機能を設定します。詳細はTerraformの公式ドキュメントと、GCPの公式ドキュメントを参照して下さい・regionバックエンドが存在するリージョンを設定します。“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上にリソースを構築します。validate」コマンドを使用して作成したコードの構文チェックを行います。validate実行した結果、何も表示されなければ構文に問題はありません。plan」コマンドを実行してGCP上のリソースにどのような変更を加えるか、実行計画を確認します。このコマンドを実施しても実際のGCPリソースに変更は加えられません。apply」コマンドを使用して実際にコードをGCPリソースに適用します。apply実行した内容を確認し、エラーなどが出ていなければGCP上にリソースが作成されているはずです。show」コマンドなどでリソースの情報を確認してみましょう。-destroy」コマンドを使用してどのリソースを削除するのかを確認しておきます。このコマンドを実施しても実際のGCPリソースに変更は加えられません。-destroy実行した内容を確認し、削除対象に問題がないことを確認します。destroy」コマンドを使用して実際に削除処理を行います。実行後確認プロンプトが出てくるはずなので、「yes」を入力して実行を進めます。destroy実行した内容を確認し、エラーが出ていないことと、対象リソースが削除されていることを確認します。Console上でも同様にリソースが削除されていることを確認できると思います。まとめ今回はGCP上のリソースをTerraformで作成する場合の一連の作業と、各設定ファイルの詳細、リソースを削除するまでをご紹介しました。Terraformはまだ検証のみの使用であるため、ご紹介できた機能はごく一部だと思いますが、同じようにGCPリソースをTerraformで管理を始めたような方に少しでもご参考になれば幸いです。@gmoap_engineer本ブログで発信される情報は、各エンジニア個人の見解であり、弊社の公式見解ではありません。本ブログに掲載、引用等をしている商品またはサービス等の名称は、各社の商標または登録商標です。その他の事項について一切責任を負いかねます。発表する情報には注意を払っておりますが、公式発表、見解については、弊社WEBサイトおよびプレスリリースなどをご確認ください。GMOインターネットグループにおけるソーシャルメディア運用ポリシーについては次のページをご確認ください。本ブログに掲載のあるソフトウェアのダウンロードは自己責任で御願い致します。ソフトウェアのダウンロードの結果、ご利用者に何らかの損失・損害が生じたといえども、当社ではその責任を負いかねます。本ブログに掲載のあるソフトウェアを扱う際は、各ソフトウェアの公式リファレンスを参照のもとご使用下さい。ソフトウェアの実行の結果、ご利用者に何らかの損失・損害が生じたといえども、当社ではその責任を負いかねます。