$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Terraform未経験の御様に対してどの ように導⼊を進めていったか
Search
t-kikuchi
November 13, 2024
Technology
2
490
Terraform未経験の御様に対してどの ように導⼊を進めていったか
Terraform未経験の御様に対してどのように導⼊を進めていったか
t-kikuchi
November 13, 2024
Tweet
Share
More Decks by t-kikuchi
See All by t-kikuchi
塩野義製薬様のAWS統合管理戦略:Organizations設計と運用の具体例
tkikuchi
0
450
JAWSPANKRATION2024-ECS Best Practice All on board(english)
tkikuchi
0
600
JAWSPANKRATION2024-ECS Best Practice All on board(japanese)
tkikuchi
0
390
AWSOrganizationsユースケースで学ぶAWSアカウント管理ベストプラクティス
tkikuchi
1
560
AWS Organizationsありなしパターン別AWSのマルチアカウント管理Tips
tkikuchi
1
410
GuardDutyとSysdigのランタイムセキュリティ機能を比較してみる
tkikuchi
1
1.5k
AWS Healthの通知の実装について考えてみた
tkikuchi
0
1.9k
developersio-2023-aws-api-publication-checklist
tkikuchi
11
9.2k
「クラスメソッドメンバーズ」で AWSをよりお得に! 活用のコツをまとめてみた
tkikuchi
0
1.9k
Other Decks in Technology
See All in Technology
12/2(月)のBedrockアプデ速報(re:Invent 2024 Daily re:Cap #1 with AWS Heroes)
minorun365
PRO
2
290
店舗向けSaaSにおける 顧客要望活用の実践アプローチ(20241205_pmconf)
yujirooo
0
1.1k
深層学習のリペア技術の最新動向と実際 / DNN Repair Techniques for AI Performance Alignment for Safety Requirements
ishikawafyu
0
210
総会員数1,500万人のレストランWeb予約サービスにおけるRustの活用
kymmt90
3
2.8k
GeminiとUnityで実現するインタラクティブアート
hokkey621
0
410
Autonomous Database サービス・アップデート (FY25)
oracle4engineer
PRO
0
210
Amazon CloudFrontを活用したゼロダウンタイム実現する安定的なデプロイメント / 20241129 Yoshiki Shinagawa
shift_evolve
0
130
今はまだ小さい東京ガス内製開発チームが、これからもKubernetesと共に歩み続けるために
yussugi
3
550
Kubernetesを知る
logica0419
17
4.5k
Engineer Recruting Deck
siva_official
PRO
1
3.3k
大規模トラフィックを支える ゲームバックエンドの課題と構成の変遷 ~安定したゲーム体験を実現するために~
colopl
0
1k
品質管理チームのEMとして大事にしていること / QA EM
nihonbuson
0
370
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
16
2.2k
The Cult of Friendly URLs
andyhume
78
6.1k
How GitHub (no longer) Works
holman
310
140k
Documentation Writing (for coders)
carmenintech
65
4.5k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Music & Morning Musume
bryan
46
6.2k
Thoughts on Productivity
jonyablonski
67
4.3k
A designer walks into a library…
pauljervisheath
204
24k
GitHub's CSS Performance
jonrohan
1030
460k
YesSQL, Process and Tooling at Scale
rocio
169
14k
Navigating Team Friction
lara
183
15k
Adopting Sorbet at Scale
ufuk
73
9.1k
Transcript
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 を使うことも決定済み 期間は3ヶ⽉ほどかけて実施 モブプロは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 今回は環境ブランチパターンに決定 • トランクベースパターンは⼀つのブラ ンチに対して⻑くとも1⽇程度を⽬ 安にマージしていくというイメージ だったので、ある程度Terraformに慣 れたメンバーであることが前提と判 断したため
• とはいえ環境ブランチだとCI/CDの ワークフローが複雑化するのでトラ ンクベースでも良かったのではと感じ ている
Terraformコードのリポジトリ構成 30 • Terraformコードのリポジトリ構成 ◦ どの単位でリポジトリを作成するか、インフラとアプリでリポジトリを分けるかを検討 ◦ 以下のような⽅針にした ▪ 前提としてインフラとアプリのリポジトリは分ける
▪ インフラ(Terraformコード) • 1つのサービスごとに1つのリポジトリを作成するイメージ ◦ ここでの'サービス'は、1つのAWSアカウントで管理する全てのリソースを含 むくらいの粒度(⾃分の中ではMonorepoのイメージ) • もちろん、開発環境や本番環境などの異なる環境は、1つのリポジトリ内で管理 ▪ アプリ • デプロイする単位で分ける(ECSでいうとサービスの単位)
Terraformコードのリポジトリ構成 31 • 上記リポジトリ構成を採⽤した理由 ◦ 前提としてインフラとアプリのリポジトリは分ける ▪ インフラとアプリケーションではライフサイクルやCI/CDのフローが全く異なる のでリポジトリを分けたかった •
インフラとアプリの中間にあたるECSタスクなどの部分はecspressoを使う ことでアプリ側に寄せた ◦ インフラ(Terraformコード)は1つのサービスごとに1つのリポジトリ ▪ 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ウェビナー
None