tfaction による Terraform の Drift Detection
tfaction という、 GitHub Actions で Terraform Workflow を構築するための Action を開発しています。
今回 tfaction が Terraform の Drift Detection をサポートしたので紹介します。
詳細に関しては公式ドキュメントを参照してください。
Drift Detection とは
ここでいう Drift とは、 IaC においてコードによるインフラの定義と実際のインフラの状態が乖離していることを指し、 Drift Detection とはその Drift を検出することを指しています。
Terraform に限らず、 IaC において Drift Detection は重要なトピックです。 Drift が常態化しているとコードの信頼性がなくなります。
なにか変更を加える際にその変更と関係な差分が検出され、その変更が何なのか、変更を適用して大丈夫なのか確認する作業が発生し生産性を低下させます。
Drift を素早く検出・修正することが IaC においては重要です。
tfaction の Drift Detection
tfaction の Drift Detection の概要を説明します。
なお、 tfaction の Drift Detection はあくまで Drift を検出するだけであり、自動で Drift を解消したりはしません。みなさんが自分で解消する必要があります。
tfaction では各 working directory ごとに GitHub Issue を作成することで Drift を管理します。
Drift が検出されると Issue が Reopen され、 Drift が解消されると Close されます。
Issue は working directory ごとに 1 つだけ作成され、それがずっと流用されます。つまり Drift が解消された後に再び Drift が発生した際、 tfaction は新しく Issue を作るのではなく既存の Issue を Reopen します。
Drift Detection は以下のタイミングで行われます。
- apply (
terraform apply,tfmigrate apply) の実行時 - GitHub Actions Workflow
schedule-detect-driftsの schedule 実行時
各 working directory で plan や apply を実行することで Drift を検出します。
plan が No change, または apply が成功した場合は Drift がないとみなされ、 Issue が close されます。逆に plan が No change ではない、または apply が失敗した場合は Drift があるとみなされ、 Issue が Reopen されます。
plan や apply の実行結果は Issue にコメントされます。コメントには workflow 及び pull request へのリンクもついています。
Issue に plan や apply の実行結果が履歴として残るので、 Issue を見ることでいつどのタイミングで Drift が発生したか追跡しやすくなります。
コメントを Issue の description に反映させることも出来るので、態々最新のコメントまで遡らなくても最新の結果を把握することが出来ます。
plan の schedule 実行では Issue の最終更新日時が閾値より古い n 個 の working directory に plan を実行していきます。
plan や apply 実行時に結果を Issue にコメントするので、 Issue の最終更新日時が更新されます。そのため最終更新日時が古い = Drift Detection がしばらく実行されていないというロジックになります。
Drift Detection を有効にする場合、デフォルトでは全ての working directory で有効になりますが、特定の working directory だけ有効・無効にすることもできます。
⚠️ Issue title を変更しない
tfaction は Issue title を元に Issue を検索するので、 title は変更しないでください。
Terraform Drift で始まるような Issue を別の目的で作成しないでください。
title はユニークでなければなりません。
もし working directory の target 名 が変更された場合、 tfaction は自動でその working directory 用に新しい Issue に作成します。
もし同じ Issue を引き継ぎたい場合、 Issue の title を新しい target 名に合わせて変更してください。
何らかの理由で Issue を作り直したくなった場合、古い Issue をリネームないし削除してください。
working directory の削除などの理由で Issue に対応する working directory が見つからなくなった場合、 tfaction は自動でその Issue をリネーム、 Close します。
運用イメージ
Drift Detection を有効化し、 Issue が作られるようになっても、それを元に Drift を解消しなければ意味がありません。
どのように解消していくかは勿論皆さんの自由ですし、チームや組織の規模・構成・方針などによっても変わるとは思いますが、
自分個人が思い描く運用のイメージを参考までに少し紹介します(比較的規模の大きな組織を想定しています)。
- Issue を GitHub Project に追加する
- Project (Kanban) を定期的(毎朝とか)にチェックし、 Open になっている Issue に人を assign し、ハンドリングする
一人で頑張ると運用が続かないので、 team 内でローテーションするのが良いでしょう。
また各 working directory ごとに product team が ownership を持っているような場合、 product team に Issue をハンドリングしてもらうようにできるのが良いでしょう(まぁ難しいケースも少なくないとは思いますが)。
もしリアルタイムに通知が欲しい場合、 tfaction の Drift Detection 自体にはリアルタイム通知の仕組みはありませんが、 Slack と GitHub を integration して通知を飛ばすようにしたり、 GitHub Actions で issue の event を trigger に workflow を実行したり、やりようはあると思います。
ただ、リアルタイム通知は結構ノイズになったり無駄に消耗する可能性もあるので個人的にはオススメしません。
最後に
以上、 tfaction における Terraform の Drift Detection について紹介しました。
Terraform の Drift Detection は個人的に以前より解決したい課題であり、自分なりの解を OSS で形にできたことに満足しています。
GitHub で完結していて外部ストレージなどを必要としない点、チャットツールへのその場限りの通知ではなく GitHub Issue で管理できるという点も個人的に良いと思っています。
詳細は公式ドキュメントも参照してください。
Discussion