はじめに
IaC (Infrastructure as Code) に興味がある人は、おそらくTerraformについて聞いたことがあるかと思います。様々なクラウドプロバイダーのインフラをコードで宣言的に管理できる優れたツールです。Terraform単体でも強力な機能を多数持っているのですが、今回はそのTerraformにさらに＋αな機能を加えたTerragruntについて触れていきたいと思います。
TerragruntはDevOps as a Serviceを提供しているGruntwork社が公開しているTerraformのラッパーツールです。「Terraformにこんな機能があったらいいのになー」というものが実装されている感じです。
共通化の全く無いTerraform
まずは共通化が全くされていないプレーンなTerraformを見てみましょう。
ディレクトリ構成は以下のような状態です。
[bash]
└── live
├── production
│ └── app
│ ├── main.tf
│ └── terraform.tfvars
└── staging
└── app
├── main.tf
└── terraform.tfvars
[/bash]
main.tfの中身は全く同じで↓のようになっています。
[bash]
variable “instance_count” {
description = “How many servers to run”
}
variable “instance_type” {
description = “What kind of servers to run (e.g. t2.large)”
}
provider “aws” {
region = “ap-northeast-1”
}
resource “aws_instance” “web” {
ami = “ami-afb09dc8”
instance_type = “${var.instance_type}”
count = “${var.instance_count}”
}
[/bash]
stagingでは、環境のレベルを下げ気味でtfvarsにて↓のように定義し
[bash]
instance_count = 3
instance_type = “t2.micro”
[/bash]
productionではあるべき姿に設定しています↓
[bash]
instance_count = 10
instance_type = “m2.large”
[/bash]
とりあえずはこの定義でstagingとproductionのインフラを作ることができます。
moduleを使ったDRYなアプローチ
さて、上の例は全くもってDRY（Don’t Repeat Yourself）ではないので、ここでTerraformに標準機能として備わっているmoduleを使って共通化を試みたいと思います。
まずは共通部分を切り出してGithubに置きます。こうすることで、この共通部分を呼び出したいTerraformのファイルはmoduleとして呼び出せるようになります。
moduleはhttps://github.com/capsulecloud/tf_ec2_sampleに置いてあるものとして、構成としては以下のとおり。
[bash]
└── app
├── main.tf
└── variables.tf
[/bash]
それぞれのファイルの中身は以下のように分解されています。
[bash]
# variables.tf
variable “instance_count” {
description = “How many servers to run”
}
variable “instance_type” {
description = “What kind of servers to run (e.g. t2.large)”
}
# main.tf
resource “aws_instance” “web” {
ami = “ami-afb09dc8”
instance_type = “${var.instance_type}”
count = “${var.instance_count}”
}
[/bash]
このようなmoduleが存在している場合、まずディレクトリ構成は以下のようになります。
[bash]
└── live
├── production
│ └── app
│ └── main.tf
└── staging
└── app
└── main.tf
[/bash]
そして呼び元からは以下のように呼び出すことができます。
[bash]
# staging
provider “aws” {
region = “ap-northeast-1”
}
module “ec2” {
source = “git::https://github.com/capsulecloud/tf_ec2_sample//app”
instance_type = “t2.micro”
instance_count = “3”
}
# production
provider “aws” {
region = “ap-northeast-1”
}
module “ec2” {
source = “git::https://github.com/capsulecloud/tf_ec2_sample//app”
instance_type = “m2.large”
instance_count = “10”
}
[/bash]
単にこれはec2のmoduleなのでほとんど恩恵がみられません。しかし、これが大きなmoduleになった場合、この共通化はなかなかな威力を発揮し始めます。
ただ、小さなモジュールだから余計に感じてしまうのですが、providerも冗長ですし、moduleのインプットをハードコードしてるのも微妙です（tfvarsにしていいのですが、それも冗長な感じがしてしまう）。stagingとproductionでとにかく変えたいのはinstance_typeとinstance_countだけなのです！それ以外には興味が無いのに、毎回書いてしまっています。
TerragruntによるDRYなアプローチ
上の課題をさらに解決してくれるのがTerragruntです。Terragruntの場合、moduleを作るというより丸っと今までのTerraformのファイルを再利用してしまうイメージです。なので↓のようにproviderブロックもそのまま入れてしまいます。
[bash]
# variables.tf
variable “instance_count” {
description = “How many servers to run”
}
variable “instance_type” {
description = “What kind of servers to run (e.g. t2.large)”
}
# main.tf
provider “aws” {
region = “ap-northeast-1”
}
resource “aws_instance” “web” {
ami = “ami-afb09dc8”
instance_type = “${var.instance_type}”
count = “${var.instance_count}”
}
[/bash]
そして、このTerraformを参照する側のディレクトリ構成は↓のようになります。
注目したいのはterraform.tfvarsだけになっている点です。
[bash]
└── live
├── production
│ └── app
│ └── terraform.tfvars
└── staging
└── app
└── terraform.tfvars
[/bash]
中身は↓のようになっています。Terragrunt独自のterragruntブロックがあることに注目してください。ここに共通利用したいTerraformファイルを参照させることができます。そして標準のterraform.tfvars同様、変数の値も指定できるんです。これで極限までDRYにもっていけることがわかったと思います。
少々シンプルすぎる例だったので恩恵が伝わりにくい部分もあるかと思いますが、これは確かにqa, staging, productionと分けたい場合には便利だと思います。
[bash]
# staging
terragrunt = {
terraform {
source = “git::https://github.com/capsulecloud/tf_ec2_sample//app”
}
}
instance_count = 3
instance_type = “t2.micro”
# production
terragrunt = {
terraform {
source = “git::https://github.com/capsulecloud/tf_ec2_sample//app”
}
}
instance_count = 10
instance_type = “m2.large”
[/bash]
おわりに
今回はTerraformのコードをDRYにする方法をTerragruntでご紹介しました。Terragruntにはまだまだ強力な機能がありますが、他の機能に関してはまた違う機会にでも紹介していきたいと思います。
