本記事はFIXER Advent Calendar 2024（ FIXER Advent Calendar 2024 ～tech編～）12月6日の記事です。

概要

Terraform、Terragrunt、Providerの依存関係を自動でアップデートすることは、IaCレベルでのセキュリティ、安定性、機能性を維持するために重要です。本記事では、これらの依存関係を自動アップグレードするに至った背景や目的、実際の運用ルールについてまとめたいと思います。

※本記事作成時点では、依存関係自動アップグレードの十分な運用実績を確保できていないため、実際の導入方法や運用時のメリットデメリットなどは記述しません。機会があれば、実際に運用してみた結果をまとめる記事を書くかもしれません。

背景

TerraformやTerragruntを使用して、クラウドインフラストラクチャは頻繁に更新される一方で、これらのバージョンや依存関係の更新が滅多に行われないことがサービスの運用上の問題となっていました。これらの管理・運用が行われない要因として、手動での更新管理が時間と労力を要すること、また、作業要員が不足していることが挙げられます。

高品質なサービス運用を実現するためにはこの問題を解決する必要があり、バージョンや依存関係の更新を自動化し、システマティックな運用を実現する必要があります。

目的

TerraformやTerragrunt、これらに付随するProviderのバージョンや依存関係を自動で更新することで、潜在的なセキュリティリスクを軽減し、質の高いIaC運用を実現することが目的です。

この目的を達成するために、GitHub上の任意のリポジトリでRenovateを有効化し、TerraformやTerragrunt、これらに付随するProviderのバージョンを自動更新します。

依存関係自動更新ツール

ソフトウェアで使用するライブラリやパッケージの自動更新ツールとして、Dependabotと Renovateが挙げられます。

Renovate選定理由

結論として、今回はTerraform、TerragruntとProviderの依存関係自動更新ツールとしてRenovateを選定しました。

理由は以下の3点です。

複数のアップデートを1つのPRに集約できるため。依存関係自動更新を有効化するリポジトリは、ディレクトリ構成、モノレポやポリレポになるかも定まっていなかったので、今後の構成に応じて柔軟に対応する必要がありました。
設定項目が豊富で、柔軟なカスタマイズが可能なため。上述の説明と同じです。
二次ドキュメントが豊富にあるため。TerraformとProviderの依存関係自動更新に限り、Renovateが多く採用されている技術記事を確認できたので、ユニークな部分で困った場合に解決が容易であり、また、実際に使用されている設定ファイルなどが公開されていることもあり、Dependabotより導入障壁が低く感じました。

運用ルール

Renovateを運用するうえでのルールを以下の通り定めます。

PRの自動マージ
- 手動でマージします。これは依存関係自動更新ツールを有効化するリポジトリの都合上、マージによってCDが起動し、開発環境のインフラストラクチャに意図しない変更を加えないためです。ただし、今後の運用でマージまで自動化する方針を視野に入れて運用します。
PRの発行頻度
- 1週間に1回の頻度。これはTerraformやTerragrunt、Providerの多くが1週間に1度、マイナーバージョンあるいはパッチバージョンのアップデートを実施しているため、暫定的にこの頻度にしました。運用しながら、この頻度でPRを発行した場合、人的なPRチェックやマージの負担を考慮して再度検討する必要があるかもしれません。
PRの粒度
- リポジトリ内のすべてのアップデートを1つのPRにまとめます。ただし、こちらも運用上で不備があれば、適宜修正する要諦です。
PRの確認者
- ひとまず1人ですべてのPRを確認します。最終的には、運用上で問題がないと感じ、知見が溜まったのちにチーム内でランダムに1人を選択し、PRの確認を実施できればと考えています。
ブランチ戦略
- 下記の画像のとおり、git-flowにRenovateブランチを組み込みます。Renovateによって作成されるブランチ名はrenovate/から始まります。

まとめ

Terraform、Terragrunt、Providerの依存関係を自動でアップデートすることに至った背景や目的などを記述しました。この導入によって、今まで以上にIaCの運用が向上することを期待しています。