2024/11/14 クラスメソッド株式会社 菊池 聡規 Terraform未経験の御客様に対してどの ように導⼊を進めていったか

⾃⼰紹介 2 ● 2008年 オンプレエンジニア時代 ● 2019年 転職しAWSに初めて触る ● 2021年頃? Terraformとの出会い ● 2022年 クラスメソッド AWS事業本部にジョイン ○ AWSコンサルティング業務を担当 ■ しばらくCDKに浮気をする ● 2024年現在→ Terraformこそが⾄⾼！！ ● 部署 ○ AWS事業本部 ● 普段の業務 ○ AWSのコンサルティング等 ● 名前 ○ 菊池聡規 ● Xアカウント ○ https://x.com/tttkkk215 ● 好きな技術 ○ コンテナ、Terraform

本セッションのターゲットとゴール 3 ● 本セッションのターゲット ○ Terraformを使い始めたばかりの⽅ ○ Terraformを⾃分のチームに広めたい⽅ ● 本セッションのゴール ○ 以下のTerraform開発を進める上で決めておいたほうがいい要素について勘所がわ かるようになる ■ Terraform開発環境の整備 ■ TerraformのCI/CD環境の作り⽅ ■ リポジトリ構成やディレクトリ構成 ■ モブプロ等のナレッジ共有の⽅法

本⽇のアジェンダ 4 1. ハンズオンの実施 a. Terraformの基礎的なハンズオン b. TerraformのCI/CD c. ハンズオンを実施した中での失 敗談 2. モブプロの実施 a. モブプロを始める前に決めたこ と b. モブプロ会の流れ ● 話す内容 ○ Terraformのご⽀援をする中での経 験‧知⾒を実際に実施した内容に 沿って話します ● 背景 ○ 御客様はTerraform未経験の⽅がほ とんど ○ 利⽤するインフラパターンが決まっ てるのでIaC化で迅速に構築できる ようにしたいというのがモチベー ション

まず何からやったか？ 5

Terraformを⼿でデプロイするハンズオンから やってみた 6

Terraformの基礎的なハンズオン 7 ● ざっくりとした内容 ○ 以下のような内容を⼀緒に実施 ■ Terraformを端末にインストール ■ tfstateファイル格納のためのバックエンド(S3)作成 ■ 実際にEC2をデプロイする ■ 開発に役⽴つツールの実演 ○ 途中で座学も交える ■ tfstateファイルの役割についての説明 ■ Terraformコードの⼤まかな構成 ■ Terraformの代表的なコマンド(init, plan, apply等)について説明

Terraformの基礎的なハンズオン 8 ● こんなかんじのページを作った

Terraformの基礎的なハンズオン 9 ● 紹介したTerraform開発に役⽴つツール ○ tfenv ⇒ 最終的にはaquaを使って管理することに ○ TFLint ■ ⾔わずとしれたTerraformのリンターツール ○ Trivy ■ こちらも有名。Terraformコード以外にもコンテナイメージの脆弱性など様々な セキュリティの問題を検知できる ○ pre-commit ■ gitクライアント側でコミット前に⾃動で定義した処理を実⾏ ○ git-secrets ■ Gitコミット対象にAWS認証情報が含まれていないかチェック ○ VSCodeの 「HashiCorp Terraform」プラグイン

Terraformの基礎的なハンズオン 10 ● このハンズオンでのねらい ○ Terraformの基本的な使い⽅が分かる ⇒ Terraformでデプロイするのって思ったよ り簡単と感じてもらう ○ tfstateファイルは重要なものと理解してもらう ○ 開発ツールの便利さを実感してもらう ⇒ 初期からTFLintやTrivyを使うことで正し いコードやセキュリティを意識したコードを書けるようになってもらいたい

TerraformをGitHub Actionsでデプロイする ハンズオン 11

TerraformをGitHub Actionsでデプロイするハンズオン 12 ● 前回のハンズオンで⼿でデプロイしたTerraformを今度はGitHub Actionsからデプロイしてみよう というハンズオン ○ いきなりステップアップしすぎたかなと反省している ○ 内容としては ■ Terraformでのブランチ戦略の紹介 ■ GitHub Actionsワークフローファイルの基本的⽂法 ■ Terraformのplan, applyをする簡単なワークフローファイルの説明 ■ 実際にGitHub Actionsでデプロイされる様⼦を確認 ○ ねらいとしては、GitHub Actionsを使うことへの⼼理的ハードルを下げたかったと いうのがある

紹介したTerraformでのブランチ戦略について 13 ● トランクベースパターン ○ Terraformコードを環境ごとにディレクトリを分ける構成にしている場合はこれが⼀番良い気がす る ○ 本番以外へのデプロイはmainブランチへのマージ、本番デプロイはタグ付与トリガーで実施

紹介したTerraformでのブランチ戦略について 14 ● 環境ブランチパターン ○ 環境ごとにブランチを切っているのでどこの環境向けに変更しようとしてるのかが直感的 ○ 環境ごとにディレクトリを分ける構成の場合、ブランチ名と環境名のマッピングやブラン チに応じた環境の変更だけをするような仕組みが必要

他に実施したハンズオン 15 ● 他にも下記のようなハンズオンを実施しましたが割愛 ○ ecspressoを使ってECSをデプロイするハンズオン ○ CloudFront継続的デプロイとS3を使って静的サイトをデプロイするハンズオン

ハンズオンをやってみた中での失敗談 16

ハンズオン失敗談 17 失敗 改善点 ● モブプログラミングでは最初に共通の実行環境（EC2）を用意 ● モブプログラミング以降はaquaを使って必要なツールをインストール ○ ⇒次第に各メンバーの端末でもTerraform実行できる環境を用意して 頂けるように ● ハンズオンといいつつ結局自分が操作することが多かった ○ 各参加者が使えるTerraformの実行環境を用意できていなかったのが一つの 要因

aquaについて 18 aquaとは ● コマンドラインツールのバージョン管理をするもの ● Node.jsとかでいうところのnvm とにかく使いやすい ● インストール簡単 ● aqua i のコマンド⼀個で必要なコマンドがすべてイ ンストールされる ● パッケージを追加したいときは aqua g -i した後に ⼊れたいパッケージ名を⼊⼒するだけ ● Terraform以外の周辺ツールもこれで⼀括管理 ● macだけでなくWindowsもサポートしてるので今 回メンバー間の開発環境を揃えるのにとても役⽴っ た ※画像はaquaのGitHub公式リポジトリ より

ハンズオン失敗談 19 失敗 改善点 ● モブプログラミングにより参加者が手を動かすので双方向コミュニケー ションになった ○ 最初からモブプログラミング形式で良かったと感じている ● コミュニケーションツールの改善 ○ 御客様が使い慣れてるTeamsに参加させてもらった ○ モブプログラミングのときにスレッドを立てて質問しやすい状況に ● 参加者が質問がしやすくなったことで各回のあとで知識のフォローもでき るようになった ● 見るだけになってしまいあまり身につかない ○ コミュニケーションが一方的になると質問もしづらい空気になる ○ 質問できないと参加者がどれくらい分かってないかを伝えることもできない ○ 参加者が結構多かった（御客様側だけで10人くらい）のも質問しづらい要 因だったのかも

ハンズオン失敗談 20 失敗 改善点 ● モブプログラミング以降は各回で前提となる知識を事前に連携するように ● ハンズオンに臨むにあたっての事前知識をインプットできていなかった ○ 前提知識がない状態で参加しついていけないという負の連鎖

ハンズオン失敗談 21 ● こんなかんじの情報を連携 ○ ※下記の中で使⽤している画像は [AWS Black Belt Online Seminar] Elastic Load Balancing (ELB) より参照

ハンズオン失敗談 22 失敗 改善点 ● モブプログラミング以降は簡単に振り返りする時間を設けた ● 参加者それぞれにその回で良かった点と改善すべき点を一つずつ言っても らうスタイル ● 振り返りをしていなかった

モブプログラミングの実践 23

モブプログラミングを始める前に決めたこと 24

前提の説明 25 今回の作ったシステム構成は左記 ● ECSを使ったWebアプリケーション ● 前段ALB、DBはAuroraのスタンダードな構成 ● AWSアカウントは環境ごとに分ける ● バージョン管理にGitHubを使うことは決定済 み ● CI/CDオーケストレーションにGitHub Actions を使うことも決定済み 期間は３ヶ⽉ほどかけて実施 モブプロはVSCodeLiveShareを使ってリモートで 実施しました

モブプロを始める前に決めたこと 26 ● 今回のモブプロで実現したいゴールの認識合わせ ● モブプロ実施にあたっての⼼構えの共有 ● Terraformコードのブランチ戦略 ● Terraformコードのリポジトリ構成 ● Terraformコードのディレクトリ構成 ● （ECSの部分の）アプリケーションデプロイについて ○ デプロイ⽅式（B/Gかローリングアップデートか）、ロールバック⽅式 ○ ECSをデプロイするツール（ecspressoを選択） ● コーディング規約

今回のモブプロで実現したいゴールの認識合わせ 27 ● 今回のモブプロのゴールを最初に話し合った ○ プロジェクトの背景： ■ お客様⾃⾝でTerraformを活⽤し、インフラ環境を迅速に構築‧展開できる体制の確 ⽴したいという思いから今回の⽀援を弊社に依頼 ● 御客様側の体制 ○ テックリードの⽅はご⾃⾝でもある程度Terraformが出来るレベルだが、コンテナ +Terraform+CI/CDといったところの知⾒を補強したい ○ その他の⽅はTerraformに触ったことがないというレベル ● 上記を踏まえて今回ゴールとして設定したこと ○ テックリードの⽅以外のメンバーの技術⼒の底上げ（特にTerraformコーディングができる ようになるレベルに） ○ Terraformを使ったECSを中⼼としたAWSリソースのデプロイ ○ TerraformのCI/CDの完成

モブプロ実施にあたっての⼼構えの共有 28 ● モブプロ内でコミュニケーションが活発になるように以下のようなモ ブプロ会で意識してほしいことも共有した ● ⼼構えの共有 ○ ⾃分が何に悩んでどう考えているかを話す ⇒ 考え込む時間が減った ○ 判断の理由をしっかり⾔う ○ 動いたときはみんなで褒めましょう ○ 積極的に質問する ⇒ どこが理解できてないかを把握できるようになりアドバイスし やすくなった ○ わかってるひとは積極的になぜそのようにコーディングしたかを聞くようにする ■ 責める意図ではなく知⾒を全体に共有するため ○ ⼀番⼤事なのは楽しくやること

Terraformコードのブランチ戦略 29 今回は環境ブランチパターンに決定 ● トランクベースパターンは⼀つのブラ ンチに対して⻑くとも１⽇程度を⽬ 安にマージしていくというイメージ だったので、ある程度Terraformに慣 れたメンバーであることが前提と判 断したため ● とはいえ環境ブランチだとCI/CDの ワークフローが複雑化するのでトラ ンクベースでも良かったのではと感じ ている

Terraformコードのリポジトリ構成 30 ● Terraformコードのリポジトリ構成 ○ どの単位でリポジトリを作成するか、インフラとアプリでリポジトリを分けるかを検討 ○ 以下のような⽅針にした ■ 前提としてインフラとアプリのリポジトリは分ける ■ インフラ（Terraformコード） ● １つのサービスごとに１つのリポジトリを作成するイメージ ○ ここでの'サービス'は、1つのAWSアカウントで管理する全てのリソースを含 むくらいの粒度（⾃分の中ではMonorepoのイメージ） ● もちろん、開発環境や本番環境などの異なる環境は、1つのリポジトリ内で管理 ■ アプリ ● デプロイする単位で分ける（ECSでいうとサービスの単位）

Terraformコードのリポジトリ構成 31 ● 上記リポジトリ構成を採⽤した理由 ○ 前提としてインフラとアプリのリポジトリは分ける ■ インフラとアプリケーションではライフサイクルやCI/CDのフローが全く異なる のでリポジトリを分けたかった ● インフラとアプリの中間にあたるECSタスクなどの部分はecspressoを使う ことでアプリ側に寄せた ○ インフラ（Terraformコード）は１つのサービスごとに１つのリポジトリ ■ VPCのようなネットワークからその上で動くリソースに⾄るまでこのリポジト リを⾒ればOKといった視認性の良さを重視 ■ 全く関係のないサービスを同じCI/CDワークフローの中でデプロイすることは避 けたい

Terraformコードのディレクトリ構成 左記のような形にした ● 詳解 Terraform で紹介されていた ディレクトリ構成を参考にした ● 以下の理由からこれがベターだと 考えている ○ ⼀つのtfstateファイルで扱うリソース 数が増えるとplan,applyの実⾏時間に 影響を与える ○ ライフサイクルが異なるリソースは tfstateファイルを分けることでapplyの 影響を最⼩限にしたい 32 terraform/ ├── environments │ ├── prod（本番用のリソース） │ │ ├── data-store（主にRDSに必要となるリソース） │ │ ├── monitoring（主に監視で必要となるリソース） │ │ ├── network（主にVPC周りのリソース） │ │ └── services（ECSサービス（またはECSクラスタ）の単位でディレクトリを作成） │ │ ├── internal │ │ └── external │ └── staging（テスト環境用リソース） │ └── mgmt（management：踏み台サーバや開発端末用サーバ等） │ └── global（prod,staging間で共通して使うリソースがあればここにいれる） └── modules（各環境等で共通化できるものは以下に格納） ├── application-autoscaling ├── ecr └── ecs

コーディング規約 33 ● Hashicorpが公開しているコーディングスタイルガイドの中から今回 のコーディング範囲の中で使いそうな部分を抜粋 ○ 特にcountとfor_eachの使い分けについては、countの場合だと意図せぬリソース再 作成のリスクがあることを説明 ○ ただ、あまりメンバー間で意識づけができてない気がするので読み合わせの時間を 設けても良かったかも ● その他IAMについては様々な書き⽅があるのでルールをある程度統⼀ ○ （賛否ありそうですが）IAMポリシーにはなるべくインラインポリシーを使う ■ カスタマー管理ポリシーがTerraform外でアタッチされるリスクを避けたかった ○ IAMポリシーは可能な限りdata "aws_iam_policy_document" を使⽤ ■ VSCodeのTerraform拡張等とも相性が良いので

コーディング規約 34 ● リソース命名規則 ○ Google Cloudが出しているTerraform を使⽤するためのベスト プラクティスに倣っ た ■ リソースがそのモジュールやmain.tfの中で単⼀である場合、リソース名はmain にする ■ 単語の区切りにはアンダースコアを使⽤する ● などなど

実際にモブプロの中で実施したこと 35

モブプロの中で実施したこと 36 ● 各回の⼤まかな流れ ○ タスクの認識合わせ ○ ドライバーとナビゲータに分かれて作業 ■ ドライバーだけが画⾯上に⼊⼒を⾏う ■ ナビゲータは⼤まかなタスクを伝える（例えばEC2を作るといった粒度で） ● ⼿が動かないときはある程度細かく指⽰ ■ ドライバーはコーディングする前に何をやりたいか、どういうことをやろうと しているのかを必ず⾔ってからコーディングする ■ 定期的にドライバーを交代 ○ 簡単に振り返り ■ 各回で良かったこと、改善したほうがいいことをコメント

モブプロの中で実施したこと 37 ● 振り返りの中で出た意⾒‧改善点 ○ ドライバーは画⾯共有しながらやったほうがいい ■ 他メンバーが状況を理解しやすくなる ○ 指⽰を出すときはどのファイルの何⾏⽬か、明確に⾔ったほうが分かりやすくなる ○ ドライバーが知⾒がないようなAWSサービスはどんなリソースを作るかだけ先に書 いておくと進みやすい ● 御客様からのモブプロの感想 ○ ハンズオンよりモブプロのほうが楽しかった ○ モブプロに⼊ってからは頻繁にコミュニケーションをとることができた

「どんなリソースを作るか先に書いておく」のイメージ 38 # application autoscaling # ## application autoscaling target # resource "aws_appautoscaling_target" "main" { # } # # ターゲット追跡スケーリングポリシー（ CPU利用率） # resource "aws_appautoscaling_policy" "ecs_cpu_target" { # } # # ターゲット追跡スケーリングポリシー（ Memory利用率） # resource "aws_appautoscaling_policy" "ecs_memory_target" { # }

実際どういうTerraformコードを書いたの？ 39

GitHubに⼀部上げてます 40 https://github.com/ice1203/terraform-development-terminal

コードで苦労したポイント 41

GitHubActionsワークフローの書き⽅ planとapplyの実⾏単位で悩む ● 環境ごと、かつレイヤーごとに ディレクトリを分けている場合 にどのようにplan, applyをする べきか 42 terraform/ ├── environments │ ├── prod（本番用のリソース） │ │ ├── data-store（主にRDSに必要となるリソース） │ │ ├── monitoring（主に監視で必要となるリソース） │ │ ├── network（主にVPC周りのリソース） │ │ └── services（ECSサービス（またはECSクラスタ）の単位でディレクトリを作成） │ │ ├── internal │ │ └── external │ └── staging（テスト環境用リソース） │ └── mgmt（management：踏み台サーバや開発端末用サーバ等） │ └── global（prod,staging間で共通して使うリソースがあればここにいれる） └── modules（各環境等で共通化できるものは以下に格納） ├── application-autoscaling ├── ecr └── ecs

Plan/Applyの実⾏単位の悩み 43 ● plan ○ 変更ディレクトリのみplanを実施する ⇒ 潜在的な変更の把握が困難 ■ 潜在的な変更とは：data-storeのtfstateがnetworkのtfstateに依存しているとき、network のtfstateの変更によりdata-storeでも変更が発⽣する可能性があること ● apply ○ 変更ディレクトリのみapplyを実施する ⇒ 依存先tfstateでの変更漏れリスク ○ 全ディレクトリでapply ⇒ 変更漏れの⼼配はないがどうやって事前に潜在的な変更の内容を把 握する？

現実的な妥協案 44 ● 最終的には以下の形に落ち着いた ● plan ○ 変更ディレクトリのみplanを実施 ⇒ 潜在的な変更があったとしてその変更内容はapply後 でないと分からないので、全ディレクトリでplanをするのは無駄。であれば、変更ディレ クトリのみで良いという判断 ● apply ○ 検証環境 ■ 全ディレクトリでapply実施 ⇒ ここで潜在的な変更有無と影響範囲を確認 ■ apply結果はプルリクエストのコメントとして残る形（tfcmtで実装） ○ 本番環境 ■ 検証環境で確認した結果を考慮して影響範囲を確認し、メンテナンスとするシステム の範囲を決定 ■ 全ディレクトリでapply実施（※全ディレクトリのapplyにはterragruntを使⽤）

GitHub Actionsワークフローの処理イメージ 45 ※Github ActionsでTerraformの実践的なCI/CDを構築する を参考にさせて頂きました

まとめ 1. 効果的だった取り組み ○ ✅ 環境統⼀ i. aquaによるツール管理 ii. 共通開発環境(tflintやtrivy, pre-commit)の整備 ○ ✅ モブプロ 2. インフラCI/CD運⽤ ○ ✅ CI/CDワークフロー i. TerraformのCI/CDのベストな形は未だ⾒えない。。が、変更ディレクトリごとにplan、 applyは全ディレクトリでやるのはとりあえずベターだと思う 3. 今後に活かせること ○ チーム全員が気軽に質問できる雰囲気づくりにモブプロは最適 ○ 継続的な振り返りと改善はとても重要 4. 今後予定していること ○ HCP Terraformを使ってよりセキュアにガバナンスを効かせたCI/CD環境の検討 46

参考にさせて頂いたページ 47 ● 皆で楽しく成⻑するためのペアプロ‧モブプロのやり⽅(前編)(#15)｜ ⼩島優介 ● aqua とは｜aqua CLI Version Manager ⼊⾨ ● Terragruntを活⽤したTerraformの実践的なディレクトリ構成 #AWS ● Github ActionsでTerraformの実践的なCI/CDを構築する #AWS

宣伝: クラスメソッド主催 IaCウェビナー

No content