MENU
  • ホーム
  • AWSマネージドサービス
    • AWS運用サポート
    • AWSコンサルティング
    • コンテナ導入支援『仁』
  • AWS導入支援
  • WordPress
    • WordPress脆弱性対策
    • WordPress高速化
    • 高速WordPressサーバ『翔』
  • 導入事例
  • Q&A
  • お問い合わせ
AWSの構築・クラウド運用を総合支援【CapsuleCloud】
  • ホーム
  • AWSマネージドサービス
    • AWS運用サポート
    • AWSコンサルティング
    • コンテナ導入支援『仁』
  • AWS導入支援
  • WordPress
    • WordPress脆弱性対策
    • WordPress高速化
    • 高速WordPressサーバ『翔』
  • 導入事例
  • Q&A
  • お問い合わせ
AWSの構築・クラウド運用を総合支援【CapsuleCloud】
  • ホーム
  • AWSマネージドサービス
    • AWS運用サポート
    • AWSコンサルティング
    • コンテナ導入支援『仁』
  • AWS導入支援
  • WordPress
    • WordPress脆弱性対策
    • WordPress高速化
    • 高速WordPressサーバ『翔』
  • 導入事例
  • Q&A
  • お問い合わせ
  1. ホーム
  2. Terraform
  3. TerragruntでDRYなTerraform

TerragruntでDRYなTerraform

2022 7/26
Terraform
2022年7月26日
目次

はじめに

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にはまだまだ強力な機能がありますが、他の機能に関してはまた違う機会にでも紹介していきたいと思います。

Terraform
infrastructure-as-code Terraform terragrunt

関連記事

  • terraform
    Terraformと変数(variable)のお話
  • terraform
    TerragruntでDRYなTerraform Remote State
人気記事
  • AWS導入支援
    amazonクラウド、AWSとは?何ができるかデメリット含めわかりやすく説明
  • aws-s3
    Amazon S3で署名付きURLを使ったアクセス制御
  • terraform
    Terraformと変数(variable)のお話
新着記事
  • 10分でスタート!AWSの利用開始までを解説
  • WordPress脆弱性の原因とやっておくべき7つの対策
  • WordPress高速化!6つの簡単な方法で重さを改善
  • 高速WordPressサーバ『翔』
  • 【実例20選】AWS導入企業、活用事例をご紹介
カテゴリー
  • AWS
  • AWS導入支援
  • Rancher
  • Terraform
  • WordPress
アーカイブ
  • 2022年7月
  • 2022年6月
  • 2022年5月
  • 2022年4月
  • 2017年7月
  • 2017年6月
開発案件多数! フリーランス・エンジニアの求人はテックブレイン

スーパーソフトウエアはAWSパートナーネットワーク(APN)のコンサルティングパートナーです。

スーパーソフトウエアはRancherパートナーネットワークのコンサルティングパートナーです。

logo

カプセルクラウドはAWSクラウドのマネージドサービスです。AWSを安心かつ迅速に導入し、負荷分散・セキュリティ・DevOps・コスト削減など、クラウドサービスのメリットを活かした豊富なベストプラクティスをご提供いたします。

Contents

  • サービス
  • 導入支援
  • WordPress
  • 導入事例
  • ブログ
  • Q&A
  • お問い合せ

お問い合わせ

株式会社スーパーソフトウエア
東京 03-6721-7105
大阪 06-4707-6001
info-capsulecloud@tokyo.supersoftware.co.jp

  • プライバシーポリシー
  • 免責事項
  • 契約約款
  • 特商法に基づく表記
  • 会社情報
  • サイトマップ

© Supersoftware 2017. All rights reserved.

目次