概要

Terraform は、いわゆる Infrastructure as Code のためのツールですが、似たようなツールが色々ある中で、なぜ Terraform を使う必要があるのか分からない人もいると思います。本記事では、

• Terraform 自体の説明
• なぜ Terraform が必要か
• Terraform を使ったインフラ構築の方法
• 他のツールとの使い分け

について説明していきます。

Terraform とは

概要

Terraform とは、前述の通り Infrastructure as Code （以下 IaC）のためのツールで、Vagrant などで有名な HashiCorp によって開発されています。

Terraform では、AWS, Azure, GCP のようなクラウドプラットフォームや、OpenStack などを使ったインフラを管理する事が出来ます。

Terraform を使うと、インフラの設定内容がコード化されるため、

• バージョン管理ツールなどで過去の修正が把握できる
• インフラ構築作業が簡単に再現可能

といった、IaC の利点は当然享受できます。（IaC 自体の話はここでは深入りしません。）

また、以下のような Terraform 特有の利点もいくつか挙げられます。

• 各リソースの依存関係を内部で管理している
• インフラの現在の状態を保持している
• 主要なクラウドプラットフォームに対応

次項から、Terraform 特有の利点について見ていきます。

各リソースの依存関係を内部で管理

それなりの規模のインフラを管理していると、多数の構成要素を触る必要が出てきます。例えば、AWS で複数台のサーバーを運用しているだけのシンプルな場合ですら、

• VPC
  • subnet
  • ルーティング
• EC2
  • インスタンス
  • IP アドレス
  • セキュリティグループ

といったものが出てきます。

構成要素が多い場合、それらのどれか1つの設定変更をした時に、他のどの部分に影響を及ぼすかを把握するのは困難になってきます。

Terraform では、各リソースの依存関係を把握しているため、あるリソースの設定を変更したときに、どこにどういう影響を及ぼすのか（再起動が必要となる、リソースの再作成が必要となる、等）というのが、事前に把握できます。

インフラの現在の状態を保持している

Terraform では、インフラの現在の状態を保持しています。

他のツールですと、設定ファイルの内容が現在のインフラに適用されているのか分からないという事もありますが、Terraform では、”State” をファイルとして保持しています。そして、インフラに何らかの変更を加える際などは、現在の State と比較して、必要な変更のみを加えるような動作をします。

State に関しての詳細は、以下のページを参照して下さい。

State – Terraform by HashiCorp

主要なクラウドプラットフォームに対応

Terraform では、AWS, Azure, GCP といった主要なクラウドプラットフォームに対応しています。それだけでしたら他のツールも同様だと思いますが、Terraform では、インフラの実体が何であろうと、割と同じような設定で書けますので、ベンダーの移行や複数ベンダーをまたぐインフラの構築なども比較的やりやすいと思います。

なぜ Terraform が必要か

世の中には似たような（あるいは似ているように見える）ツールが沢山ありますが、それらでは無くて Terraform を使う必要はなぜでしょうか。Terraform の以下のドキュメントにも記載がありますので、それを元に書いてみます。

Terraform vs. Other Software – Terraform by HashiCorp

Chef, Puppet etc.

Chef, Puppet などは構成管理ツールです。あるマシンに対してソフトウェアをインストールしたり設定を変更するのに適しています。

個人的には Chef は無駄に複雑だと思うので使うのを止めてしまいましたし、実際に最近は Chef の人気も下火のように思えます。Puppet は使った事がありません。

Ansible は、web サイトに 「App deployment, configuration management and orchestration – all from one system」と書いてありますが、構成管理ツールとして使われる事が一番多いと思いますので、Chef, Puppet と同じカテゴリーに入れて良いと思います。

CloudFormation, Heat etc.

CloudFormation や Heat は、出来る事は Terraform と似ています。最大の違いとしては、CloudFormatino は AWS のみ、Heat は OpenStack のみに対応しているのに対し、Terraform では複数のクラウドプラットフォームに対応しています。

CloudFormation は少し使った事があるのですが、機能は十分ですが、覚えるのが大変という印象があります。また、AWS でしか使えないのは大きなマイナスです。

それに対して、Terraform は比較的シンプルかつ、AWS 以外にも対応していますので、覚えるのであれば Terraform の方が良いでしょう。

Terraform を使ったインフラ構築の方法

基本的な流れ

ここからが本題です。インストール自体は済んでいる前提です。

Terraform の使い方は、以下のページとその後続のページである程度概要が載っています。

Build Infrastructure – Terraform by HashiCorp

基本的な流れとしては以下の通りです。

• *.tf というファイルを作成する
• terraform init でいろいろ初期化
• terraform apply で設定内容をインフラに反映
• *.tf を修正したら、都度 terraform apply を実行

State 及び Remote State

terraform apply をした時点で、terraform.tfstate というファイルが作成されたと思いますが、これが State を保持するファイルです。大事なファイルなので消さないようにしましょう。

さて、1人のプロジェクトとかであれば、このファイルをローカルに保存しておけば良いと思いますが、複数人がインフラに関わる環境（通常はそうだと思います）であれば、Remote State という仕組みを使って、このファイルを S3 などに置いて共有する事をお勧めします。
また、Stateは認証情報なども含まれているので、一人で運用する場合でもgit管理はしないようにしましょう。

Remote State の使い方は以下のページに記載があるのですが、これだけだと分かりにくいと思います。（実際に、私もこれだけだとよく分かりませんでした。）

State: Remote Storage – Terraform by HashiCorp

ということで、設定方法を簡単に説明します。

まずは、以下のファイルを拡張し .tf の任意のファイル名で保存します。例えば s3-backend.tf などです。

terraform {
  backend "s3" {
    bucket  = "a-bucket-for-provisioning"
    key     = "terraform.tfstate"
    region  = "ap-northeast-1"
  }
}

その上で、terraform init コマンドを実行します。これで、*.tfstate ファイルが S3 上に保存されます。

Workspace

Terraform には、”workspace” という概念があります。典型的な使い方としては、development, staging, production といった Workspace を用意して、それを切り替えて使うというものです。

これは、内部的には state ファイルなどを workspace 毎のディレクトリに格納するという形になっています。

workspace を使うには、次のようなコマンドを使います

# foo という名前の workspace を作成し、そちらに切り替え
terraform workspace new foo
# bar という名前の workspace を作成し、そちらに切り替え
terraform workspace new bar
# foo という名前の workspace に切り替え
terraform workspace select foo

設定ファイルの中では workspace 名を使用する事が出来るため、インスタンスの名前に workspace 名を入れたり出来ます。以下の設定例は、公式サイトからの引用です。

resource "aws_instance" "example" {
  tags {
    Name = "web - ${terraform.workspace}"
  }

  # ... other arguments
}

ここまでで、Terraform を使ったインフラ構築の基本的なタスクは網羅できたと思います。

他のツールとの使い分け

上の方で他のツールとの違いについて記述しましたが、ここでは他のツールとの使い分けについて書きます。

個人的な使い分けとしては以下の通りです。以下、AWS の例ですが、他のクラウドベンダーの場合も似たような感じになるかと思います。

• AWS のインフラ定義（EC2, ELB, VPC, RDS, etc）は、Terraform メインで
• EC2 へのソフトのインストールとかは Ansible
• Lambda や、Lambda が使用するリソースの定義は Serverless

本当であれば、AWS のインフラ定義は全て Terrform を使いたいのですが、Terraform で Lambda 関数を定義するのは結構面倒だったので、Lambda の場合は、以前紹介した Serverless を使うのが良いと思います。

また、EC2 を使うケースは段々減ってきているので、多分近いうちに Ansible は要らなくなって、コンテナ周りで Kubernetes を使う事になるかと思います。

昨年の終わり頃に流れてきた以下のスライドが色々と良い内容が書いてありました。

運用自動化、不都合な真実 /20171212-automation // Speaker Deck

ここに書いてあったのですが、自動化関連のツールの流行り廃りは早いので、1つのツールで全てやろうとするのはあまり良い考えでは無いと思います。従って、Terraform が苦手な部分は、他のツールを併用するのが良いと思います。

まとめ

IaC のツールは色々ありますが、Terraform は、主要なクラウドプラットフォームに対応したインフラの構成管理ツールで、インフラ自体の定義・構築に適しています。

ただ、Terraform だけで出来ない部分もあるので、その辺りは他のツールと併用するのが良いと思います。