Zenn
Closed8

Terraform で Google Cloud の ロードバランサーを管理下にしたい

Terraform
Google Cloud
waddy_uwaddy_u

動機

  • ロードバランサーの設定、画面からポチポチするほうがわかりやすい
  • でもやっぱりインフラもバージョン管理したい
  • Serverless NEG とか含めるとどのへんんまでTerraform管理化におけばよさそうか塩梅があまりわかってない
  • そもそもどう書けば良いかわからない

このあたりを明らかにしたい。

waddy_uwaddy_u

出力してみる？

gcloud コマンドで terraform 記述をエクスポートするやつがあるらしいのでちょっと試してみる

https://cloud-ace.jp/tech_blog/gcp-bulk-export/

gcloud beta resource-config bulk-export --on-error=continue \
    --resource-format=terraform \
    --project=YOUR_PROJECT_ID > resources.tf

待つ。5分くらいでした。3158行のresource.tfが作成された！

waddy_uwaddy_u

そもそも ロードバランサーのリソースがわからん

Terrafrom だとどれにあたるんだ、というのを探してたら良い資料があった。やっぱり最後は本家よな。

https://cloud.google.com/blog/ja/products/serverless/serverless-load-balancing-terraform-hard-way

gcloud コマンドでやってくださっているこちらもイメージがわきやすい。

https://saitosho.me/blog/2021-07-04-network-endpoint-group/

  • google_compute_global_forwarding_rule: IP アドレスの HTTPS トラフィックをターゲット HTTP プロキシにルーティングする（？）
  • google_compute_target_https_proxy: HTTPプロキシで証明書を使いトラフィックを終端、URLマップにルーティング
  • google_compute_url_map: URLマッピングのリソース
  • google_compute_backend_service: バックエンドサービスのHTTPサーバー設定
  • google_compute_region_network_endpoint_group: Serverless NEG

おぼろげにイメージが湧いてきた。

waddy_uwaddy_u

Terraform方針

  • 証明書はインフラ・アプリ開発のとメンテナンスサイクルが違いそう（最初に画面から登録することも多そう）なので、静的な値として証明書IDをパラメータを入力する
  • App Engine や Cloud Run のアプリケーションも上記の理由と一緒でインフラとアプリのサイクルが違うのでTerraform管理からは外れそう（gcloudでデプロイすることも多そう）というわけでAppEngine CloudRun リソースも静的なものにする

Terrafrom 管理下におくリソース

  • google_compute_region_network_endpoint_group
  • google_compute_backend_service
  • google_compute_url_map
  • google_compute_target_https_proxy
  • google_compute_global_forwarding_rule
waddy_uwaddy_u

import中...

バックエンドサービスにIAPが紐付いているケース

google_compute_backend_serviceについて。IAPをくっつける場合、デプロイ時にiap設定が必要なのだが…

iap {
 oauth2_client_id
 oauth2_client_secret
}

機密情報を管理したくないので、 data でとってこれないでしょうか。

https://registry.terraform.io/providers/hashicorp/google/latest/docs/data-sources/iap_client

data "google_iap_client" "iap_cleint" {
  brand     = 
  client_id = 
}

client_id はいいとして、 brand って何？
gcloudコマンドでだしてみる。

https://cloud.google.com/sdk/gcloud/reference/alpha/iap/oauth-brands

gcloud alpha iap oauth-brands list --project=sample
ERROR: (gcloud.alpha.iap.oauth-brands.list) INVALID_ARGUMENT: Request contains an invalid argument.

あれれ〜おかしいぞ〜？

注: API で作成された内部ブランドがパブリックに設定されると、identityAwareProxyClients.create() API は機能しなくなります。これは、ブランドを内部に設定する必要があるためです。したがって、内部ブランドがパブリックになった後は、API を介して新しい OAuth クライアントを作成できません。
https://cloud.google.com/iap/docs/programmatic-oauth-clients#branding

これでしょうか。残念ながらAPIでとってくることはできない様子。シークレットを入れるしかないか〜

waddy_uwaddy_u

元気に動いています

パスマッピングを手元から変更できるので便利！結局以下のリソースをimportしました

resource "google_compute_region_network_endpoint_group"

# ロードバランサーのバックエンド:
resource "google_compute_backend_service"

# ロードバランサーのバックエンド：アセット用バケット
resource "google_compute_backend_bucket"

# URLマッピング
resource "google_compute_url_map"

# 終端するための証明書 意図せずリプレースが実行されるため参照にとどめる
data "google_compute_ssl_certificate"

# ロードバランサー
resource "google_compute_target_https_proxy"

# ロードバランサー用のグローバルIPアドレス。Terraform管理下にすると差分になってしまうので、
# 管理画面で作成したものを参照して使う。
data "google_compute_global_address"

# ロードバランサーの転送ルール設定
resource "google_compute_global_forwarding_rule"

ポイントは、証明書やグローバルIPアドレスなど、

  • 一度つくったらあとから更新することはほとんどない
  • 検証などで先に手でつくりがち

なものは、わりきってimportせず参照にとどめるとうまく扱えます。

このスクラップは2022/03/03にクローズされました