Open11
terraformとGCP周りのあれこれ
gontaあれこれ
こちらを使ってterraformのイメージをわかせる
gontaVite, Reactの静的ファイルを Cloud CDN + Cloud Storage + Load Balancer
gonta保存したplan結果を使用してapply
terraform apply tfplan
github actionでのGCPの情報を取得する時に参考にさせていただいた。
gonta以下のようにして特定のリソースの情報に絞って確認ができる
terraform show | grep -A 5 "google_iam_workload_identity_pool\."
terraform applyをするとずっと作られているとエラーが出ていたが、GUIで見ると30日間の保存をされて、完全削除ができていなかったからだった。
gontaおそらくはterraform destroyをしたけど、実際はterraformのリソースが完全削除をするわけではなかったということなのではないかと思っている。
gonta- terraformのstateファイルはgit管理をしない前提の理解が大事
- bootstrapのディレクトリを作って、これだけをローカルのstateファイルにおこうと思ったけど、もしも消えたりしたら嫌なので、やっぱり良くない。
全てstorageに置くようにする。
gonta変数使えない。
backend "gcs" {
//
}
MacBook-Air gcp-organization-terraform % terraform init
Initializing the backend...
╷
│ Error: Variables not allowed
│
│ on versions.tf line 5, in terraform:
│ 5: bucket = "${var.organization_id}-terraform-state"
│
│ Variables may not be used here.
このあたりでGCPとcloud storage, cloud run cloud sqlなどを使ってterraformで管理をして大枠のGCPについての理解が深まった気がする
gonta学んだこと
- ディレクトリ構成はenviromentsなどできっちり分けておく。
- 可能であればdev, prodからmodulesを呼び出して、バケツで渡して対応をする。これにより、devとprodのリソースは基本的に一致をする
- 最初のプロジェクトの初期開発ではstateはローカルで属人的に開発でもいいかも。ある程度できた段階でcloud storageのバケットにstateをおいて管理をするくらいが良さそう。
- google providerでは対応をしていないことがあって、google-beta？を使わないといけないことがある。
- iamも最初の組織で権限をちゃんと分けておいた方が良さそう。
- userは開発時の権限に関しては、開発用のグループを作っておいて、そのグループにroleを割り当てる。そのグループにユーザーを招待をする
- 権限は最小権限の原則が望ましいが、roleの中の詳細な権限が多すぎるのである程度大雑把に権限をつけてもいいかもしれない。例えば「編集者権限」など
- サービスアカウントをgithub用で作ったり、することもある。
- GCPでやるなら最初に組織があったほうが良さそう。