terraform

結論 Terraform がリソース間の依存を張るのは、式が別のリソースや module の output を参照したときと、depends_on を書いたときだけ。同じ値を文字列や root の変数で渡しても依存はできず、親と子は並行に作られる 依存が無くても、親が既にある環境では通る。落ちるのはまっさらな環境への初回 apply だけで、Firestore の Field が 404 になったり、API の有効化より先にリソースの作成が走ったりする depends_on = [module.x] は x の全リソースを待つ。x の中に自分の出力を使うリソースがあると、依存が一周して cycle (循環参照) になり、Error: Cycle で落ちる。x の output を書けば、その output が参照するリソースだけを待つ 設定を持つ provider ブロックを中に書いた module には、depends_on (と count / for_each) を付けられない。provider は root へ上げる module の depends_on は、依存先に未適用の変更がある plan で、module 内の data source の読み込みを apply 時まで遅らせる。その値を ForceNew の属性に渡すと、何も変わっていなくても replace が出る 以下のコードと出力は Terraform v1.15.8 で確かめた。使ったのは terraform init -backend=false と terraform validate だけで、plan / apply は打っていない。 GCP の API を呼ぶ節と data source の節は、作業ログの記録をもとに書いた。 ...

terrarorm init で バケットがなければ作成する バケット名は ${project_id}-${app}-tfstate とする project_id, app は Makefile で指定 terraform コマンドをラップした Makefile app := sample project_id := project-a export init_tfstate_gs: @init_gs_tfstate_if_needed init: init_tfstate_gs @echo "==> Initializing terraform..." @make _tf cmd=init init_if_needed: @if [[ ! -e envs/$(stage)/.terraform ]]; then \ make init; \ fi login: @make _tf cmd=login init_upgrade: @make _tf cmd=init opt="-upgrade=true" init_migrate_state: @make _tf cmd=init opt="-migrate-state" plan: init_if_needed @make _tf cmd=plan apply: init_if_needed @make _tf cmd=apply apply-auto-approve: @make _tf cmd=apply opt=-auto-approve apply-refresh: @make _tf cmd=apply opt=-refresh-only destroy: @make _tf cmd=destroy refresh: @make _tf cmd=refresh show: @make _tf cmd=show output: @make _tf cmd=output opt=-json console: @make _tf cmd=console validate: @make _tf cmd=validate _check_env: @test -e envs/$(stage) || (echo 'No such stage:envs/$(stage) exist.' && exit 1) _tf: _check_env @cd envs/$(stage) && \ terraform $(tf_opt) $(cmd) $(opt) バケット作成スクリプト init_gs_tfstate_if_needed #!/usr/bin/env -S bash -e app=${app:-""} && readonly app region=${region:-"us-central1"} && readonly region main() { if [[ -z ${app} ]]; then echo "==> app is required." exit 1 fi local project_id bucket_tfstate project_id=$(gcloud config get-value project) if [[ -z ${project_id} ]]; then echo "==> project_id is required." exit 1 fi bucket_tfstate="${project_id}-${app}-tfstate" if gsutil ls | grep "gs://${bucket_tfstate}" &>/dev/null; then echo "==> Already tfstate ${bucket_tfstate} exist." return fi echo "==> Creating tfstate ${bucket_tfstate}..." gsutil mb -l "${region}" "gs://${bucket_tfstate}" gsutil versioning set on "gs://${bucket_tfstate}" echo "==> Bucket created!" } main "$@" terraform backend を GCS backet に設定する terraform { backend "gcs" { bucket = "project-a-sample-tfstate" prefix = "terraform/state" } }

まとめ Terraform で google_api_gateway_api_config に api_config_id は設定しない 以下詳細 以下のように api_config_id を設定すると、再作成時にエラーが発生する resource "google_api_gateway_api_config" "default" { project = var.project_id provider = google-beta api = google_api_gateway_api.default.api_id api_config_id = "${var.env}-${var.service}-api-config" openapi_documents { document { path = "openapi.yaml" contents = base64encode(templatefile("${path.module}/openapi.yaml", { title = "${var.env} ${var.service} API" description = "This is the API for ${var.env} ${var.service}" version = "1.0.0" managed_service = google_api_gateway_api.default.managed_service func_url = google_cloud_run_service.default.status[0].url })) } } lifecycle { create_before_destroy = true } } │ Error: Error creating ApiConfig: googleapi: Error 409: Resource 'projects/{project_id}/locations/global/apis/{api_id}/configs/{api_config_name}' already exists │ Details: │ [ │ { │ "@type": "type.googleapis.com/google.rpc.ResourceInfo", │ "resourceName": "projects/{project_id}/locations/global/apis/{api_id}/configs/{api_config_name}" │ } │ ] 一見、create_before_destroy = true が指定されているので、新しいリソースを作成してから古いリソースを削除するように見えるが、 実際には api_config_id が変更されていないため、新しいリソースを作成することができない 省略した場合はタイムスタンプベースでIDが振られている… terraform-YYYYMMDDHHMMSS000000000001-xxxxxxxxxxxxx

はじめに tflint 利用時のメモ 想定するディレクトリ構成 環境は dev, prd など 環境毎にディレクトリを切る 各環境の main.tf から使用したい module を使う module は 機能単位でディレクトリを切る cognitoとかで切ってるけど、サービスの有効無効など、もう少し大きな単位で切っても良いイメージ ├── envs │ ├── dev │ │ ├── main.tf │ │ ├── outputs.tf │ │ ├── swagger.yaml │ │ ├── terraform.tfvars │ │ └── variables.tf │ └── prd │ ├── main.tf │ └── ... └── module_aws ├── cognito │ ├── main.tf │ ├── outputs.tf │ └── variables.tf └── s3 ├── main.tf ├── outputs.tf └── variables.tf tflint の設定ファイルの読み込み優先順位: tflint/docs/user-guide/config.md at master · terraform-linters/tflint File passed by the –config option File set by the TFLINT_CONFIG_FILE environment variable Current directory (./.tflint.hcl) Home directory (~/.tflint.hcl) awsでこんな設定をしてみた # 結構口うるさいタイプ plugin "terraform" { enabled = true preset = "all" } # `tflint --init` needed plugin "aws" { enabled = true # deep_check = true version = "0.34.0" source = "github.com/terraform-linters/tflint-ruleset-aws" } # rule "terraform_required_version" { # enabled = false # } # # rule "terraform_required_providers" { # enabled = false # } よくでてくるエラーは以下 variable.tf ではなく、variables.tf にする output は outputs.tf に書く outputs.tf は空でも要る output, variable には description を書く 無視する方法は以下 以下のように tflint-ignore を書く # tflint-ignore: terraform_required_version # tflint-ignore: terraform_required_providers module を再帰的にチェックはしない --recursive を指定しても、ロードしている module のなかまでチェックされない ref: tflint の仕様や使い方についてのメモ 対象のディレクトリ(module)に移動または、–chdirで指定して、モジュールのチェックを行う必要がある => 想定構成のディレクトリでは、構成のルートディレクトリから --recursive つけて tflint すればいい => envs配下も、module_aws 配下もチェックされる Terraform 的には 暗黙的 プロバイダの継承 を推奨？ Providers Within Modules - Configuration Language | Terraform | HashiCorp Developer For convenience in simple configurations, a child module automatically inherits default provider configurations from its parent. This means that explicit provider blocks appear only in the root module, and downstream modules can simply declare resources for that provider and have them automatically associated with the root provider configurations. ...

はじめに 色々調べたのでメモ.. 以下詳細 Terraform で Lambdaも管理できないか？ 最近やってるLambdaとAPI Gatewayの開発方法の話 tf, ecr, python, openapi TerraformでAPI Gateway + Lambdaの構成テンプレート #lambda - Qiita tf, NOT ecr, node, openapi TerraformでAmazon API Gatewayを構築する(基本編) #AWS - Qiita tf, NOT ecr, openapi LambdaをカスタムDockerランタイムで開発する方法 | フューチャー技術ブログ コンテナイメージを更新した際に気をつけるポイントですが、latestタグのコンテナイメージを更新しても、 すぐにLambda関数の挙動には反映されません。一晩寝かしても古いイメージが参照されていました。 全く同じimage-uriのまま更新コマンドを実行することで即時反映できます。 TerraformでLambdaコンテナイメージを自動構築する #Docker - Qiita swagger ecr lambda apigateway codebuild aws_lambda_alias lambda version に対するエイリアス これに対するIgnore設定の記載など 【AWS Lambda】複数のLambda関数を１つのコンテナイメージにまとめる #AWS - Qiita entrypoint指定できる aws_lambda_function | Resources | hashicorp/aws | Terraform | Terraform Registry ここでいうhandler? Terraform で ApiGateway を作成する 【Terraform】Terraformで作るサーバレス構成（API Gateway、Lambda、DynamoDB） TerraformでAmazon API Gatewayを構築するサンプルコードを書いてみた #AWS - Qiita Terraform で API Gateway（REST API）を構築する | DevelopersIO How to Create API Gateway With Terraform and AWS Lambda Creating a Rest API in AWS API Gateway using Terraform and OpenAPI Swagger specification | by InovaOnlineSolutions | Medium ECR の Pros and Cons Cons AWS Lambda で Go ランタイムを使うのが良いと思っている理由 基本的にコンテナイメージより zip 形式の方が安く使える コンテナイメージとカスタムランタイムは Lambda 関数の初期化時にも課金が発生する ...