おはようございます、YASUです。
これまでTerraformを、自分のパソコンから手動でplan・applyしてきましたが、実務ではこの一連の流れをCI/CD(継続的インテグレーション・継続的デリバリー)と組み合わせて自動化するのが一般的です。今日は、その仕組みの考え方を整理してみます。
結論
PR(プルリクエスト)を出すと、自動でterraform planが実行されて、その結果がPRのコメントに表示される。これにより、レビュアーは「このコードを適用したら何が起きるか」を、コードを読むだけでなく実際の差分として確認できるようになります。
これまでの手動運用の限界
個人の練習であれば、自分のパソコンでterraform planを実行し、内容を目で見て、大丈夫そうならterraform applyする、という流れで十分でした。しかしチーム開発になると、次のような課題が出てきます。
- 誰かが
planの内容を確認せずに、うっかりapplyしてしまう可能性がある - レビュアーが、コードの差分(
git diff)だけを見て、実際にAWS上で何が起きるかを想像しなければならない - applyを実行する人のパソコンの環境やバージョンによって、結果が微妙に変わることがある
CI/CDと組み合わせるとどうなるか
GitHub ActionsのようなCI/CDの仕組みを使うと、こんな流れが実現できます。
1. developerがブランチを切って、Terraformのコードを変更する
2. mainブランチに対してPRを作成する
3. PRが作成されたタイミングで、CI/CDが自動的に terraform plan を実行する
4. plan の結果が、PRのコメント欄に自動で投稿される
5. レビュアーは、コードの差分と plan の結果、両方を見てレビューする
6. 問題なければPRを承認してマージする
7. マージされたタイミングで、CI/CDが自動的に terraform apply を実行するつまり、以前学んだ「PRを出してレビューしてもらってからマージする」というGitのワークフローと、Terraformのplan/applyの仕組みが、そのまま組み合わさっている形です。
なぜこれが重要なのか
以前、planは「何が変わるかを予告するだけ」で、applyで初めて実際にAWS上に反映される、という2段階の安全装置について書きました。CI/CDと組み合わせることで、この安全装置がさらに強化されます。
- 人為的なミスを防ぐ:誰かが手元で勝手に
applyすることを防ぎ、必ずマージ経由でしか本番環境に反映されないようにできる - レビューの質が上がる:コードだけでなく、実際に何が起きるかの差分をレビュアーが見られる
- 実行環境が統一される:CI/CDサーバー上で常に同じバージョン・同じ設定で実行されるので、「自分のパソコンでは動いたのに」という事故を防げる
身近な例えで考えると
以前紹介したGitのコンフリクト解消や、モジュール化の話とも通じますが、Terraformの世界でも「個人の注意力に頼らず、仕組みで事故を防ぐ」という発想が根底にあります。CI/CDは、まさにその仕組み化の代表例です。
まとめ
- 個人の手動運用では、applyし忘れやミスのリスクが残る
- PRをトリガーに自動で
planを実行し、結果をコメントに表示する仕組みがCI/CD連携の基本 - マージ後に自動で
applyすることで、必ずレビューを経てから本番に反映される - 「個人の注意力」ではなく「仕組み」で事故を防ぐという発想は、Git運用ともTerraform運用とも共通している
まだ自分の環境でCI/CDを組んだことはありませんが、これまで学んできたGitのPRレビューとTerraformのplan/applyが、実務ではこうして繋がっているのだと分かり、点と点が線になった感覚がありました。それでは、また明日!
コメント