Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Terragruntで快適なIaCを!
Search
KOHEKOHE
January 19, 2025
Programming
0
50
Terragruntで快適なIaCを!
SRE Kaigi 2025のLTのために作成した資料
KOHEKOHE
January 19, 2025
Tweet
Share
More Decks by KOHEKOHE
See All by KOHEKOHE
LT_TerragruntでAWS環境を構築してみた_20250220
kohekohe
1
60
Replaced the app with Next.js, Golang and Auth0 20240619
kohekohe
0
120
LT_Amazon_ECSで複数環境のDockerイメージを頑張って共通化した話.pdf
kohekohe
0
24
Terraform user getting started with AWS CDK
kohekohe
0
180
Other Decks in Programming
See All in Programming
GPUを計算資源として使おう!
primenumber
1
190
Node-RED を(HTTP で)つなげる MCP サーバーを作ってみた
highu
0
120
Android 16KBページサイズ対応をはじめからていねいに
mine2424
0
200
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
870
テスト駆動Kaggle
isax1015
1
480
ISUCON研修おかわり会 講義スライド
arfes0e2b3c
1
460
Webの外へ飛び出せ NativePHPが切り拓くPHPの未来
takuyakatsusa
2
570
20250704_教育事業におけるアジャイルなデータ基盤構築
hanon52_
5
880
What's new in AppKit on macOS 26
1024jp
0
130
効率的な開発手段として VRTを活用する
ishkawa
0
150
オンコール⼊⾨〜ページャーが鳴る前に、あなたが備えられること〜 / Before The Pager Rings
yktakaha4
1
550
PostgreSQLのRow Level SecurityをPHPのORMで扱う Eloquent vs Doctrine #phpcon #track2
77web
2
550
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
336
57k
Code Review Best Practice
trishagee
69
19k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
Scaling GitHub
holman
460
140k
Writing Fast Ruby
sferik
628
62k
The Pragmatic Product Professional
lauravandoore
35
6.7k
Statistics for Hackers
jakevdp
799
220k
Testing 201, or: Great Expectations
jmmastey
43
7.6k
4 Signs Your Business is Dying
shpigford
184
22k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
How to Think Like a Performance Engineer
csswizardry
25
1.7k
Transcript
Terragruntで快適なIaCを! kohekohe 2025年1月26日 ENGINEER LIGHTNING TALK @Kohei-Sato-1221 @kohekohe1221
佐藤幸平(こへこへ) @Kohei-Sato-1221 @kohekohe1221 所属:e-dash株式会社 役割:SRE‧EM 出⾝:埼⽟県 趣味:旅⾏‧お酒 ⾃⼰紹介 ABOUT ME 2
会社について ABOUT e-dash 3 • 企業のCO2排出量可視化‧削減のSaaSを開発 • 三井物産出資のスタートアップ • 2022年設⽴‧本社は⾚坂⾒附付近 •
ソフトウェアエンジニア絶賛募集中です
• TerragruntというTerraformをラッパーしたツールを導⼊した感想を話 します。 • Terraformをある程度理解している前提で話します。 • AWSで環境を構築する想定で話します。 • ソースコードは弊社独⾃の運⽤で⽣まれたものなので、ベストプラク ティスかどうかは不明です。
LTの概要‧注意点 4
• Gruntwork社がメンテしているTerraformをラッパーしたツール。 • より簡単‧簡素にTerraformを使ったIaCを運⽤することができる。 • 基本的には.tfファイルを使ってインフラを記述することはTerraformと 同じ。 • Terraform運⽤時の難点を解消することができるかも。 Terragruntって何?
5
Terraformは強⼒なIaCツールですが、不便だと感じる点がいくつ か、、、 1. 複数環境の設定ファイルの管理が煩雑 2. Stateファイルの分割が⾯倒 3. Stateを格納するS3バケットを⼿動で作成しないといけない 4. terraform
initを適宜実⾏しないといけない Terragruntを使えば、これらの難点が解消するかも?! Terraformの難点 6
弊社ではWorkspaceは使わずに 環境ごとにディレクトリを切っ てTerraformを運⽤。 ⇩ 各環境ごとにmain.tfを⽤意しな いといけない。 Terraformの難点:複数環境の設定ファイルの管理が煩雑 7 ※Terraformでの構築例
モジュール毎にhclと呼ばれる設定ファ イルを⽤意 ⇩ 設定ファイル数は増えているが、「ほぼ コピペで済む&変更の頻度は少ない」 のでメンテナンスコストは下がる ※⼦hclは親hclを継承できる Terraformの難点:複数環境の設定ファイルの管理が煩雑 8 ※Terragruntでの構築例
locals { environment = "${replace(replace(replace(get_path_from_repo_root(), "environments/", ""), path_relative_to_include(), ""), "/",
"")}" variables = read_terragrunt_config(find_in_parent_folders("envs/env_${local.environment}.hcl")) module_name = basename(path_relative_to_include()) } remote_state { backend = "s3" generate = { path = "backend.tf" if_exists = "overwrite_terragrunt" } config = { region = "ap-northeast-1" bucket = "terragrunt-state-sugar-sample-${local.environment}" key = "${path_relative_to_include()}/terraform.tfstate" encrypt = true } } (右に続く...) Terraformの難点:複数環境の設定ファイルの管理が煩雑 9 (....左の続き) generate "provider" { path = "provider.tf" if_exists = "overwrite_terragrunt" contents = <<EOF terraform { required_version = "= 1.9.8" required_providers { aws = { source = "hashicorp/aws" version = "5.59.0" } } } EOF } inputs = { variables = local.variables.locals } develop環境⽤の親hclファイルの例
locals { environment = "${replace(replace(replace(get_path_from_repo_root(), "environments/", ""), path_relative_to_include(), ""), "/",
"")}" variables = read_terragrunt_config(find_in_parent_folders("envs/env_${local.environment}.hcl")) module_name = basename(path_relative_to_include()) } remote_state { backend = "s3" generate = { path = "backend.tf" if_exists = "overwrite_terragrunt" } config = { region = "ap-northeast-1" bucket = "terragrunt-state-sugar-sample-${local.environment}" key = "${path_relative_to_include()}/terraform.tfstate" encrypt = true } } (右に続く...) Terraformの難点:複数環境の設定ファイルの管理が煩雑 10 (....左の続き) generate "provider" { path = "provider.tf" if_exists = "overwrite_terragrunt" contents = <<EOF terraform { required_version = "= 1.9.8" required_providers { aws = { source = "hashicorp/aws" version = "5.59.0" } } } EOF } inputs = { variables = local.variables.locals } develop環境⽤の親hclファイルの例 環境名をディレクトリから引っ張ってくる パスからモジュール名を取得 環境変数を格納している hclファイルを指定 inputsが子に引き継がれる tfファイルを生成する
include { path = find_in_parent_folders() } terraform { source =
"../../../modules/${path_relative_to_include()}" } Terraformの難点:複数環境の設定ファイルの管理が煩雑 11 S3⽤の⼦hclファイルの例 • inputsが親から引き継がれるので、⼦hcl⽤にわざわざ記述 しなくてよい • これを各モジュールの配下にコピペしていく
Terraformの難点:Stateファイルの分割が⾯倒 12 • プロジェクトが⼤きくなってくるとterraform plan(apply)の実⾏時間 は⻑くなるため、適宜Stateの分割を検討するとよい。 • しかし、terraformではStateの分割は結構めんどくさい。 • Terragruntでは、既述のディレクトリ構成を採⽤するだけで
モジュー ル毎にStateファイルを勝⼿に分割してくれる。
• TerraformではStateを格納するS3バケットは⼿動で作成することが推 奨されている。 • Terragruntではterragrunt apply(terraform apply的なコマンド)を実 ⾏する際に⾃動でS3バケットを作成してくれる。 Terraformの難点:Stateを格納するS3バケットを⼿動で作成しないといけない 13
Terraformの難点:terraform initを適宜実⾏しないといけない 14 • Terraformではモジュールの新規追加を⾏なった場合は、terraform initを都度実⾏しないといけない。 • Terragruntでは、applyやplanを実⾏する際に裏側でプラグインのダ ウンロードやバックエンドの初期化が⾃動で⾏われる。
Zennで記事を書いたのでより詳しく知りたい⽅はよければアクセスください。 ⼿を動かしてメリットを実感するTerragrunt⼊⾨1~3 https://zenn.dev/edash_tech_blog/articles/2e2482fd27647c https://zenn.dev/edash_tech_blog/articles/ebc1db4195a31d https://zenn.dev/edash_tech_blog/articles/085fe5381b99e2 「e-dash Terragrunt」でググればヒットすると思います。」 最後に 15 e-dash
Terragrunt 検索
THANK YOU! ENGINEER LIGHTNING TALK kohekohe @Kohei-Sato-1221 @kohekohe1221