Codeシリーズで作る TerraformのCICDパイプライン概要

プロフィール 名前：檜山 準（ひやま じゅん） 所属：I◯◯◯ お仕事：クラウドエンジニア（設計、構築、運用保守） https://twitter.com/hiyanger https://qiita.com/hiyanger https://zenn.dev/hiyanger 最近よく使う技術：AWS、IaC、CI/CD　 出身：栃木県 よかったら フォローしてね！

もくじ 全体構成 この構成にした理由 各環境のデプロイ方法 クロスアカウント 承認フェーズ 実際に運用して困ったこと

全体構成

全体構成 黒線：パイプラインのメイン動作 緑線：アーティファクト系の動作 オレンジ線：Terraformのバックエンド動作

なんでこの構成なの？

なんでこの構成？ ・パイプライン：メンバーや環境間でコードとAWSリソースの整合性を常にとれる状態にできる。 ・CodeCommitを使う理由：コードをリソースと同じくAWS内で完結することができる（セキュア） ・クロスアカウント：検証と商用でリポジトリをわける必要がなくGit管理がしやすい

各環境へのデプロイ

検証環境へのデプロイ developブランチにマージすると検証環境のパイプラインが動作し、検証環境にリソースがデプロイされる

商用環境へのデプロイ（クロスアカウント） mainブランチにマージすると商用環境のパイプラインが動作し、商用環境にリソースがデプロイされる

クロスアカウント

クロスアカウント ・検証CodeCommit用ロールに商用CodePipelineロールからのAssumeRoleを許可 ・商用アーティファクトS3にKMSを設定し、検証CodeCommitからのPutを許可 （アーティファクトはterraformのarchive_fileのようなterraform planでファイルに変更が入る場合に使われる） ※コンソール上から不可の設定が多々あり。AWS CLIから設定して、それをTerraformに組み込む

承認フェーズ

承認フェーズ（IAMポリシー） ・developからmainへのマージはIAMポリシーの設定で管理グループしかマージできない ・商用のplan→apply間のCodePipeline/Approvalは管理グループしか承認できない

承認フェーズ CodePipeline 実際のパイプラインはこんな感じ。 Approvalフェーズまできたら 承認してあげればOK！

実際に運用して困ったこと

実際に運用して困ったこと × 改善が難しい デプロイは基本的にコードを経由する必要があるため、構築の瞬発力が落ちる IaCの特性上やむを得ない。どうしても急ぎなら手動とかで。 plan/applyでエラーが起こると構築が止まってしまう planはローカルで。applyまで検証したいなら別環境とかでやる。 手動変更やローカルから直applyされると、都度確認が必要になる テスト中はやむを得ない手動変更とかが起きる。 その間はパイプラインを止めておくなど、うまくスケジュールする。 共通リソースがあるので、商用だけ一部先行着手とかが難しい developとmainは共通化されるので共通リソースも中途半端に デプロイされてしまう。先行してやるなら手動やローカルから流す。 ※チーム構成 全体４名（ガッツリ書く人２名、そこそこ書く人２名、Lambda等は別部隊で記述） ◯ 改善が可能 terraformを使えるメンバーが少なかったので、applyの依頼が集中 少なくともインフラチームはみんな使えた方がいい。 記述方法が個人間で差がでる 事前に軽い規約は作ったが、まだまだ弱かった。 開発同様、より強い規約の制定が必要。

Thanks!! 実際に使ってみて、いろいろ問題点はありましたが、大規模構 築やるならパイプラインの存在はほぼ必須かなと思いました。 最初はわちゃわちゃしますが、慣れればそれなりに運用も安定 しました。後続環境のデプロイが一瞬なのもの爽快です。 ぜひ本パイプラインの構築を検討してみてください！ 本資料 https://speakerdeck.com/hiyanger/codesirizudezuo-ruterraf ormnocicdpaipurain https://twitter.com/hiyanger https://qiita.com/hiyanger https://speakerdeck.com/hiyanger https://zenn.dev/hiyanger