Terraformの改善活動まとめ
概要
最近のやっていたTerraformリポジトリの改善活動をまとめる
課題点
リポジトリの分割粒度
prd,stgなどの実行環境ごとにリポジトリが別れており、AWSアカウントとリポジトリが1対1でない。また、明確なルールがない環境のため
- どのリポジトリにコードを書けばいいかわからない
- どのmoduleを使えばいいかわからない(terraform-moduleリポジトリがあるのにdev-terraformリポジトリにもモジュールがある)
- リソースを書く場合リポジトリを間違える、間違いを指摘する手間が増える
- カスタムスクリプトやドキュメントが重複しており管理コストが高い
stateの粒度
1terraform resourceにつき1stateになっていたため
- apply作業を何度も実行する必要がある
- 定期的にapplyされないのでコードとリソースの差分が発生する
- インフラアーキテクチャの全体像が分かりづらい
カスタムスクリプトによる開発体験の低下
- メンテナンスできるメンバーが少ない
- 拡張性の低下
linterなどの周辺ツールを導入するためにカスタムスクリプトに大幅な変更が必要
CI変更時も同様 - terraform applyする対象をファイルで管理するためPR作成時にコンフリクトする
Terraform, AWS providerのバージョンが古い
リソースが細かいことにも相まってバージョンアップ作業が大変
やったこと
リポジトリの統合
リポジトリをmonorepo構成に変更
カスタムスクリプトの脱却
CIの拡張
CodeBuildからGitHub Actionsに変更
- Plan結果をPull Requestのコメントに表示するように変更
- apply結果をSlackに通知
- DynamoDBによるstateのlockの追加
静的解析の追加
- tfsec、tflint、conftestなどの静的解析を導入
Terraform, AWS providerのバージョンアップ
やれなかったこと
- stateの統合
- drift detection
学んだこと
やったことは基本的なことなので、そこから抽象化した学びをメモする
- 守れないルールは必要ないので、ルールと仕組み化はセットにする
- チームとして負債をハンドリングできないと返却に大幅な時間がかかる
- 負債とは正面から向き合う必要があるか考える
- 開発組織の人数規模が増えてくると基礎的なフォローアップや、同じことを繰り返し言う必要がある
