はじめに
こちらの記事では以下のことについて説明しています。
- Terraform のベストプラクティスについて
- ここまで書いてきた Terraform ファイルのリファクタリング
ここまで構築してきた公式のサンプルを元に改良してきた main.tf
ですが、ファイル末尾にリソースをどんどん追記していました。そのおかげで行数は200行超えでかつ、リソースもまとまって書かれていないため可読性の鬼(悪い意味で)になっております。
今回は公式や有志の方が提唱している Terraform のベストプラクティスに従って、今まで書いてきた tf ファイルをリファクタリングしていきます。もはや Cloud Run functions 関係ないね。
Terraform のベストプラクティスについて
公式が出してくれています。
Googleも GCP リソースを Terraform で構成する際のベストプラクティスを紹介してくれています。
このベストプラクティスのうち、以下を適応しようと思います。
- 変数を用途や目的がすぐわかる名前を付ける
- プロバイダのバージョン固定のため
terraform.lock.hcl
を Git 管理下に置く - モジュール分割
Terraform ファイルのリファクタリング
変数を用途や目的がすぐわかる名前を付ける
# 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
この構成で書き直したものが以下になります。
おわりに
以上、Terraformファイルのリファクタリングでした。tfファイルは油断していると急激に肥大化していくので、最初からベストプラクティスに則って綺麗に構築しておきたいですね。