概要 だいぶニッチなのはわかっているのだが、terraformでJSONを作って、その中で配列を渡したい事例があってドハマリしたのでメモ。 対象サービス AWS　EventBridge Scheduler EventBridge schedulerでJSONを渡す EventBridge schedulerでJSONを渡したいという要件だった場合、特に難しく考えなければ下記で十分な場合が多い。 resource "aws_scheduler_schedule" "sample" { ... target { ... input = <<EOT { "example_key" : "example_value" } EOT はたまた、 resource "aws_scheduler_schedule" "batch_scheduler" { ... target { ... input = jsonencode(var.example) } variables "example" { default = { "example_key" : "example_value" } } これでOK. しかし、今回はJSONに <aws.scheduler.execution-id>　を含めたら、jsonencodeでエンコードされて、<と>が\u003cと\u003eという文字列になってしまった。 jsonencode Terraformのjsonencodeでは、<　>はエスケープシーケンスが用意されている。 https://developer.hashicorp.com/terraform/language/functions/jsonencode When encoding strings, this function escapes some characters using Unicode escape sequences: replacing <, >, &, U+2028, and U+2029 with \u003c, \u003e, \u0026, \u2028, and \u2029.

10月から株式会社マクアケでSREとしてお世話になっています。 そんなマクアケのアドベントカレンダー3日目の記事です。 昨日は、絶賛育休中のrenoinnさんのEnt+Atlasでマイグレーションするでした。 最近はTerraformよりもDBのお勉強が多いですが、久しぶりにTerraform関連のブログです。 概要 Terraformを使っていると、いろいろな理由で差分が発生することがある。 terraform管理と手動管理が混ざっている terraformがアップデートされて使えなくなった構文がある プロバイダーがアップデートされて使えなくなった構文がある いずれの理由にせよ、構成ドリフト（設定差異）はterraform適用へのハードルをあげる。 targetで指定すれば良いが、どこか不安が残る、そんなコードになりがちになる。 管理を対象を全てのリソースにしないにせよ、terraformの差分が解消してあることが望ましい。 そんなこんなで、terraformの差分解消に伴うtipsやらポイントを自分のためにもまとめておく。 まずは何はともあれ現状を見てみる 差分を解消しなくてはいけないリポジトリは、常に触っているリポジトリとは限らない。 そうすると、terraform initからはじめる必要がある場合がある。 その場合、いきなりコケて心が折れるかもしれないけれど、まずは落ち着いて terraformのバージョン と 権限　を確認しよう。 特にAWSの権限が実は不足していたなんてことはままある。 backendに指定しているリソース、AWSでS3を使っている場合は、AWS CLIを使って対象のS3へアクセスできることを確認しよう。 私は必ずbackendにS3を使っている場合は、下記が実行できるかを必ず確認しておく。（VPNがつながっていない、SAML認証が通っていない、SAMLのアクセスキーの有効期限が切れていた、、、なんてことはありがち） aws s3 ls XXX terraform init でコケるときはプロバイダーのバージョンも疑う terraform init がコケるなんて、おいおい、、、という気持ちかもしれないが、放置していればそういうこともある。 まして初めて触るリポジトリなら、ありえなくは無い。 上記権限等が問題ないのであれば、プロバイダーのバージョンを疑ってみる。 AWSのプロバイダーだけならまだしも、templateを使ってたり、他のプロバイダーを使っていればコケることはある。 最悪は、すでに動かしている人がいたら、その人から .terraform ごともらえば解消するかもしれない。 terraform planを実行するときは-outで出力するか、-no-colorをつける ということでinitまで出来たら、次はterraform planをしてみる。その結果、大量に差分が出力されることがある。 その場合はファイルに出力してみると差分の作業がやりやすくなる。 terraform plan -out /tmp/diffs.txt このファイルはバイナリで terraform show /tmp/diffs.txt で確認することが可能だ。 もし、ファイルにちょっとメモ書き込みしたり、対応したリソースの行を消したりしたい場合はファイルにリダイレクトすることになる。 しかし、単純にリダイレクトで下記のように実行するとシェルの色の文字コードが出力されてしまう。 $ terraform plan > ~/Downloads/diffs.txt data.template_file.example: Reading... data.template_file.example_test: Reading.

はじめに 副業先で一からAWS環境を作成することになり、そろそろ準備を考えてたときに、ふとTerraformCloudのことを思い出しました。 https://www.hashicorp.com/products/terraform/pricing/ 最低の有料プランのチームで使う場合の違いとして権限管理が異なり、個人ユーズなら無料でも十分使えます。 また、tfstateをS3等で管理したくないのもあり、思い切ってTerraformCloudに任せてみることにしました。 ※なお、AWSアカウントがあり、Terraformに触れたことがある方だったら30分もかからずにセットアップができます。 まずはリポジトリ連携 GitHubでTerraformを管理するリポジトリを作成し、TerraformCloudでWorkspaceを作成します。 この時に、特定のディレクトリをTerraform専用ディレクトリとしている場合は、変更を検知するディレクトリを指定できます。 私の場合は、今回は同じリポジトリでインフラを全部管理する予定だったため、シンプルに「terraform」というディレクトリを作成して指定しました。 backend.tfで変数指定 backend.tfファイルを作成して、varでAWSのアクセスキーとシークレットキーを変数で指定します。 provider "aws" { access_key = var.aws_access_key secret_key = var.aws_secret_key region = "ap-northeast-1" } variables.tfで下記のようにします。 variable "aws_access_key" {} variable "aws_secret_key" {} variable "aws_region" { default = "ap-northeast-1" } そして、Pushする前にTerraformCloudでAWSのアクセスキーとシークレットアクセスキーを登録します。 秘匿情報の場合はSENSITIVEを選択すると、中を確認することが出来ないように設定できます。 この辺はCircleCIなんかと使い方は似ていますね。 早速VPC用のtfを作ります。 resource "aws_vpc" "test-vpc" { cidr_block = "192.168.0.0/16" instance_tenancy = "default" enable_dns_support = true enable_dns_hostnames = true tags = { Name = "test-vpc" } } ここまで来たらテストなのでmasterへPush。