Terraform 0.4 (参考訳) | Pocketstudio.jp log3

HashiCorp の Blog に Terraform の新バージョンに関する投稿がありました。例によって、翻訳してみました。参考程度にどうぞ。

Terraform 0.4 – HashiCorp
https://hashicorp.com/blog/terraform-0-4.html

■Terraform 0.4

私達は Terraform 0.4 をリリースします。Terraform は安全かつ効率的にビルド・組みあわせ・インフラの立ちあげを行います。

Terraform 0.4 は、これまでで最大のリリースです。私達はAWSの広範囲をサポートするような、複数の主要な機能を提供します。Terraform 0.4 は新しいコア・コミッターの Paul Hinze と Clint Shryock 、そして80人ものコントリビューターにより、これまで最もコミュニティが関わりました。

Terraform 0.4 の見所は、次の点です：

新プロバイダ：Docker
新プロバイダ：OpenStack
機能：作業対象のターゲット化
機能：リモートモジュール
新コマンド：taint
設定機能：計算、新機能、自己変数
AWS 機能と改善

■新プロバイダ：Docker

Terraform 0.4 は Docker コンテナのライフサイクル管理をサポートする初めてのバージョンです。Terraform Docker プロバイダは Docker サーバ API を通して Docker と通信し、簡単な単一のサーバ上で管理するように、複数のホストやクラスタを簡単に管理できるようになります。

Docker は Terraform のモデルとピッタリ合います。仮想マシンやその他のリソースを管理するのと同じように、コンテナを管理できるようになります。

resource "docker_container" "web" {
    image = "${docker_image.ubuntu.latest}"
    count = 5
}

resource "docker_image" "ubuntu" {
    name = "ubuntu:latest"
}

今回のリリースで Docker コンテナの設定機能をサポートしましたが、多くの設定範囲についてはまだサポートしていません。次のリリースで追加することを考えています。

Docker プロバイダに関するドキュメントはこちらをお読みください。

■新プロバイダ：OpenStack

Terraform 0.4 は OpenStack をサポートしています。OpenStack プロバイダは OpenStack API の v2 と v1 をサポートし、インスタンスやフローティングIPやブロックストレージ、キーペアなど、多くのリソースをサポートします。

OpenStack プロバイダは、これまでの Terraform モデルと同じように扱えます：

# OpenStack プロバイダの設定
provider "openstack" {
    user_name  = "admin"
    tenant_name = "admin"
    password  = "pwd"
    auth_url  = "http://myauthurl:5000/v2.0"
}

# ウェブ・サーバの作成
resource "openstack_compute_instance_v2" "test-server" {
    ...
}

OpenStack プロバイダに関するドキュメントはこちらをお読みください。

■機能：作業対象のターゲット化 (Targeted Operations)

作業対象のターゲット化(targeted operation)は Terraform の新機能で、作業手順（ワークフロー）を拡張し、本当に変更をしたい範囲のみ処理できるよう、処理範囲をより確実に制御します。ターゲット化できるのは、新しいリソースや複数のリソースを「refresh」「plan」「apply」「destroy」で適用できます。これが意味するのは、他に希望する状態に向けた変更箇所があったとしても、あくまでターゲット化されたリソースのみを変更します。

例えばこんな場面で使います：オペレータは Terraform 設定に大きな変更をしたいと要望があったとします。しかし、あなたは現時点ではウェブサーバの更新しか許可したくありません。そこで、この作業対象のターゲット化を行うことで、対象外の更新作業を先送りさせることができます。

構文は以下の形式です：

$ terraform apply -target=aws_instance.web
...

対象となる操作は「refresh」「plan」「apply」「destroy」です。

■機能：リモートモジュール

Terraform の前回リリース、Terraform 0.3ではモジュールを導入しました。モジュールは Terraform をカプセル化するユニットで、オペレータがインフラ構成物を共有したり取り扱ったりするのに、１つのユニットで入出力を行います。

この考え方を一歩進め、Terraform 0.4 はリモートモジュールと連携するようにしました。リモートモジュールは、独立した Terraform 実行時の出力結果にアクセスする唯一の方法です。

リモートモジュールは、組織内で他のチームがインフラの構築や変更を行う時に、インフラのリソースをリードオンリーで共有するためのチーム手法です。例えば、あるチームが高い可用性のデータベース・クラスタの構築やメンテナンスをしたいとします。他のチームはリモートモジュールのURLにアクセスすることで、インフラを変更してしまう危険性無く、その変更情報を参照することができます。

リモートモジュールは Terraform の標準的なリソースとしてアクセスできます。次のような形式です：

resource "terraform_state" "vpc" {
    backend = "atlas"
    config {
        path = "hashicorp/vpc-prod"
    }
}

resource "aws_instance" "foo" {
    # ...
    subnet_id = "${terraform_state.vpc.output.subnet_id}"
}

上の例では、インフラ部分と他のチームがアクセスできる部分を別々のパーツに分けています。

■コマンド：taint

Terraform 0.4 は新しいトップ・レベルの CLI コマンド「terraform taint」を導入しました。

taint コマンドは、汚れている(taint)リソースを明確化します。汚れたリソースは次の play や apply 時に破棄・再生成されます。Terraform は既存のリソースを再生成するだけで、その他には影響を与えないかもしれません。

これには使い道が複数かあります。１つはTerraformを使わずに稼働しているものだけを、強制的に再実行する場合。もう１つは、Amazon EC2のより優れているハードウェア上でリソースを再利用する場合です。

taint コマンドを使う前に、リソース設定をリモートに置いて再追加する必要があります。これらは全てコマンドライン上から利用できます。構文は次の通りです：

$ terraform taint aws_instance.web
...

taint コマンドに関する詳細はこちらをご覧ください。

■Terraform 設定のアップデート

Terraform における設定は Terraform 0.4 で大きな改善が施されました。数値計算が利用できるようになった他、”self” 変数などの新しい変数や、多くの新機能が追加されました。

数値計算によって、設定を計算して補完できるようになります。例えば「count.index」はゼロから数える典型的なものですが、インスタンス起動時の名前には、その番号に１を加えたい場合が考えられます。それも、今や些細なことです：

resource "aws_instance" "web" {
    count = 5
    tags {
        Name = "web-${count.index+1}"
    }
}

数値計算の範囲はリテラル数に限りません。「${count.index+aws_instance.tags.number}」のような指定もできます。しかし、変換した数値が値を持たなければ、実行時にエラーとなります。

数値計算に加えて、新しく３つの設定機能、「format」「replace」「split」が利用できるようになります。それぞれの使い方はドキュメントに書かれています。その中でも「split」は「join」（0.3 で導入）と同様、目立った変更点となりました。これはTerraformの設定において、モジュールと変数入力によるデータリストの変換ができるようになるからです。

私達はこれらに対してファーストクラスの対応をしたいと思っていますが、現時点では注力できていません。

最後に、Terraform の設定においてself変数(自己変数；self variables)が利用できるようになりました。self変数とは、自分自身のリソースを参照するための属性です。現時点ではプロビジョナーの中で利用できます。例えば：

resource "aws_instance" "web" {
    provisioner "local-exec" {
        command = "echo ${self.private_ip_address}"
    }
}

self変数は単一もしくは複数アカウントで自分自身のリソースをプロビジョニングする際の問題を解決しますし、そこにはTerraform グラフのサイクル作成は不要です。

■AWS 対応機能の改善

Terraform 0.4 の開発に於いて、多くのコミッターが AWS サポートの改善に尽力しました。そのお陰で次のようにいくつもの影響のある機能を追加することができました。

AWS リソースに Terraform でタグをつけられること
ロードバランサー、オートスケール・グループ、起動設定に関するワークフローなどに特化したバグ修正や機能改善
RDS を壊さないアップデート
多くの依存性を壊す問題を修正したため、Terraform における実行結果と AWS 上の状態が一貫性を持てるように
公式 AWS SDK に完全に移行したため、Terraform は AWS API にフルアクセスできるようになりなりました。そのため今後 AWS でリリースされる機能にも対応できるように

0.4 で私達が集中したのは、大きな機能（タグ付けのような）と、これまでサポートしていたリソースに関するバグの修正でした。以降のバージョンでは、私達は AWS が提供しているリソースの完全なるサポートに注力するつもりです。

■更に多くのこと…

新しいプロバイダ：DNSMadeEasy。DNSMadeEasyを通してDNS設定を行います。

SSH エージェントのリモート実行(remote-exec)のサポート。「agent = true」を指定することで、リモート実行プロビジョナーは、ローカルの SSH エージェントをリモートホストに接続します。

継続的な状態の保存。これまでのTerraformは、Terraform を実行することにより、状況を更新することができました。ですが、Terraform が様々な理由によりクラッシュした場合（コンピューターが突然シャットダウンする、メモリ圧迫により kernel に kill されてしまう、等）、その時の状態に関する情報は失われてしまいました。そこで、terraform は全てのリソース変更毎に状態を保持しますので、何か起こっても影響を最小限に抑えます。

多くのバグ修正を行いました。上記の機能に加え、Teffaromのコアからプロバイダに至るまで多くのバグを修正しています。詳細な情報については CHANGELOG をご覧ください。

■まとめ

HashiCorp において、私達は 0.4 をリリースするにあたり、技術面やユーザー経験いずれも前に増して非常に安定するよう懸命に努力しました。Terraform 0.4 の方向性とは次のようなものです。私達はツールの内部の安定性に自信を持っており、提供する機能はユーザー経験、例えば数値計算やターゲット化や新しいプロバイダに注力してきました。

加えて、Teffarom に対してフルタイムで働く複数のコア・コミッターが居ます。Terraform の開発は光速のペースに加速しており、私達は既に 0.5 の機能に取り組んでいます。私達はまもなく新しい更新によって、あなた方を輝かせることを楽しみにしています。

ダウンロードして試してみてください。