tfaction v0.5.0 の update
tfaction という、 GitHub Actions で良い感じの Terraform Workflow を構築するための Action を開発しています。
先日リリースした v0.5.0 で追加された機能について紹介します。
リリースノートにも変更点などを書いてあるのでそちらも参照してください。
-
BREAKING CHANGE tfmigrate で State をまたいで migration をする際に使う label の prefix が
ignore:からskip:に変わりました。挙動も変わり、 terraform plan, apply 以外は実行されるようになりました - tfaction の自動 PR 作成機能に関し、 feature branch だけ作成し PR は敢えて作成しないようにする option が追加されました
- Terraform Modules 管理がサポートされました
BREAKING CHANGE ignore: から skip: へ
tfaction では tfmigrate で State をまたいで migration をする場合、元々 ignore: で始まる label をつける必要がありました。
working directory A から B に migration する場合、 tfmigrate:A と ignore:B, あるいは tfmigrate:B と ignore:A という label をつける感じです。
これは tfmigrate を実行しない方の working directory で terraform plan や apply が実行されるのを防ぐためのものでしたが、 ignore: label をつけると list-targets で対象から除外されて build matrix で job が起動しないので、 plan や apply だけでなく、 linter や formatter も実行されませんでした。
例えばあるリソースを別の state に移動した際、使われなくなった local value がそのまま残ってしまっていたとしても今までは気づけませんでした。
そこで ignore: label を廃止し、 skip: で始まる label を使うようになりました。
skip: label では terraform plan, apply は実行されないものの、その他の処理は実行されるので上記のような問題は起こりません。
あえて PR を作成しない option
tfaction には working directory や tfmigrate の migration などを scaffold する Pull Request や、 apply が失敗したあとの Follow up Pull Request を自動生成する機能があります。
これは非常に便利なのですが、 GitHub App によって Pull Request が作られるため、作成された Pull Request に変更を加えて自分で approve することが出来、 review を必須にしたい場合に不都合な場合もあります。
それを防ぐための option として、 tfaction-root.yaml に skip_create_pr: true とすると、
Pull Request の代わりに feature branch だけ作成し、 GitHub CLI を使って PR を作成するコマンドをユーザーに案内するようになります。
ユーザーは案内されたコマンドをコピペして実行すれば Pull Request が作成されます。 Pull Request の作成者はその人になるので、自分で approve することはできなくなります。
案内がどのようなものかは、ドキュメントのスクショを見てください。
Follow up Pull Request は Pull Request へのコメントでメンションもされるので割と気づきやすいですが、
Scaffold に関しては GitHub Actions の Annotation で通知もないし Summary を見ないと気づきにくいのが難点です。
まぁこのオプションを使う代わりに 2 approve 必須にすればいいのではないかといった意見もあると思いますし、
特に GitHub App で Pull Request が作られることが気にならなければこのオプションを使わなくても良いとは思います(ユーザー的にはそちらのほうが便利でわかりやすいかと思います)。
Terraform Modules 管理
- Module の Scaffold
- Module の CI (lint, format, document 自動生成)
- Module の Release (Versioning)
がサポートされました。
自前の Terraform Modules をいかに管理するかは Terraform における一つのトピックで、やり方を模索している人もいるかと思います。
tfaction では以下のようなやり方で Modules を管理するワークフローを提供するようになりました。
- Module も同じ Monorepo で管理する
- GitHub Release を作成し、 Module ごとに versioning する
- Module Source としては GitHub を使う
- 各 Module の root directory 配下に
tfaction_module.yamlというファイルを置く(現状中身は見てないので空で良い)。 tfaction はこのファイルがあるディレクトリを Module として認識する
Monorepo で管理することで CI などの仕組みを共通化し、管理対象を減らすことでメンテナンスコストを減らしつつ共通化された仕組みを改善していくことで
改善の恩恵をすべての Module に反映させることが出来ます。
また、 Module を Local paths ではなく version を指定するようにすることで
Module の変更を特定の working directory から段階的にリリースしたり、 Pull Request を分けてリリースすることが出来ます。
Module を変更する際に terraofrm plan を実行して動作確認したい場合、一時的に Local paths に切り替えることで簡単に確認できます。
リポジトリが分かれているとやりづらかったりするので、これも同じリポジトリで Module を管理するメリットかなと思います。
同じリポジトリの GitHub Source であれば簡単に Private な Module をダウンロードできます。
Private Repository で Module のダウンロードに失敗した場合、 gh auth setup-git を実行すると解消するかと思います。
terraform fmt による自動フォーマット, terraform validate, tflint, tfsec による lint, terraform-docs によるドキュメントの自動生成などが CI で実行され、非常に便利です。
新たに terraform-docs が必要になるため、 aqua.yaml に追加してください。
# -i は aqua >= v1.1.0 が必要
$ aqua g -i terraform-docs/terraform-docs
Scaffold だけでなく、 Release のための Actions も提供されています。
といっても今の所 release-module では tag, release の作成くらいで大したことはしていないのですが、
scaffold から release まで一貫してワークフローが提供されているので、自分たちでどうするか考えなくて良いので便利です。
現状の課題としては、 Module の自動 update がまだサポートされていません。
Module 管理を導入する方法
Release Note に書いてあるように workflow を修正してください。
Discussion