公式

https://www.terraform.io/docs/index.html
GCP用リファレンス

https://registry.terraform.io/providers/hashicorp/google/latest/docs

お便強

https://qiita.com/minamijoyo/items/1f57c62bed781ab8f4d7

https://qiita.com/donko_/items/6289bb31fecfce2cda79

https://www.apps-gcp.com/infra-automation-01/

https://colsis.jp/blog/gcpterraform/

moduleは構成に合わないようなリファクタリングが必要になった時にterraform state mv が必要になってとたんにつらい、moduleを細分化しすぎるとvariable と output が大量に必要になって書きづらい、moduleは再利用できる複数のリソースの単位（プログラミング言語でいうところの関数みたいなもの）で作るのがしっくり

環境情報は外部ファイルが基本

prd/stg/dev環境はprd.tfvars, stg.tfvars, dev.tfvarsを用意

.tfvars　各環境の設定

aws_access_key    = "XXXXXXXXXXXXXXXXXXXX"

aws_secret_key    = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

aws_region        = "eu-west-1"

main.tf

terraform {

  required_version = "= 0.12.26"

}

provider "aws" {

  version    = "2.66.0"

  access_key = var.aws_access_key

  secret_key = var.aws_secret_key

  region     = var.aws_region

}

var.tf　空の受け皿

variable aws_access_key {}

variable aws_secret_key {}

variable aws_region {}

Terraform で変数を使う - Qiita

credentials等の秘匿したい変数を外部のファイルやコマンドライン引数から読み込む

variable "credentials_file" {}　＠var.tf　変数を定義し空にしておく

credentials = file(var.credentials_file)　＠main.tf　ファイルを読むがファイル名は変数

terraform plan -var 'project=' -var 'credentials_file=.json'　＠cmd　プロジェクトとクレデンをコマンド時に指定
他にもvars.tfvars設定ファイル(行頭variableが不要)、TF_VAR_環境変数による指定

Terraformのベストなプラクティスってなんだろうか | フューチャー技術ブログ (future-architect.github.io)
Workspace派、module派、ディレクトリ分離派

HCLの変数は基本2種類のlocalとvariable

variableはグローバル変数、ファイル外やコマンドラインから使える

変数

　variable(input var)はcmd実行時に変数を上書きできるが、localsはできない

　outputはapply時にterminalで値が確認できる、moduleから値を取得する

google_bigquery_connection | Resources | hashicorp/google | Terraform Registry
ドット繋ぎで値を扱える

    for_each = toset(["foo", "bar", "bar"])　でbar, foo

    name = each.key

}

for_each/eachのループ
locals {
    sg = {

        foo = "FOO"
        bar = "BAR"
    }

}
resource "xxx" "aaa" {
    for_each = local.sg
    name = each.key
    description = each.value
}

　　provider "google" {

　　  project = "bangboo-kuso"

　　}

　　terraform {

　　  backend "gcs" {

　　    bucket = "bangboo-kuso-terraform"

　　  }

　　}

　プロジェクトレベルownerのサービスアカウントを持っておく

　セットアップする際にtfsateのbackend保存場所のbucket部分をコメントアウト

　bucketを作るterraformを実施しbucketを作成しつつlocalにtfstateファイルを作成

　再度terraformをするとtfstateファイルがbucketにコピーされる

　bucket部分のコメントアウトを外すと次回tfからはバケットにtfstate更新する
　　このときローカルtfstateの内容をバケットに写すか聞かれるが写す
　　（写さないと差分しかバケットに行かないのでimport等が必要になる）

　リソースタイプや個別パラメータは公式ドキュメントを参照しながら定義

　https://registry.terraform.io/providers/hashicorp/google/latest/docs

リファレンスでoptionalとなっていてもtfファイルでは必要な場合もある

　tfstateファイルからは必要ないとして自動的に削除されるが

スプシをBQでみれるFederatedQueryはテーブルだけ定義しimportしstate show調査

　urlをTFファイルに記載する

シャーディング（日付別）テーブルは定義できないのでは

　生成するクエリの方をTF化したい
Authorized viewはモジュールがあるがconflictがあり全消えする場合がありTF化にまだ向かない

　TFのorg_iamページのArgument referenceのrole項目を見ると

　　Note that custom roles must be of the format organizations/{{org_id}}/roles/{{role_id}}

　TFのorg_iam_custom_roleページのAttributes  referenceのrole項目を見ると

　　id - an identifier for the resource with the format organizations/{{org_id}}/roles/{{role_id}}
　で下記と分かる、使用側と被使用側のTFマニュアルを両方確認する

resource "google_organization_iam_custom_role" "my-custom-role" {

  role_id     = "myCustomRole"

  org_id      = "123456789"

  title       = "My Custom Role"

  description = "A description"

  permissions = ["iam.roles.list", "iam.roles.create", "iam.roles.delete"]

}

resource "google_organization_iam_member" "my-organization" {

  org_id  = "123456789"

  role    = google_organization_iam_custom_role.my-custom-role.id
  #あるいは通常"roles/bigquery.dataEditor"のようにいれるがorganizations/0123456789/roles/chinkoといれる

  member  = "user:jane@example.com"

}
↑
resourceの2番目リソース名を定義しますが任意の名前を指定します
　ここが同じ項目はユニーク制限がない場合は追加としてまとめられます
　通常はユニークにしterraformで管理するリソース名(yourResourceName)を宣言します
　　※1番目のリソースタイプ内でユニークにするのが基本（全体でもユニークの方が分かり易い）

■TFのcount
数を指定してその個数のリソースを作る。なのだが

　enable_lien = true　モジュール側/変数側でこう設定し

　count = var.enable_lien ? 1 : 0　リソース側で3項演算子を使えばIFのように使える
　　※for loopのようなインクリのcount"+="でなく"="の1発実行なので3項演算子でIFになる

gcloud auth login --enable-gdrive-access

gcloud auth application-default login --scopes="https://www.googleapis.com/auth/drive","https://www.googleapis.com/auth/cloud-platform"

排他処理でロックが残る：

他の作業者がいなければ、terraform apply -lock=false で一時的に無視をして続行
エラーIDに対して terraform force-unlock id_num963103164

Terraform と gcloud CLI を使用した完璧な Google Cloud インフラストラクチャの構築 | Google Cloud Blog
gcloud beta resource-config bulk-export --help
gcloud beta resource-config bulk-export --project=kuso12345 --resource-format=terraform --path=/path/to/dir/
　対応を見ると数が少ないgcloud beta resource-config list-resource-types --format=json --project=kuso12345

terraformer import google list --projects=xxxx-123　で対象のリソース確認

terraformer import google --resources=instances,forwardingRules --regions=us-west1 --projects=xxxx-123　とか

https://www.apps-gcp.com/terraformit-gcp/

https://qiita.com/uu4k/items/48d3ecfefe57dba1d7e1

■Terraform applyで意図しない権限削除で障害が発生する
Terraform x GCP で、IAM権限を全削除してしまった - Qiita
google_bigquery_dataset_iam_member：roleとmemberを1対1でresourceを作りまくる、Non-authoritative
　※_iam_policyや_bindingはまとめ易そうだが権限消しそう


Terraform で GCP のサービスアカウントを管理する - Eng (なりたい) (hatenablog.com)
Terraform で GCP IAM 設定どれ使うのがいいのか - pokutuna (scrapbox.io)
google_project_iam | Resources | hashicorp/google | Terraform Registry
Authoritative: TFに明示していないものをApply時に削除しますという意、TFの権威
Non-authoritative: TFは権威を示さず、TFに明示していないものは現状維持ですという意

■勝手に公開
terraform vpc auto_create_subnetworks = falseにせなサブネットを公開して作りよる
Cloud sqlのtfファイルに記述がなくてもtf stateにはPWが出てしまう＞tf化したくない

■Applyの依存関係はdepends_on(プロジェクト作成の前に権限を付与しようとしてエラー等の順序)
[Terraform]Module間の値の受け渡しについて | DevelopersIO (classmethod.jp)
　これより先にあれをTFしてくれという記述

■データセット
google_bigquery_dataset | Resources | hashicorp/google | Terraform Registry
スキーマ取得: bq show --schema --format=prettyjson bangboo-prj:test-dataset.tbl001
ビューはコンソール＞BQ＞該当ビュー＞detailからコピー

■組織ポリシー
google_organization_policy | Resources | hashicorp/google | Terraform Registry
制約について  |  Resource Manager のドキュメント  |  Google Cloud

■parallelismで早くなるかもしれない
あなたのterraform planを手軽に高速化する（かもしれない）魔法の言葉 - Qiita

■テスト
TF Apply後には検証をしっかりしたい、最低Apply後にPlanを再実行したい、テストスクリプト的にチェックしたい
適応されていないことや、TF定義とtfstateと実設定の差分が想定と違うことがある感じがするからだ
moduleを含めて条件的な書き方だと、適応の順序の関係で適応が抜け2回以上TF applyしないといけなかったり

■TFファイルを分割し部分的に別環境へTFファイルを移行したい
tf stateファイルを新環境用にコピー
TFファイルを分割：現行の部分的に削除したTFファイル、と新環境用のTFファイルを準備
tf stateから不要部分を削除
　terrafrom state rm {{asset}}
terrafrom planで差分がないことを確認
新環境用にコピーしたtf stateファイルを編集し準備
　下の terraform state push xxx.tfstate で変更された状態をtf stateファイルに書き戻すことができる？
　このコマンドを実行する前に必要に応じて terraform state pull で最新の状態を取得？

　ダメなら terraform state rm で不要分を削る

新環境用にtfファイルを準備
新環境で下記を実行
　terraform init
　terraform state push xxx.tfstate
　terraform planで差分がないことを確認

■GCP権限（メールの変名時）

　これにクレデンシャルファイルのパスを渡すとサービスアカウントでgcloudコマンド打てるはず