data "aws_caller_identity" "current" {} output "account_id" { value = data.aws_caller_identity.current.account_id } 若干補足しておくと、 "${}" 自体が廃止されたわけではなく、今でも文字列の中に変数を埋め込む場合には必要ですが、式が変数の参照しか含まない場合は不要で、v0.13.4以降は冗長な書き方は警告が出ます。ちなみにv0.14のfmtはもう一歩踏み込んで、この書き方を自動で修正するようになりました。古いサンプルコードを雑にコピペできるようになってべんり。 Terraformではなく汎用的なHCLそのものの仕様を調べたいときは、 hashicorp/hcl にありますが、本稿執筆時点ではデフォルトのmasterブランチはまだHCL1であることに注意して下さい。 HCL

はじめに 以前、Terraform本体/プロバイダ/モジュールのバージョンアップを自動化するtfupdateというツールを書いたのですが 、Terraformのバージョン制約だけじゃなくて、もうちょっと汎用的にHCLがコマンドで編集できたら便利では？と思って、hcleditというツールを書いてみました。 まだできることはそれほど多くはないのですが、設計方針というか特徴はこんなかんじです。 標準入出力でHCLを読み書きするので、簡単に他のコマンドとパイプして組み合わせることが可能です。 HCLのまま直接トークンを書き換えるので、可能な限りソースコード内のコメントを維持します。これは既存のHCLファイルをスクリプトなどで一括処理するのに便利です。 Terraformには依存せず、汎用的なHCLを対象にしているのでスキーマレスです。 HCL2対応(というかHCL1はサポートするつもりはありません

はじめに Terraform職人のみなさんは無限に「ぼくのかんがえたさいきょうのディレクトリ構成」についてメリデメを議論していますが、未だに銀の弾丸のようなベストプラクティスは見つかっていないようです。なぜでしょう？ それは最適解がサービスの規模、組織の構造、メンバーのスキルなどいろいろな変数に依存しているからです。さらに悩ましいことに、これらの要因は固定ではなく変化するので、ある時点での最適解が時間の経過とともに現状にうまくマッチしなくなり、いわゆる技術的負債になったりします。つらい。 個人的な解釈では、組織の成熟度に合わせてモジュールを細かく切っていく方向に徐々に向かっていくというような傾向があるようには思いますが、組織のフェーズによってうつりかわるものなので、唯一の最適解というものはそもそも存在しないのです。そんなこんなで、最近の私の関心事は、理想と現実がずれてきたときに、どうやった

はじめに Terraform職人あらためシニアHCLエンジニア（？）の @minamijoyo です。 最近はHCL(HashiCorp Configuration Language)のパーサで遊んでいます。Terraformの設定をパースしていいかんじに書き換えることができるようになると夢が広がりますよね？ そんな個人的な趣味の産物として、Terraform本体/プロバイダ/モジュールのバージョン制約をいいかんじに一括で書き換えてくれる tfupdate というツールを書いたので紹介します。 これをCIとかジョブスケジューラで流せば、毎日最新版をチェックして、差分があれば自動でバージョンアップのPull Requestを生成したりできます。つまり、「ぼくのかんがえたさいきょうのTerraform版Dependabot」ができるのだ。 ※この記事は クラウドワークス Advent Cale

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

だいたい50万行ぐらい増えて100万行ぐらい減ってる(!?) これはもはや別物でわ。。。なんか削除行数の方が多くてあってるのかこれ自信がない。vendor配下の差分？ いや、むしろこれでよく表面上はv0.11と互換性保ってるよね。 0.12upgradeは何をしているのか とはいえ0.11と0.12でいろいろ非互換な変更は入ってるので、移行を手助けするために0.12upgradeというサブコマンドがTerraform v0.12に付いてます。（あ、うっかり仕事に役立つ情報を書いてしまった。ごめんね。 手元の3万行ぐらいのv0.11のコードベースに0.12upgradeを流したら6000行ぐらいdiffが出ました。0.12upgradeがなかったら死んでいた。0.12upgradeすごい（小並感 さて、こいつは一体何をしてるのでしょう？気になりますよね？ 実装を読むよりもテストケースに入出力

terraform planのdiff見づらいですよね。 JSONが1行の文字列として扱われてどこがdiffだか分からんかったり。 そこで、landscapeですよ。 Before After クッソ見やすい。 インストール Rubyのgemとして配布されています。

はじめに この記事はGo (その3) Advent Calendar 2016の18日目の記事です。 最近Goの勉強がてら、とある社内向けWebサービスのAPIを叩くCLIツールを書いてます。 有名どころのWebサービスならたいてい既に誰かがSDKなりCLIツールを作ってたりするので、それを使ればよいと思いますが、クローズドな社内向けのWebサービスとかだと、まぁ欲しい人が自分で書くしかないですね。 で、簡単なプロトタイプが動くようになったので、このあたりで覚えたことを整理してまとめてアウトプットしておこうかなと思います。 内容的には サブコマンド形式のCLIツールを作り方 spf13/cobraの使い方 viperと連携した透過的な設定ファイルの読み込み version番号の埋め込み、Makefile pkg/errorsによるエラーの伝搬、contextを使ったタイムアウト 標準のne

はじめに Docker使ってるとできるだけイメージは共通化して、設定ファイルはマウントで差し込み、環境ごとの設定差分は環境変数で埋め込む方向になってきます。 しかしながら、設定ファイルに環境変数を直接埋め込めるかは対象のソフトウェアの実装次第で、例えばfluentdは設定ファイルで環境変数を直接埋め込めるけど、nginxは環境変数を直接埋め込めなかったりします。 で、よくやるのは entrypoint.sh みたいなのを作って起動時にsedするという原始的な方法もあるけど、もうちょっとスマートな方法として、 envsubst という軽量なテンプレートエンジンを使うことで、設定ファイルに汎用的に環境変数を埋め込むことができて便利なので紹介したい。 インストール nginx:alpineには既にenvsubstコマンド入ってるので、そのまま使える。 他のイメージで入ってなければ以下の方法でイン

はじめに インフラ周りのテストにServerspecを使ってますが、よく書くテストの書き方がある程度パターン化してきたので、コピペで使えるサンプルの例文集としてまとめておきます。 この記事の目的は特に機能の網羅性をカバーしようというわけではありません。よくあるユースケースとして、Serverspecでこーゆーのどう書くの？と思ったときのスニペットとしてご利用下さい。 基本 インストール関連 パッケージがインストールされているか確認する

TL; DR AWSのKMSのキーポリシーで暗号化/復号化の権限付与する対象のPrincipalにIAMユーザとIAMロールは指定できるのに、なぜだかIAMグループは指定できない。 IAMグループで管理するにはKMSのキーポリシーでIAMポリシーを有効化するように設定し、別途IAMポリシーをIAMグループに付与することでIAMグループ単位での制御が可能となる キーポリシー { "Version": "2012-10-17", "Id": "key-consolepolicy-2", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::111122223333:root"}, "Action": "kms:*", "Resour