Terraform で構築前に知っておいた方が良いと思われる機能の紹介
HashiCorpの Terraform を利用して、よくインフラ層の管理を行っています。 理由としては、いくつか考えられるます。
- 様々な IaaS に対応しているので、Terraform での書き方が分かっていれば、学習コストなどを抑えて新しい IaaS の導入ができる
- HCL (HashiCorp Configuration Language) は、人が読みやすい設定ファイルで初めての人が読んでもなんとなく理解ができるので、複数人で管理するDevOpsの場面に向いている
- Terraform Module Registry で他人が書いたソースを導入することができコストを抑えると同時に、学習することができる
などなど、様々なことがあります。(同時にデメリットの部分ももちろんあります。)
そこで、これから Terraform を導入しようとする人向けに知っておくと良いのではないかと私個人が考えている機能をユースケース別に紹介したいと思います。 (基本的には、ドキュメントを読めば書いてあることですが。。。)
似たような環境でちょっとだけ差異がある環境を作りたいのだけど…
State: Workspaces - Terraform by HashiCorp
Workspaces という機能を利用することで、だいたいの需要は満たせると思います。
必要な環境があれば、 terraform workspace new
コマンドを利用して作成することができますし、定義ファイル内では、${terraform.workspace}
という変数が使えるようになりますので、この変数をうまく使って環境毎の差異を吸収するようにすると良いかと思います。
ただ、Workspaces ではある処理をスキップする書き方がスマートにまだ書けないという問題があります。無理やりやろうとすると、Meta-parameters
の count
を使って、ある workspace
の場合だけ、 countを0にするという方法で実現できると思います。
同じプロバイダー(GCP, AWS, etc.)だけど、別の設定のものを使いたいのだけど…
Configuring Providers - Terraform by HashiCorp
Terraform は複数のプロバイダーに対応しており、alias
というフィールドを Provider
に定義することによって、同じプロバイダーも利用することが可能になります。
GCPなどを利用している際は、環境毎にプロジェクトを分けて対応することが多いですが、DNSなどはプロジェクト横断的に利用することも多く、この機能は重宝しそうです。
複数人で実行したいのだけど…
State: Remote Storage - Terraform by HashiCorp
Terraform では対象のインフラがどのような状態であるか、Stateファイルというものを使って管理しています。この機能は事前に差分を照会したりするので、重要なファイルです。ただ複数人で実行する際は、このファイルを共有する必要があります。デフォルトではローカルにこのファイルは保存されてしまいますが、Remote state
という機能を利用すれば解決できます。
Remote state
で利用できる各サービスは、以下のページに記載されています。
Backend: Supported Backend Types - Terraform by HashiCorp
私個人の意見としておすすめは、S3
です。理由としては、バージョニングの機能が提供されていること、Dynamo DB
と連携して実行中のロック機能を提供することが可能という点です。
既に構築済みのものがあるのだけど…
Import - Terraform by HashiCorp
import
機能を利用することによって、現在のインフラのリソースの状態をstateファイルに反映しTerraformの管理下にすることが可能です。
ただ、全てのリソースに対応が出来ていないので、PRを送るか、手動でstateファイルを編集するなどが必要になる場面もあります。
操作ミスで消えてしまうリソースがあると困るのだけど…
Resource Lifecycle - Terraform by HashiCorp
特定のリソースは、ある設定が変更された際に、作り直しが必要なものが存在します。たとえば、AWS の ec2 のインスタンスの user data
などは変更があるとインスタンスを削除し新しく構築が行われます。ただ、今回は Terraform の設定ファイルのみの編集だけを行いインスタンスの再作成は、実行してほしくないという場合、以下のような書き方が可能です。
resource "aws_instance" "web" { ami = "ami-408c7f28" instance_type = "t1.micro" user_data = "${template_file.userdata.rendered}" lifecycle { ignore_changes = ["user_data"] } }
その他にも、lifecycle
では削除することそのものを防ぐことも可能です。
さいごに
いくつか個人的に紹介したい機能を紹介させていただきました。 他にも様々な場面で有効な機能が存在します。 Terraform はインフラ系のエンジニアだけのツールではなく、様々なエンジニアとインフラ層を近づけてくれるツールだと思っています。 ちょっとでもインフラに興味があるエンジニアであれば、触ってみてください。