手を動かしてメリットを実感するTerragrunt入門1 ~Terragruntを使うべき4つの理由~
はじめに
こんにちは!e-dashのSREグループ所属のkohekoheです。
今回はe-dashのインフラ管理のツールとして新規導入したTerragruntというツールに関して紹介したいと思います。
Terragrunt入門の記事として3本の記事を投稿します。次の構成で紹介したいと思います。
1.Terragruntの概要とどういったメリットがあるのかを解説します【★本記事】
2.Terragruntを使ったハンズオン①(導入〜単一モジュールのプロビジョニング)
3.Terragruntを使ったハンズオン②(複数モジュールのプロビジョニング)
こちらはe-dash advent calendar 2024の2日目の記事です。
注意点
-
Terragrunt
に関して知らない・詳しくない人が対象読者です -
Terraform
の知識は一定ある前提で話を進めます - 本記事ではAWSを用いて解説します
Terragruntとは?
Terragruntは Gruntwork社がメンテナンスしているTerraformをラッパーしたツールになっています。Terraformが提供する機能を拡張し、より簡単に・より簡素にTerraformを使ったIaCを運用することができます。
Terragrunt専用の設定ファイルも存在はしますが、基本的には.tf
ファイルを使ってインフラを記述することはTerraformと同じなので、既にterraformを使ってインフラを構築している方は、Terragruntの採用も検討してみるとよいかもしれません。
メリットは様々ですが次節で記述するTerraformの難点を解消することができます。
Terraformの難点
Terraformはインフラ構築のためのIaCツールとして非常に便利です。弊社(e-dash)はAWSをインフラに採用していますが、全環境Terraformを用いてAWS環境を構築しています。Terraformは非常に便利ですが、長く運用していると気になる点も出てきます。
- 複数環境の設定ファイルの管理が煩雑
- Stateファイルの分割が面倒
- Stateを格納するS3バケットを手動で作成しないといけない
-
terraform init
を適宜実行しないといけない
ぶっちゃけ3,4は大したことはないのですが、1,2は結構深刻な問題です。ただ、1~4を全て解決する方法があるんです。できるんです。Terragruntを使えば、ね。
Terragruntを使うべき理由1:複数環境の設定ファイルの管理を簡便化
どの現場でも複数環境(開発環境・検証用環境・本番環境)を用意するが当然だとは思います。いろんなやり方があるとは思いますが、弊社ではWorkspaceなどは使わずに環境毎にディレクトリを用意して管理しています。以下弊社でのTerraformを用いた構築例です。
environments/
develop/
main.tf //prodivderやbackendを指定。各モジュールを呼び出し。
terraform.tfvars // 機微な情報(DBの情報等)
staging/
(developと同じ)
production/
(developと同じ)
modules/ //各モジュールを格納するディレクトリ。
ec2/
xxx.tf
rds/
xxx.tf
vpc/
xxx.tf
:
main.tf
を環境毎に用意しなければならないです。これが地味に面倒なのです。ただ用意するだけならよいのですが、main.tf
から各モジュールを呼び出している関係上、新規のモジュールが追加になる度に各環境のmain.tf
を修正する手間が発生します。
弊社ではこれをTerragruntを使って以下のように置き換えました。
environments/
develop/
ec2/
terragrunt.hcl //ec2モジュールの設定ファイル(※子)
rds/
terragrunt.hcl //rdsモジュールの設定ファイル(※子)
vpc/
terragrunt.hcl //vpcモジュールの設定ファイル(※子)
terragrunt.hcl //develop環境用の設定ファイル(※親)
staging/
(developと同じ)
production/
(developと同じ)
modules/ //各モジュールを格納するディレクトリ
ec2/
xxx.tf
rds/
xxx.tf
vpc/
xxx.tf
envs/
develop_envs.hcl
staging_envs.hcl
production_envs.hcl
「えっ?! 設定ファイルとかディレクトリ増えてない!?」... とツッコミたくなるかもしれませんが、「ほぼコピペで済む&変更の頻度は少ない」 のでメンテナンスコストは下がるかなと思います。
具体的な書き方は後述しますが、Terragruntでは親の設定ファイル(hcl)を子供が継承できるので個別の設定ファイルの記述量はそれほど多くありません。
Terragruntを使うべき理由2:Stateファイルの分割を簡便化
プロジェクトが大きくなってくるとterraform plan(apply)
の実行時間は長くなります。これはTerraformがState内の全てのリソースをチェックする仕様だからです。ですので、大きなプロジェクトではStateファイル自体を分割して、terraform
コマンドの実行時間の短縮を行う場合があります。
ただ、これが 結構めんどくさい のです!
具体的なやり方は本記事では紹介しませんが、別のStateに情報を提供する場合、output
として出力を行い、利用側ではterraform_remote_stateを用いる必要があります。
Terragruntでは、前項で紹介したディレクトリ構成を採用するだけで モジュール毎にStateファイルを勝手に分割 してくれます。他のモジュールの情報を参照するには、専用の記述が必要といえば必要なのですが、terraformでState分割するよりはかなり簡便な印象です。
Terragruntを使うべき理由3:Stateを格納するS3バケットを手動で作成しなくてよい
terraformではStateを格納するS3バケットは手動で作成することが推奨されています。Terragruntではterragrunt apply
(terraform apply的なコマンド)を実行する際に自動でS3バケットを作成してくれます。
Terragruntを使うべき理由4:terraform initを実行しなくてよい
Terraformではモジュールの新規追加を行なった場合は、terraform init
を都度実行しないといけないですが、Terragruntではそれが不要になります。Terragruntでは、applyやplanを実行する際に裏側でプラグインのダウンロードやバックエンドの初期化が自動で行われるのです。そうです。Terragruntは空気を読んでいい感じにやってくれるいいやつなんです。
おわりに
本記事ではTerragruntを採用するメリットについて解説しました。後述のTerragrunt入門2では、実際にTerragruntを使ったインフラ構築の方法をハンズオン形式で解説していきます!
Discussion