Cloud RunとCloud SchedulerをIaC化するために、初めてterraformを触ったのでメモ

既にterraform(以下tfと略す)化されていたインフラ構成があったが、想像よりちゃんと勉強しないと全く分からんて感じだったので、まずtfの概要を学ぶ。
ざっくり言って、下記のtfコマンドと参考にした記事が理解できれば、なんとなくtfのコードが読めるようにはなった。

流れ

• 下記を参考にtfenvを入れて、tfのversion管理ができるようにする
  • https://dev.classmethod.jp/articles/beginner-terraform-install-mac/
• 「参考」に載せた記事を一通り読んで、tfの文法やディレクトリ構成パターンを理解する
• 下記とかを読んで、コマンドをなんとなく把握する
  • https://cloud.google.com/docs/terraform/basic-commands?hl=ja

コマンド

# 最初だけやればOK。pluginをinstallしてくれるやつ。
terraform init

# これらのコマンドでtf化したインフラ構成を作ったり、壊したりできる。
terraform validate
terraform plan
terraform apply
terraform destroy

参考

• https://y-ohgi.com/introduction-terraform/handson/syntax/
• https://dev.classmethod.jp/articles/terraform-bset-practice-jp/
• https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/getting_started

余談
シェルでterraformって毎回打つと、左手人差し指の消耗が激しいので、下記のようなaliasを掘ると便利な気がする。

# vim ~/.zshrcして下記を追記する
alias tf="terraform"

なんとなくtfが理解できたが、既存のtfリソースをいきなり修正するのは不安が大きかったので、一旦サンプルをググってみた。
そうしたらCloud Scheduler + Cloud Runをtfで構築するっていうドンピシャな下記サンプルがGCP公式であったのでやってみた。
サンプル: https://cloud.google.com/run/docs/triggering/using-scheduler?hl=ja#terraform

上記のサンプル自体は(確か)問題なく構築できるが、Cloud Runの設定を変更してtf applyすると、なぜかmodifyingで処理が終わらない現象が発生した。

結論から言うと下記のオプションを追加する必要があった。
この記事に救われた。
せっかちなので、timeout上限値の15mまで待てなくてエラーメッセージが表示される前にctrl + cしていたので、これに死ぬほどハマった。

autogenerate_revision_name = true

余談
Cloud RunとCloud SchedulerをGUI上で構築して、それをtf形式でexportしたら秒で終わるんじゃないか説があったが、tf形式でのexportがサポートされていないぽく諦めた(2023/05/20現在)。

下記のコマンドでtf形式のexportがされているGCPリソースが分かる。

gcloud beta resource-config list-resource-types

https://cloud.google.com/docs/terraform/resource-management/export?hl=ja#filter_the_output

サンプルを構築できたので、開発環境でCloud Run + Cloud Schedulerを構築してみた。
その際になんやかんやあって、Cloud RunはGUIで既存のCloud Runをコピーして作った方がコスパ良さそうと判断して、結局Cloud Schedulerだけ構築した。

Cloud Schedulerはjob毎に愚直にtfを書かないで、下記記事の「Scheduler」のサンプルのようにfor_eachで書くと保守しやすくて良さげだった。

参考: https://swfz.hatenablog.com/entry/2020/12/12/235827

最終的にCloud Schedulerのtfは下記のようになった。

locals {
  params = {
    one        = {
      body = "test"
      cron  = "* * * * *"
    }
    two = {
      body = "test-2"
      cron  = "* * * * *"
    }
  }
}

resource "google_cloud_scheduler_job" "batch-test" {
  for_each = local.params

  name             = "test-job-${each.key}"
  description      = "test http job"
  schedule         = each.value.cron
  time_zone        = "Asia/Tokyo"
  attempt_deadline = "320s"

  retry_config {
    retry_count          = 1
    max_backoff_duration = "3600s"
    max_doublings        = 5
    max_retry_duration   = "0s"
    min_backoff_duration = "5s"
  }

  http_target {
    http_method = "POST"
    # Note: uriはハードコーディングしたので、場合によって修正が必要
    uri         = "xxx"

    oidc_token {
      # audienceもハードコーディングする予定(動作未検証)
      audience              = "xxx"
     
      # service_account_emailは自分の環境のものの指定が必要
      service_account_email = "xxx"
    }
  }
}

Cloud RunはIaC化していないが、構築済みのCloud Runはyamlで吐くことができる。
吐かれたyamlを元にCloud Runも構築できるので、まあいいかなっていう(そもそもCloud Runはコピー簡単だし)。

初めてtfでIaC化してみたけど、全部をコード化するのは結構大変でコスパ悪い気はした。
この記事で言及されているOS領域はIaC化、クラウド領域は軽く管理っていうのが妥当な気がする。