【要約】【Terraform】planとplan -refresh-onlyの結果で、ドリフトを2種類に分類する [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
複数チームでAWS環境を共有する現場では、アプリチームがコンソールから直接設定変更を行うことがある。これにより、Terraformの管理状態と実環境に乖離が生じる。
- ・コンソール操作による、Terraform外からの意図しない構成変更。
- ・
terraform apply後のコードマージ忘れによる、適用済み変更の巻き戻しリスク。
// Approach
筆者は、2つのコマンドの比較対象の違いを利用し、ドリフトの性質を自動分類する仕組みを構築した。
- ・
terraform plan（コード vs 実インフラ）とplan -refresh-only（state vs 実インフラ）を併用する。 - ・GitHub Actionsで定期実行し、結果をSlackへ通知する。
- ・Terraformの終了コードの不安定さを考慮し、
terraform show -jsonからresource_driftの件数を取得して判定する。
// Result
この仕組みにより、ドリフトの原因を特定した状態での自動通知が可能となった。
- ・「コンソールでの手動変更」と「コードの未マージ」を明確に区別して通知できる。
- ・原因に応じた適切なアクション（CloudTrail確認やマージ作業）を即座に判断できる。
- ・JSON解析により、Terraformの不具合を回避し、実運用に耐えうる堅牢な検知フローを実現した。
Senior Engineer Insight
> ドリフト検知の自動化はIaC運用の基本だ。原因の切り分けまで踏み込む点は実戦的である。特に、終了コードに依存せず、JSON解析で判定する実装は、運用の堅牢性を確保する上で極めて重要だ。単なる検知に留まらず、運用コストを下げ、開発体験を向上させる優れたアプローチである。