はじめに

こちらの記事では以下のことについて説明しています。

Terraform のベストプラクティスについて
ここまで書いてきた Terraform ファイルのリファクタリング

ここまで構築してきた公式のサンプルを元に改良してきた main.tf ですが、ファイル末尾にリソースをどんどん追記していました。そのおかげで行数は200行超えでかつ、リソースもまとまって書かれていないため可読性の鬼（悪い意味で）になっております。

今回は公式や有志の方が提唱している Terraform のベストプラクティスに従って、今まで書いてきた tf ファイルをリファクタリングしていきます。~~もはや Cloud Run functions 関係ないね。~~

Terraform のベストプラクティスについて

公式が出してくれています。

Googleも GCP リソースを Terraform で構成する際のベストプラクティスを紹介してくれています。

このベストプラクティスのうち、以下を適応しようと思います。

変数を用途や目的がすぐわかる名前を付ける
プロバイダのバージョン固定のため terraform.lock.hcl を Git 管理下に置く
モジュール分割

Terraform ファイルのリファクタリング

変数を用途や目的がすぐわかる名前を付ける

"default" を内容がわかるように変更

# default -> functions_resource
resource "google_storage_bucket" "functions_resource" { ... }

# default -> sample
resource "google_cloudfunctions2_function" "sample" { ... }

# role によって IAM の名称を適切に変更する member -> invoker
resource "google_cloud_run_v2_service_iam_member" "invoker" { ... }

モジュール分割

modules ディレクトリを作成し、論理的に関連するリソースをまとめた構成に作り直します。ベストプラクティスでは modules と同階層に各環境用のディレクトリ prod, pre-prod などを作成していますが、今回紹介しているケースはそこまで規模の大きなプロジェクトを想定していないのでこのケースでは作成しません。

修正後のディレクトリ構成

.
├── modules
│   ├── functions
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   └── variables.tf
│   ├── secrets
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   └── variables.tf
│   ├── espv2
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   └── variables.tf
│   └── scheduler
│       ├── main.tf
│       ├── outputs.tf
│       └── variables.tf
├── main.tf
├── outputs.tf
└── variables.tf

この構成で書き直したものが以下になります。commit 履歴を見て比較してみてください。

おわりに

以上、Terraformファイルのリファクタリングでした。tfファイルは油断していると急激に肥大化していくので、最初からベストプラクティスに則って綺麗に構築しておきたいですね。