TL;DR
- 手動管理されていたリスナールールをIaC化した
- IaC化するためにTerraformのimportブロック使った
- 思わぬ恩恵受けた
- 手動更新のミスを減らせるぜ〜くらいの想定だった
元々どんな状態だったか
本番環境のリスナールールはコード管理されていて、ステージング環境のリスナールールは手動管理されていました。
（ALB自体のリソースはTerraformで管理されていましたが、リスナールールだけ手動で更新していたという状況）
ステージングだけ手動更新しているのも気持ち悪いなあ…というお気持ちと、新規参画者が入ってきた時に「なんでステージングだけ手動更新？」って違和感を抱きそうなのでIaC化したいという気持ちはありました。
（ステージングだけ手動更新になった背景は長くなるので割愛します）
どうやってIaC化したか
Terraformのimportブロックを使ってIaC化しました！
ALBのリスナールールなのでimportの記述は以下のように書きました。
import {
to = aws_lb_listener_rule.example
id = "リスナールールのARN"
}
インポート先（to指定したリソース）となるリソースも作成してあげます。
resource "aws_lb_listener_rule" "example" {
listener_arn = aws_lb_listener.example.arn
priority = 1 // 実際にインポートするリスナールールのpriorityと合わせる
// その他必要な記述
}
気をつけたこと
インポートした際に、実際に稼働しているリソースと設定に差分が生まれないように注意しました。
プルリクを出した際に走らせるCIの中に、terraform planコマンドで差分を出すワークフローを組んでいるのですが、そこで想定外の差分が出てないかレビュー時にチェックしました。
具体的には、
- priority◯番のリスナールールのconditionこれで合ってる？
- リソースが変にupdate・destroyされていないか
- インポート漏れがないか
- インポートされた数と実際のリスナールールの数が一致しているか
などの観点でチェックしました。
コード管理の恩恵
手動更新によるミスを防いだり、ミスったとしても前の状態に戻しやすいという恩恵は想像に難くないと思いますが、弊社事情で結構嬉しい出来事がありました。
ステージング環境のドメイン名を変えるという話があって、その作業を行なっていたのですが、リスナールールのconditionにドメイン名を指定している部分があったので、そこは全部改修の対象となりました。
ですが、そもそもの前提として、リスナールールが実は80個くらいありまして、、
（IaC化を精神的に妨げていた要因でもありますw）
どれだけ変えないといけないんだ…と思っていたのですが、コード管理したことで
Local Valueで定義していたドメイン名を修正しただけで作業が終了しました！
（Local Valueってなに？という話はこちら）
手動更新によるミスを防ぎつつ、時短効果も生んでくれたという恩恵がありました😀
手動で1つずつポチポチ修正することを考えたら恐ろしいです…。。
まとめ
IaC化って面倒に思うかもしれないですが、やって損はないですし、何かしらの形で返ってくるかなと思うので、ぜひトライしてみてください！
Discussion