Dependabot の Terraform 1.0 対応が完了した件

[2021-05-27-1] のつづき。この間に 1.0 がリリースされてました ね。 先ほど、Lockfile (.terraform.lock.hcl) の対応が完了したそうです。 https://github.com/dependabot/dependabot-core/issues/1176#issuecomment-858490407 これで Dependabot での terraform 対応が完了しました。 ・terraform version は自動更新できない ・provider version を自動更新できる。その際、.terraform.lock.hcl も更新されるはず ・以前の Dependabot で対応されていた module version はどうなんだろう?使ってないので分からない dependabot.yml のドキュメントはこちら。 circleci-tfupdate-orb はそろそろアーカイブしたいな。でも Dependabot だと terraform version は更新出来ないんだよね…。 追記(2021-06-11): 公式でもアナウンスされてました。 Dependabot now supports Terraform 1.0|GitHub Changelog

2021-06-10 (Thu) · masutaka

Dependabot の Terraform 0.15 対応が進んでいる件

最近この Issue が活発になってきました。 Terraform 0.15 support · Issue #1176 · dependabot/dependabot-core 実はプロバイダーバージョンのアップデートだけならもう使えます。 ・プロバイダーバージョンのアップデートはもう動く ・↑の後に必要な .terraform.lock.hcl の更新は実装中とのこと。現在は手動で “$ terraform init -upgrade” が必要 ・terraform バージョンのアップデートはロードマップに含まれていない ↓プライベートリポジトリで動いている様子。 dependabot.yml のドキュメントはここにある ので、試してみるのも良いかもしれません。 ↓このブログが置いてあるリポジトリの .github/dependabot.yml です。daily はやり過ぎなのであとで減らそう。 version: 2 updates: - package-ecosystem: "terraform" directory: "/terraform/aws" schedule: interval: "daily" time: "12:00" timezone: "Asia/Tokyo" assignees: - "masutaka" open-pull-requests-limit: 10 - package-ecosystem: "terraform" directory: "/terraform/heroku" schedule: interval: "daily" time: "12:00" timezone: "Asia/Tokyo" assignees: - "masutaka" open-pull-requests-limit: 10 今までの経緯とか Terraform 0....

2021-05-27 (Thu) · masutaka

terraform を再帰的に実行する Makefile

[2019-05-07-1] に紹介した『Pragmatic Terraform on AWS 』に沿って設計すると、terraform のディレクトリは複数出来ると思います。 依存を分けることと、まとめて実行することはやや矛盾します。とは言え terraform や terraform provider がアップデートした時の terraform init/plan/apply はまとめてやりたいものです。 少し前に作って使っていますが、なかなか良い感じです。 使っている Makefile たち この辺りを工夫しました。 ・terraform init/plan/apply に失敗すると、即座に停止する ・make の -C オプションを使って、cd せずに make を実行できている。つまり cd .. とかで戻る必要がない。そういう理由で下位ディレクトリに Makefile 置いてる ・make の -w オプションを使って、以下のようなそれっぽいログを出している $ make init-r make[1]: Entering directory `/Users/masutaka/src/github.com/masutaka/masutaka.net/terraform/aws' (snip) make[1]: Leaving directory `/Users/masutaka/src/github.com/masutaka/masutaka.net/terraform/aws' make[1]: Entering directory `/Users/masutaka/src/github.com/masutaka/masutaka.net/terraform/heroku' (snip) make[1]: Leaving directory `/Users/masutaka/src/github.com/masutaka/masutaka.net/terraform/heroku' direnv 使う場合 terraform では credential を注入するケースも多いので、direnv も使うことは多いのではないでしょうか。ルートに .envrc があるだけなら別ですが、各ディレクトリにもある場合はこのパッチが必要になると思います。...

2020-03-26 (Thu) · masutaka

terraform-provider-healthchecksio を Terraform Plugin SDK に移行した

今まで terraform provider のビルドには、terraform 自体をライブラリとして要求されました。今後は terraform-plugin-sdk を使います。 この PR で移行しました。 Migrate over to new terraform SDK by masutaka · Pull Request #16 · kristofferahl/terraform-provider-healthchecksio ※ https://healthchecks.io はバッチが時間通りに動いたかの監視で重宝しています。 仕事で使っている terraform-provider-heroku の v2.2.1 で知りました。 9/26 にアナウンスがあったのかな? 知らなかった。 loading... https://www.terraform.io/docs/extend/plugin-sdk.html に従うだけで割と簡単です。tf-sdk-migrator という移行ツールが用意されています。 $ go get github.com/hashicorp/tf-sdk-migrator $ go mod vendor $ tf-sdk-migrator check $ tf-sdk-migrator migrate $ tf-sdk-migrator check (snip) exit status 1 build github.com/kristofferahl/terraform-provider-healthchecksio: cannot load github.com/hashicorp/terraform/helper/schema: open /Users/masutaka/src/github.com/kristofferahl/terraform-provider-healthchecksio/vendor/github.com/hashicorp/terraform/helper/schema: no such file or directory...

2019-10-10 (Thu) · masutaka

『Pragmatic Terraform on AWS』を読んだ

【ダウンロード版】Pragmatic Terraform on AWS - KOS-MOS - BOOTH これも職場の同僚氏がオススメしていた本。 普段から Terraform の設計に課題を感じていたので、ざーっと斜め読みして、第17章からしっかり読んだ。 その中での設計のやり方が モノリス → モジュールの利用 → 環境(ステージ)の分離 → コンポーネント分離 と段階を踏んでおりとても良いと思った。そう、これなんですよ。最初は main.tf だけで十分。 Terraform の設計はアプリケーション設計とよく似ており、初めから抽象化すると難しくなると思う。 基本は宣言的に書いていき、設定ファイルのような読めるコードにする。3回くらい重複し始めたくらいで、変数やモジュールに落とし込むのが良いはず。 17.4.1 の “安定度の高いコンポーネントは、変動を想定したコンポーネントに依存してはいけません” もまさにアプリケーション設計あるある。『オブジェクト指向設計実践ガイド 』にも同じことが書いてある。→ [2016-09-22-1] [2017-11-01-1] Terraform の Workspaces をオススメしない点にも同意。状態を気にしながらの terraform apply は怖い。 18.4 のリモートステートは知らなかった。便利そう。現状、ちょっとだけ関連があるリソースを同じコンポーネント(ディレクトリ)に集めている。リモートのバックエンドを使えば疎結合に出来るかも。Data Source でも良いと思うけどね。 Terraform だけでなく、第19章のように AWS のベストプラクティスが書かれている点も良い。S3 の暗号化は確認しようと思った。 ちなみにダウンロード版には .epub と .pdf しか存在しない。kindlegen 使って .mobi に変換して、Kindle 用のメールアドレスに送った。久々だと忘れちゃうね。 $ brew cask install kindlegen $ kindlegen PragmaticTerraformOnAWS.epub 追記(2019-05-10): 作者様からありがたいお言葉が・・・! loading... 追記(2022-03-03):...

2019-05-07 (Tue) · masutaka