Terraform職人入門: 日々の運用で学んだ知見を淡々とまとめる

# はじめに
この記事は [CrowdWorks Advent Calendar 2017](https://qiita.com/advent-calendar/2017/crowdworks) の8日目の記事です。

Terraform職人の @minamijoyo です。Infrastructure as Codeしてますか？

インフラのコード管理に [Terraform](https://www.terraform.io/) を使い始めて2年ちょっと、本番環境で運用していると日々色んな学びがあるので、Terraformやってみた系の入門記事では語られない、現場の運用ノウハウ的なものを共有してみようかと思います。
Terraformを使い始めた or 使っている人が、こんなときどうするの？っていうときに参考になれば幸いです。

書き始めたら超長文になりました。概要は以下のとおりです。

- 公式ドキュメントを読もう
- tfファイルを書く技術
  - インデントを揃える
  - 組み込み関数に親しむ
  - lifecycleブロックを使う
      - リソースの差分を無視する
      - リソース再生成のときに新しいのを作ってから古いのを削除する
      - リソースのうっかり削除の保護
  - テンプレートを使う
      - 外部ファイルを文字列として読み込む
      - テンプレートに変数を埋め込む
  - モジュールでコードを共通化する
      - モジュールの作り方
      - production/stagingなどの環境差分を管理する
      - モジュール間で値を参照する
      - Stateを跨いで値を参照する
  - 条件分岐したい
      - 条件によって変数の値を変える
      - 条件によってリソースを作成したりしなかったり
- Terraformのバージョンを管理する技術
  - Terraformをバージョンアップする
  - Terraformのバージョンを切り替える
  - Terraformのバージョンを固定する
  - Terraformプロバイダをバージョンアップする
  - Terraformプロバイダのバージョンを固定する
- tfstateファイルを書く技術
  - ローカルでミニマムのStateを見てみる
  - リモートのStateを見る
  - 強制的にリソースを再生成する
  - Terraform管理外の既存のリソースをTerraform管理下に入れる
  - tfファイルをリファクタリングする
- Terraformをデバッグする技術
  - デバッグログを出力する
  - Terraformのソースコードをコンパイルする
  - デバッグログにソースコードのファイル名と行番号を付ける
  - Terraformをデバッガでステップ実行する

本稿執筆時点のTerraformのバージョンはv0.11.1です。普段はAWSをいじってるので、説明の例としてAWSが出てきますが、扱っているトピック自体はAWSだけじゃない汎用的な話がほとんどなので、適宜お使いのクラウドプロバイダーに読み替えて下さい。

# 公式ドキュメントを読もう
まず最初に、何を当たり前のことを言われそうですが、分からないことはまずは公式ドキュメントを読みましょう。

Terraformは現在も活発に開発されているプロダクトです。ネットでぐぐって出て来る情報は古いことがあるので（この記事もいずれはそうなっちゃうと思いますが）、迷ったら公式ドキュメントを見に行くのが確実です。
https://www.terraform.io/docs/index.html

Terraformで使われている用語が分かると公式ドキュメントなどが読みやすくなるので、最低限理解しておきたい用語についてざっくり説明しておくと、以下の理解でだいたいOK。

| 用語 | 意味 |
|:---|:---|
| Configuration | インフラ設定のコード。要するに `*.tf` ファイルにDSLで書くTerraformのコードのこと。 |
| HCL | HashiCorp Configuration Languageの略。`*.tf` ファイルで使われているDSLのこと。 |
| Resource | Terraformで管理する対象の基本単位。 |
| Data Source | Terraform管理外だけど、Terraform内で参照したい参照専用の外部データ。 |
| Provider | ResourceやData Sourceなどを作成/更新/削除するプラグイン。aws/google/azurermなど。 |
| Provisioner | リソースの作成/削除時に実行するスクリプトなどのプラグイン。local-exec/remote-exec/chefなど |
| State | Terraformが認識しているリソースの状態。 `*.tfstate` ファイルのこと。 |
| Backend | Stateの保存先。local/s3/gcsなど。 |
| Module | ResourceやData Sourceなどを再利用可能なようにまとめたConfigurationの単位。 |

ところで、 `terraform apply` してみたらエラーが出たとかあるあるで、公式ドキュメントの対象のリソースの説明読んでもパラメータの意味とかがよく分からない場合、関連するIssueを探したり、最終的にソースコードを読みに行くしかないです。
Terraformはv0.10からProviderごとにリポジトリが分割されているので、TerraformのIssueやコードを探す場合は、リポジトリ構成を理解しておく必要があります。

Terraformの本体は以下のリポジトリにあります。
https://github.com/hashicorp/terraform

Providerはterraform-providersというOrganizationの下にあって、
https://github.com/terraform-providers

例えばAWSだと以下のリポジトリにあります。
https://github.com/terraform-providers/terraform-provider-aws

ちなみにProvisionerは数が少ないので、Terraform本体のリポジトリのbuiltinディレクトリの下にあります。

# tfファイルを書く技術
## インデントを揃える
インフラをコードで管理することのメリットの1つは、設定変更がコードレビュー可能になることですが、コードレビューでtfファイルのインデントが揃っていない、とか指摘するのは不毛です。

Terraformでは `terraform fmt` というインデントなどのスタイルを揃えるコマンドを公式に提供しているので、これを使いましょう。Terraform自体はGo言語で開発されており、Go言語には `go fmt` というコードスタイルを揃えるコマンドがあるので、たぶんそれの影響を受けてるのかなーと思います。いずれにせよ個人の好みではなく、公式にスタイルはかくあるべしというのが提示されているのは、不毛な議論を減らせてありがたいです。

`terraform fmt` は、デフォルトでカレントディレクトリにあるファイル全部のスタイルを揃えます。

例えば以下のように微妙にイコールの位置が揃っていないファイルに

```main.tf
provider "aws" {
  version = "1.4.0"
  region = "ap-northeast-1"
}
```

`terraform fmt` をかけると

```
$ terraform fmt
```

以下のようにイコールの位置が修正されます。

```
provider "aws" {
  version = "1.4.0"
  region  = "ap-northeast-1"
}
```

ただ毎回手動で実行するのは忘れがちなので、エディタのプラグインなどを使ってファイルの保存時に自動で `terraform fmt` を実行するようにしておけば、意識せずに常にフォーマットが揃った状態になるのでオススメです。また自動フォーマットの副次的なメリットとして、括弧などのとじ忘れで構文エラーがあると、フォーマットに失敗するので、構文エラーレベルの初歩的なミスに早期に気付くことができて便利です。

あなたのお気に入りのエディタに、Terraform用のプラグインがないかを調べる価値はあります。
私は普段NeoVimを使ってるので、ここでは(Neo)Vimについて簡単に説明しますが、Emacs/Atom/VSCode/IntelliJなどでも、ぐぐるといろいろ情報が出てくるので、自分の好きなエディタでTerraformのプラグインがないか調べてみて下さい。

(Neo)Vimの場合は、以下の `hashivim/vim-terraform` を入れるとシンタックスハイライトや、ファイル保存時の自動フォーマットが使えるようになります。
https://github.com/hashivim/vim-terraform

```~/.vimrc
NeoBundle 'hashivim/vim-terraform'
let g:terraform_fmt_on_save = 1
```

READMEにも書いてありますが、ファイル保存時の自動フォーマットを有効にするには `let g:terraform_fmt_on_save = 1` をセットしておきます。

また `juliosueiras/vim-terraform-completion` も入れるとリソースタイプやパラメータ名などのオムニ補完もできるようになります。
https://github.com/juliosueiras/vim-terraform-completion

```~/.vimrc
NeoBundle 'juliosueiras/vim-terraform-completion'
```

ちなみにこの `vim-terraform-completion` は内部的にRubyに依存してるので、Vimの場合は `+ruby` オプションが有効になってるか確認して下さい。
NeoVimの場合は `gem install neovim` が必要です。

## 組み込み関数に親しむ
Terraformには組み込み関数がいくつかあって、知ってるとtfファイルを書く時に便利なことがあるので、文字列とかを加工したくなったら、便利な組み込み関数がないか調べてみましょう。
https://www.terraform.io/docs/configuration/interpolation.html#built-in-functions

この関数の挙動よく分からんなぁーってときは `terraform console` でインタラクティブなREPLが起動できるので、これで試すと便利です。

```
$ terraform console
> coalesce("","hoge")
hoge
> coalesce("fuga","hoge")
fuga
```

## lifecycleブロックを使う
### リソースの差分を無視する
Terraform使ってると、一部のリソースの設定差分を無視したいと思う時があります。例えば `aws_autoscaling_group` を使ってBlue/Greenデプロイメントをしようとすると、アタッチしている `load_balancers` を動的に変更したくなります。このように、リソース自体はTerraformで作るんだけど、運用の都合上、手動で設定いじっても無視して欲しい属性は `lifecycle` ブロックで `ignore_changes` に指定すると差分を無視できます。

```main.tf
resource "aws_autoscaling_group" "app_1" {
  name = "app-asg-1"
  ...

  lifecycle {
    ignore_changes = ["load_balancers"]
  }
}
```

また `ignore_changes` のよくある用途として、パスワードなどをtfファイルに平文でハードコードしたくない場合に使えます。
Terraformでリソース作るときに設定項目としてパスワードなどのクレデンシャルが必要になる場合があります。例えばAWSのRDSインスタンスを立てる場合は、`aws_db_instance` の `password` にDBのマスターパスワードを設定値として記載する必要があります。
このようなクレデンシャルは、tfファイル上は変数にして、`terraform apply` 時に渡すこともできますが、この方法はStateにパスワードが平文で記録されてしまい、Stateにアクセス可能な人なら誰でも参照できてしまうので、個人的にはあまりオススメしません。

個人的には、このようなパスワードなども `ignore_changes` でTerraformの管理対象外にしちゃうのがオススメです。つまり、初回のterraform applyのときに初期パスワードのみ記載しておき、 `ignore_changes` で指定しておけば、あとでパスワードを変えても差分としては無視されるので、パスワード変更可能です。

```main.tf
resource "aws_db_instance" "db_instance" {
  identifier = "db"
  password   = "hoge"
  ...

  lifecycle {
    ignore_changes = ["password"]
  }
}

```

### リソース再生成のときに新しいのを作ってから古いのを削除する
`lifecycle` の使い方の他の例は、リソースの再生成時に古いの削除=>新しいの作成ではなく、新しいの作成=>古いの削除の順に実行したいときです。例えば `aws_autoscaling_group` に紐づく `aws_launch_configuration` を更新したい場合、 `aws_launch_configuration` は更新ができないリソースなので、基本的に古いの削除=>新しいの作成が毎回発生しますが、このままだとリソースの依存として `aws_autoscaling_group` からの参照が残っていて古いのを削除できません。 ただ無停止で更新したいので、 `aws_autoscaling_group` を削除はしたくありません。このような微妙なリソースの依存関係がある場合は、lifecycleブロックで `create_before_destroy = true` を指定することで、新しいの作成=>古いの削除の順に実行できます。

```main.tf
resource "aws_launch_configuration" "as_conf_1" {
  image_id    = "ami-xxxx"
  name_prefix = "app-"

  lifecycle {
    create_before_destroy = true
  }
}
```

この方法の1点注意点として、新しいの作成=>古いの削除の順に実行するため、一時的に2つのリソースができます。リソースのネーミングでユニーク制約がある場合は、リソースの作成に失敗します。自動採番されるようなリソースであれば問題ありません。

### リソースのうっかり削除の保護
`lifecycle` には `prevent_destroy` というリソースのうっかり削除を保護するフラグがあります。ただ productionのインフラをいじってるとだいたい消しちゃまずいリソースが大半なので、あんまりこれに頼りすぎるのはよくないかなとは思います。ちゃんとplanを見ましょう。

## テンプレートを使う
### 外部ファイルを文字列として読み込む
例えばリソースの設定パラメータがJSONの文字列を受け取る場合、その場でヒアドキュメントで書くことも可能ですが、外部ファイルを文字列として読み込むこともできます。

```main.tf
resource "aws_iam_role" "ec2_role" {
  name = "ec2-role"

  assume_role_policy = "${file("./ec2_assume_role_policy.json")}"
}
```

```ec2_assume_role_policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

特にJSONは外部ファイルに保存するとエディタでシンタックスハイライトが効いたりして、末尾カンマでエラーになるなどの初歩的なミスが防げるので、外部ファイルに切り出すとよいかと思います。

### テンプレートに変数を埋め込む
設定ファイルが読み込めるようになると、変数埋め込みたくなることありますよね。
こーゆーときは変数を埋め込みたい場所に `${変数名}` と書いておいて、

```kms_policy.json
{
  "Version": "2012-10-17",
  "Id": "key-policy-for-${account_name}-account",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::${account_id}:root"},
      "Action": "kms:*",
      "Resource": "*"
    }
  ]
}
```

`template_file` のData Sourceを作って、変数を外から差し込みます。

```main.tf
data "template_file" "kms_policy" {
  template = "${file("${path.module}/kms_policy.json")}"

  vars {
    account_name = "dev"
    account_id   = "123456"
  }
}
```

で、実際に文字列として必要な場所で、renderします。

```main.tf
resource "aws_kms_key" "key" {
  policy = "${data.template_file.kms_policy.rendered}"
}
```

## モジュールでコードを共通化する
### モジュールの作り方
Terraformのいいところの一つとして、似たような構成のサーバを立てたりするときに、だいたいコピペ＆置換で仕事が完了することなのですが、コピペが増えてくると、コードを共通化したくなります。
Terraformで再利用可能なコードの塊を定義する方法として `module` があります。
適当なhogeディレクトリを掘って、その中に共通化したい `resource` などを定義します。

```hoge/null_resource.tf
provider "null" {}

resource "null_resource" "hoge" {}
```

そして、利用したい場所で、 `module` を使って、 `source` で相対パスを指定して読み込みます。

```main.tf
module "bar" {
  source = "./hoge"
}

module "baz" {
  source = "./hoge"
}
```

このようにディレクトリ掘ってtfファイルをグループ化するだけで、モジュールを使い始められます。
ローカルディレクトリ以外に外部のリポジトリも参照する仕組みがあり、最近Terraform Registryという公開モジュールをオープンに共有する仕組みもできました。
https://registry.terraform.io/

リソースのネーミングルールなどの都合もあるので、公開されているモジュールをそのまま使えるケースはあんまりないんじゃないか？という気もしますが、他の人がどのようなTerraformのコードを書いてるのか参考になるので、見てみるとよいんじゃないでしょうか。

### production/stagingなどの環境差分を管理する
モジュールには `variable` も渡せるので、production/stagingなどの環境を差分を管理する場合は、共通コードをモジュール化し、差分を `variable` で吸収することが可能です。

`modules/hoge/*` 配下に共通化したいtfファイルを置いて、
`services/myapp/production/main.tf` でproduction環境用の設定を、`services/myapp/staging/main.tf` でstaging環境用の設定をとディレクトリを分けて管理します。

```
$ tree
.
├── modules
│   └── ec2
│       └── aws_instance.tf
└── services
    └── myapp
        ├── production
        │   └── main.tf
        └── staging
            └── main.tf
```

```modules/ec2/aws_instance.tf
provider "aws" {}

resource "aws_instance" "app" {
  ...

  tags {
    Name    = "app-${var.service}-${var.env}"
    service = "${var.service}"
    env     = "${var.env}"
  }
}
```

```services/myapp/production/main.tf
module "app" {
  source  = "../../../modules/ec2"
  service = "myapp"
  env     = "production"
}

```

```services/myapp/staging/main.tf
module "app" {
  source  = "../../../modules/ec2"
  service = "myapp"
  env     = "staging"
}
```

実はTerraformには1つのディレクトリで複数のStateを扱うWorkspaceという機能もあるのですが、個人的には普通にディレクトリを分けて管理する方が楽です。
production/stagingは完全に同じリソース構成で、設定のパラメータの差分がちょっとだけあるという理想的な世界ではWorkspaceでも運用できるかもしれませんが、現実的には、stagingだけまだリリース前の検証用の一時的なリソースが立ってたりとか。完全に同じ構成にならないことも多いので、モジュールの読み込みの有無や一部の環境だけ存在するリソースなど、差分を吸収できる場所があったほうが都合がよいからです。
また、ディレクトリを分けることの副次的な効果として、production/stagingなどの環境ごとにAWSのアカウントが異なる場合に、AWSアクセスキーなどの環境変数を使い分けないといけないのですが、ディレクトリが分かれていれば[direnv](https://github.com/direnv/direnv)などのツールを用いて、環境変数の切り替えが簡単に行なえます。

複数の環境をまたいでアカウントでグローバルなリソースは、別のディレクトリでStateを分けて、後述のStateを跨いで値を参照する方法を使っています。

### モジュール間で値を参照する
モジュール分割を進めると、こっちのモジュールで作った値を、別のモジュールで参照したいということが発生します。
モジュールからの出力は `output` で、モジュールへの入力は `variable` でできるので、これらを組み合わせることで、モジュール間で値を引き回せます。

```modules/ec2/aws_instance.tf
provider "aws" {}

variable "service" {}

variable "env" {}

output "hoge_private_ip" {
  value = "${aws_instance.hoge.private_ip}"
}

resource "aws_instance" "hoge" {
  tags {
    Name    = "hoge-${var.service}-${var.env}"
    service = "${var.service}"
    env     = "${var.env}"
  }
}
```

```services/myapp/production/main.tf
module "app" {
  source  = "../../../modules/ec2"
  service = "myapp"
  env     = "production"
}

module "foo" {
  source = "../../../modules/bar"
  ip     = "${module.app.hoge_private_ip}"
}
```

```modules/bar/bar.tf
variable "ip" {}
```

### Stateを跨いで値を参照する
先ほどの例ではモジュールをまたいだ変数の参照でしたが、Stateが分かれてる場合は `terraform_remote_state` のData Sourceを使うことで、他のStateの値を参照することができます。

例えばStateAで作ったリソースをStateBで参照したい場合、まずStateA側で参照したい値をoutputで出力しておきます。

```accounts/main/iam/output.tf
output "hoge_instance_profile_name" {
  value = "${aws_iam_instance_profile.hoge.name}"
}
```

で、参照したい側のStateBで `terraform_remote_state` を使ってStateAのData Sourceを作って参照します。

```services/myapp/main.tf
data "terraform_remote_state" "aws_main_iam" {
  backend = "s3"

  config {
    bucket = "my-tfstate-main"
    key    = "aws-accounts/main/iam/terraform.tfstate"
    region = "ap-northeast-1"
  }
}

module "hoge" {
  source = "../../../modules/hoge"

  instance_profile_name = "${data.terraform_remote_state.aws_main_iam.hoge_instance_profile_name}"
}
```

管理するリソースが増えてStateが肥大化すると、 `terraform plan` のリフレッシュが遅くなったり、オペミスで事故った時の影響範囲が広くなるので、適当な粒度でStateを分割しておくとよいでしょう。

## 条件分岐したい
### 条件によって変数の値を変える
Terraform書いてるとif文書きたくなることありますよねー。残念ながら今のところif文はないんですが、三項演算子なら書けます。

```main.tf
resource "aws_instance" "web" {
  subnet = "${var.env == "production" ? var.prod_subnet : var.dev_subnet}"
}
```

### 条件によってリソースを作成したりしなかったり
モジュールでコードを共通化したものの、変数だけで差分を吸収しきれず、条件によって一部のリソースを作ったり作らなかったりしたい時もあります。まぁモジュールを分けてもいいんだけど、ほぼ同じだったりすると、分けるほどでもないかなみたいなとき。

Terraformにはリソースを複数個作成するのに `count` というパラメータがあって、これを先ほどの三項演算子と組み合わせると、条件によって作ったり作らなかったりが実現できます。

```main.tf
resource "aws_cloudwatch_log_group" "hoge" {
  count = "${var.create_log_group ? 1 : 0}"
  name  = "hoge"
}
```

# Terraformのバージョンを管理する技術
## Terraformをバージョンアップする
Terraformは日々進化しています。バージョンアップしたい理由は様々ですが、最新の機能が使いたい、踏んだ既知のバグが治ってる、など長く運用しているとバージョンアップしたくなることもあるでしょう。

本稿執筆時点のTerraformのバージョンはv0.11.1ですが、まだv1.0に到達していないので、v0.10.x => v0.11.x などマイナーバージョンアップでも非互換な変更が入ります。ここではTerraform本体のバージョンアップについて記載します。ここでTerraform本体と言っているのは、 [hashicorp/terraform](https://github.com/hashicorp/terraform) のことで、Terraformはv0.10から各クラウドプロバイダ(AWS, GCP, Azureなど）に依存したプラグインが [terraform-providers/terraform-provider-*](https://github.com/terraform-providers) に分離されました。プロバイダのバージョンアップについては後述します。

Terraformのバージョンアップをする場合には、いくつか注意点がありますが、まずバージョンアップ前に既に出ている警告を解消することをオススメします。事前にdeprecatedな警告ログを出しておいて、次バージョンで機能削除などがあるので。
このような理由からマイナーバージョンアップでもv0.9.x => v0.11.x などバージョン飛ばしはせずに、v0.9.x => v0.10.x => v0.11.x と刻んで上げた方が無難です。マイナーバージョンはだいたい今のところ、数ヶ月に1回ぐらいの頻度でリリースされてます。

非互換な修正が入る場合は、UpgradeガイドやCHANGELOGに記載があるので、必ず確認しましょう。`*.tf` ファイルの修正が必要な場合もあります。

公式のUpgradeガイドはバージョンごとに以下で参照できます。
https://www.terraform.io/upgrade-guides/index.html

CHANGELOGはGitHubの本体のリポジトリにあります。
https://github.com/hashicorp/terraform/blob/master/CHANGELOG.md

チームで複数人で開発している場合は、バージョンを揃えないと事故の元です。バージョンアップに伴い、非互換変更で、`*.tf` ファイルの修正が必要な場合は、チーム内でタイミングを見計らって一気に切り替えます。

バージョンアップの具体的な手順は、後述の「Terraformのバージョンを切り替える」を参考にして下さい。

バージョンアップしたら `terraform plan` しなおして、意図しない差分が出ていないかや、新しい警告が出ていないかチェックしましょう。変な差分が出てる場合は、関連した変更がないかCHANGELOGを探しましょう。

## Terraformのバージョンを切り替える
Terraformは活発に開発されており、バージョンアップも比較的早いプロダクトです。
チームで開発する場合は、全員が同じバージョンを使わないと、微妙なバージョン違いで意図しない差分が出ることがあり注意が必要です。
Terraformはコンパイル済のバイナリとして配布されているので、特定のバージョンをダウンロードしてきてPATHを通すだけで、好きなバージョンが使えるのですが、その辺を簡単にしてくれる [tfenv](https://github.com/kamatama41/tfenv) というツールを使うのがオススメです。

tfenvはMac OSXであればHomebrew経由でインストールできます。それ以外の場合は、git cloneしてきて適当にPATHを通すと使えます。詳細は[tfenvのREADME](https://github.com/kamatama41/tfenv/blob/master/README.md)を参照して下さい。

```
$ brew install tfenv
```

```
$ tfenv --help
Usage: tfenv <command> [<options>]

Commands:
   install       Install a specific version of Terraform
   use           Switch a version to use
   uninstall     Uninstall a specific version of Terraform
   list          List all installed versions
   list-remote   List all installable versions
```

利用可能なバージョンを確認します。

```
$ tfenv list-remote | head
0.11.1
0.11.0
0.11.0-rc1
0.11.0-beta1
0.10.8
0.10.7
0.10.6
0.10.5
0.10.4
0.10.3
```

指定のバージョンをインストールします。

```
$ tfenv install 0.11.0
[INFO] Installing Terraform v0.11.0
[INFO] Downloading release tarball from https://releases.hashicorp.com/terraform/0.11.0/terraform_0.11.0_darwin_amd64.zip
######################################################################## 100.0%
[INFO] Downloading SHA hash file from https://releases.hashicorp.com/terraform/0.11.0/terraform_0.11.0_SHA256SUMS
tfenv: tfenv-install: [WARN] No keybase install found, skipping GPG signature verification
Archive:  tfenv_download.ef4YCM/terraform_0.11.0_darwin_amd64.zip
  inflating: /usr/local/Cellar/tfenv/0.6.0/versions/0.11.0/terraform
[INFO] Installation of terraform v0.11.0 successful
[INFO] Switching to v0.11.0
[INFO] Switching completed
$ terraform --version
Terraform v0.11.0
```

tfファイルを管理しているリポジトリのルートにでも `.terraform-version` というファイルを置いて、その中にバージョン番号を書いておくと、 `tfenv install` のバージョン番号を省略できます。

```
$ cat .terraform-version
0.10.7
```

```
$ tfenv install
[INFO] Installing Terraform v0.10.7
[INFO] Downloading release tarball from https://releases.hashicorp.com/terraform/0.10.7/terraform_0.10.7_darwin_amd64.zip
######################################################################## 100.0%
[INFO] Downloading SHA hash file from https://releases.hashicorp.com/terraform/0.10.7/terraform_0.10.7_SHA256SUMS
tfenv: tfenv-install: [WARN] No keybase install found, skipping GPG signature verification
Archive:  tfenv_download.bHmtrT/terraform_0.10.7_darwin_amd64.zip
  inflating: /usr/local/Cellar/tfenv/0.6.0/versions/0.10.7/terraform
[INFO] Installation of terraform v0.10.7 successful
[INFO] Switching to v0.10.7
[INFO] Switching completed
```

この方法のうれしいところは、tfファイルのリポジトリごとにTerraformのバージョンが違っても、cdすると自動で `.terraform-version` を見てバージョンを切り替えてくれるところです。

## Terraformのバージョンを固定する
tfenvはバージョンを切り替えてくれる便利ツールですが、開発チーム全員がtfenvを使っていない場合はバージョンの強制にはなりません。使用するTerraformのバージョンを固定して強制するにはtfファイルに `terraform.required_version` を定義します。

例として、terraform v0.10.7に固定してみました。

```main.tf
terraform {
  required_version = "= 0.10.7"
}
```

これを例えばv0.11.0で使うと、以下のようにエラーが出ます。

```
$ terraform --version
Terraform v0.11.0
+ provider.null v1.0.0

$ terraform plan

Error: The currently running version of Terraform doesn't meet the
version requirements explicitly specified by the configuration.
Please use the required version or update the configuration.
Note that version requirements are usually set for a reason, so
we recommend verifying with whoever set the version requirements
prior to making any manual changes.

  Module: root
  Required version: = 0.10.7
  Current version: 0.11.0

```

バージョンを厳密に強制したい場合は、tfファイル側に書くとよいでしょう。

## Terraformプロバイダをバージョンアップする
Terraformプロバイダをバージョンアップする際の注意点は、警告ログやCHANGELOGを確認するなど基本動作はだいたいTerraform本体と同じです。

たとえばAWSの場合は、CHANGELOGは以下にあります。
https://github.com/terraform-providers/terraform-provider-aws/blob/master/CHANGELOG.md

バージョンアップの具体的な手順は `terraform init`  コマンドに `-upgrade` オプションを指定すると、バージョン制約を満たす最新のプロバイダにアップグレードされます。

```
$ terraform init -upgrade
```

なので、指定のバージョンにアップグレードするには、プロバイダもバージョン制約で明示的に固定しておくとよいでしょう。

## Terraformプロバイダのバージョンを固定する
プロバイダのバージョン制約はproviderブロックに書けます。例えばAWSの場合はこんなかんじです。

```main.tf
provider "aws" {
  version = "= 1.3.0"
}
```

チーム開発する場合は、バージョン間の微妙な差分でハマらないように固定しておくとよいでしょう。

# tfstateファイルを書く技術
これ以降はかなり発展的なトピックです。
Terraformを使いこなすには、Stateの状態を記録した `terraform.tfstate` の理解は避けて通れません。
tfstateを制すものがTerraformを制すと言っても過言ではないでしょう。

tfstateファイルは内部実装なので、ここに記載したこともTerraformのバージョンが上がれば古くなってしまう可能性が高いです。しかしながら現時点の知見を共有することにはなにがしかの意味があると思うので、理解している範囲で書きます。

お約束: tfstateファイルを手動でいじるのは大変危険ですので、インフラがぶっ壊れても責任は取れません。試すなら壊れて良い環境でまずは試し、自分が何をしているかを理解した上で自己責任で行って下さい。

## ローカルでミニマムのStateを見てみる

サンプルで適当なtfファイルを書きます。

```main.tf
provider "null" {}

resource "null_resource" "hoge" {}
```

`terrform apply` すると、Stateが保存されます。
リモートStateを使っていないデフォルトの場合は、ローカルのカレントディレクトリに `terraform.tfstate` という名前で保存されます。
ちょっと中身を見てみましょう。

```json
{
    "version": 3,
    "terraform_version": "0.11.1",
    "serial": 1,
    "lineage": "6fab4dbe-eca7-405b-8210-c82c5276ac28",
    "modules": [
        {
            "path": [
                "root"
            ],
            "outputs": {},
            "resources": {
                "null_resource.hoge": {
                    "type": "null_resource",
                    "depends_on": [],
                    "primary": {
                        "id": "1492336661259070634",
                        "attributes": {
                            "id": "1492336661259070634"
                        },
                        "meta": {},
                        "tainted": false
                    },
                    "deposed": [],
                    "provider": "provider.null"
                }
            },
            "depends_on": []
        }
    ]
}
```

見るとわかりますが、ただのJSONです。

各項目の意味は実装詳細としてドキュメント化されていませんが、ソースコードを眺めたかんじ、以下のとおりです。

| 項目 | 意味 |
|:---|:---|
| version | Stateファイルのフォーマットバージョンです。Stateファイル自体のフォーマットが変更された場合にマイグレーションできるようにフォーマット自体のバージョンがあります。 |
| terraform_version | Terraformのバージョン。古いTerraformで書かれたStateは新しいTerraformで読めますが、その逆はエラーになります。 |
| serial | シリアル番号です。Stateが更新されるたびにインクリメントされます。諸般の事情で手動でStateを編集する場合は、このシリアル番号もインクリメントする必要があります。 |
| lineage | Stateの血統です。うっかり間違って無関係のStateを上書いたりしないように、シリアル番号を比較することに意味があるかどうかを判別するため、Stateが初期化されるタイミングでUUIDが発行されます。 |
| modules | モジュールの状態です。 |

modulesの中は、moduleごとに状態が記録されていますが、moduleは以下の要素で構成されています。

| 項目 | 意味 |
|:---|:---|
| path | モジュールのツリーのパスです。必ずrootモジュールが1つ存在します。rootモジュールから読み込まれているhoge moduleの場合は、rootから見たツリー上の位置が、 `[root, hoge]` というように記録されてます。 |
| output | モジュールのoutputです。 |
| resources | リソースの状態です。 |
| depends_on | モジュール間の依存です。 |

resoucesの中は、resourceごとに状態が記録されていますが、resourceは以下の要素で構成されています。ちなみにresourceと言いつつ、data sourceも `data.` というprefixがついた 特殊なresourceとして記録されてます。

| 項目 | 意味 |
|:---|:---|
| type | リソースの種類です。 |
| depends_on | リソース間の依存です。 |
| primary | アクティブなインスタンスの状態です。 |
| deposed | 削除予定のインスタンスです。 `create_before_destroy` のときに使われます。 |
| provider | プロバイダの名前です。プロバイダはマルチリージョンしたりするのに、エイリアスを作ったりできるので記録されています。 |

primaryの中が実際のリソースの状態です。

| 項目 | 意味 |
|:---|:---|
| id | リソースIDです。何がIDになりうるかはリソースタイプによって異なります。 `null_resouce` の場合はただの乱数ですが、一般的にはインスタンスIDなど、APIなどでそのリソース情報を取得するのにユニークに特定し得る値が使われます。 |
| attributes | リソース属性です。リソースの設定項目などの具体的な値を保存しているのはここです。 |
| meta | Terraformコアからは無視されるけど外部ツールが使うことを意図したメタ情報です。 |
| tainted | 汚染フラグです。リソースをtainted状態にすると、次回のplanで削除=>作成で再作成するplanになります。 |

## リモートのStateを見る
リモートにStateを保存している場合でも、 `terraform state pull` するとStateを標準出力に表示できます。
Stateの状態がおかしくなっちゃったときに状態を確認したり、リダイレクトして簡易バックアップすることも可能です。

```json
{
    "version": 3,
    "terraform_version": "0.10.7",
    "serial": 554,
    "lineage": "dd612537-035f-4cf3-94c8-0618bab715cd",
    "backend": {
        "type": "s3",
        "config": {
            "bucket": "my-tfstate-main",
            "key": "services/myapp/staging/terraform.tfstate",
            "region": "ap-northeast-1"
        },
        "hash": 4435600807653202963
    },
    "modules": [
        {
            "path": [
                "root"
            ],
```

## 強制的にリソースを再生成する
諸般の理由でリソースを強制的に再生成したいときがあります。
例えば `terraform apply` に失敗しちゃって、なんか中途半端な微妙な状態のリソースができちゃったときとか。
そーゆーときは、 `terraform taint` でリソースをtainted状態にマークすると、次回のplanで強制的に削除=>作成で再生成されるplanが作られます。

```main.tf
provider "null" {}

resource "null_resource" "hoge" {}
```

```
$ terraform taint null_resource.hoge
The resource null_resource.hoge in the module root has been marked as tainted!
```

ここではrootモジュールのリソースを指定していますが、root以外のモジュール内のリソースをtaintする場合は、 引数 `-module=` でモジュールのパスを指定して下さい。

planを見てみると、以下のように `-/+` で再生成しようとしていることが分かります。

```
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

null_resource.hoge: Refreshing state... (ID: 1492336661259070634)

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

-/+ null_resource.hoge (tainted) (new resource required)
      id: "1492336661259070634" => <computed> (forces new resource)


Plan: 1 to add, 0 to change, 1 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
```

## Terraform管理外の既存のリソースをTerraform管理下に入れる
すべてがTerraformで管理されている理想的な世界であればよいのですが、既存のプロジェクトにあとからTerraformを導入した場合は、既にあるTerraform管理外のリソースをTerraformの管理下に入れたくなります。気軽に再生成できるリソースであれば、作り直しちゃうのが手っ取り早いですが、productionでもう動いちゃってるものは、現実的にはなかなか作り直しづらいものが多いのも事実です。

これまで見てきたように、Terraformは自身が管理しているリソースの状態をStateとして管理しているので、なんらかの方法でこのStateを作ってやる方法があります。

まず最初に試してみるのは、公式で提供されている `terraform import` コマンドです。このコマンドは、importしたいリソースのState上のアドレスとリソースIDを指定すると、Stateに新しいリソースを追加してくれます。注意点として、Configurationを自動で生成してくれるわけではないので、tfファイルは自分で書く必要があります。

```main.tf
provider "aws" {}
```

ここでは例として、リソースタイプ `aws_iam_role` で、Terraform上のリソース名 `test_kitchen_ec2_role` として、 AWS上のIAMロール名 `test-kitchen-ec2-role` をimportしてみましょう。

おもむろに、tfファイル側に定義がない状態でimportしようとすると、エラーが出ます。

```
$ terraform import aws_iam_role.test_kitchen_ec2_role test-kitchen-ec2-role
Error: resource address "aws_iam_role.test_kitchen_ec2_role" does not exist in the configuration.

Before importing this resource, please create its configuration in the root module. For example:

resource "aws_iam_role" "test_kitchen_ec2_role" {
  # (resource arguments)
}
```

以前はできたんですが、Stateだけ追加されてConfigurationがないと、うっかりdestroyのplanができちゃうので、安全にエラーになるようになったんでしょう。tfファイルにリソースの枠だけ作ってみます。

```main.tf
provider "aws" {}

resource "aws_iam_role" "test_kitchen_ec2_role" {
}
```

importしてみます。

```
$ terraform import aws_iam_role.test_kitchen_ec2_role test-kitchen-ec2-role
aws_iam_role.test_kitchen_ec2_role: Importing from ID "test-kitchen-ec2-role"...
aws_iam_role.test_kitchen_ec2_role: Import complete!
  Imported aws_iam_role (ID: test-kitchen-ec2-role)
aws_iam_role.test_kitchen_ec2_role: Refreshing state... (ID: test-kitchen-ec2-role)

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.
```

`terraform.tfstate` を見てみましょう。

```json
{
    "version": 3,
    "terraform_version": "0.11.1",
    "serial": 2,
    "lineage": "591a7666-d636-4e4f-aea8-8a9df641e460",
    "modules": [
        {
            "path": [
                "root"
            ],
            "outputs": {},
            "resources": {
                "aws_iam_role.test_kitchen_ec2_role": {
                    "type": "aws_iam_role",
                    "depends_on": [],
                    "primary": {
                        "id": "test-kitchen-ec2-role",
                        "attributes": {
                            "arn": "arn:aws:iam::XXXXXX:role/test-kitchen-ec2-role",
                            "assume_role_policy": "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Sid\":\"\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"ec2.amazonaws.com\"},\"Action\":\"sts:AssumeRole\"}]}",
                            "create_date": "2016-07-12T03:00:40Z",
                            "force_detach_policies": "false",
                            "id": "test-kitchen-ec2-role",
                            "name": "test-kitchen-ec2-role",
                            "path": "/",
                            "unique_id": "XXXXXXX"
                        },
                        "meta": {},
                        "tainted": false
                    },
                    "deposed": [],
                    "provider": "provider.aws"
                }
            },
            "depends_on": []
        }
    ]
}
```

`assume_role_policy` などが読み込まれていることが分かります。
planしてみます。

```
$ terraform plan

Error: aws_iam_role.test_kitchen_ec2_role: "assume_role_policy": required field is not set

```

assume_role_policyが必須項目だったのでエラーになりました。

assume_role_policyをtfファイル側に追加します。
Stateの値をそのままtfファイルにハードコードしてもよいんですが、改行なしのJSONは読み辛いので、適当にjqで整形して外ファイルを読み込むようにしておきましょう。

```
$ echo "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Sid\":\"\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"ec2.amazonaws.com\"},\"Action\":\"sts:AssumeRole\"}]}" \
| jq . > ec2_assume_role_policy.json
```

```ec2_assume_role_policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

```main.tf
provider "aws" {}

resource "aws_iam_role" "test_kitchen_ec2_role" {
  assume_role_policy = "${file("./ec2_assume_role_policy.json")}"
}
```

planします。

```
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

aws_iam_role.test_kitchen_ec2_role: Refreshing state... (ID: test-kitchen-ec2-role)

------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.
```

差分がなくなりました。このようにplan差分がなくなるまで、tfファイルの設定を調整します。

ところで残念なお知らせですが、この `terraform import` コマンドはすべてのリソースタイプに対応しているわけではありません。
対応していないリソースタイプの場合は、import実行するとエラーが出ます。

公式のimportコマンドが対応していないリソースタイプの場合は、自分でStateを書く必要があります。
しかし何もないところからおもむろにStateを書くのは、どのようなattributesがあるのか分からないので難しいです。実際には、以下のような流れで実施します。

- Terraformのドキュメントを眺めつつダミーのtfファイルを作る
- ダミーのリソースを `terraform apply` してtfstateの雛形作成
- AWSコンソールを眺めつつターゲットとなるリソースのtfファイルを作る
- tfstateの雛形をコピーしてターゲットとなるリソースのtfstateの枠を作る
- `terraform refresh` して terraformでtfstateを既存リソースの状態に合わせる
- ダミーリソースを削除して `terraform plan` で差分がなくなれば完成

Terraform v0.6時代に私が書いた資料で若干古いんですが、実際の例は以下の記事も参考にしてみて下さい。基本的な流れは変わりません。

[Terraforming未対応の既存リソースも自力でtfstateを書いてTerraform管理下に入れる](https://qiita.com/minamijoyo/items/e0f69bfa853bef60977e)

当時からの差分として注意すべきこととしては、StateをRemoteに保存している場合は、デフォルトでローカルに `terraform.tfstate` が保存されなくなりました。Stateを編集するには、 `terraform state pull` をファイルにリダイレクトして一旦ローカルに保存し、ファイルを編集、 `terraform state push` で上書きが必要です。

余談ですが、上記の記事で出て来る[terraforming](https://github.com/dtan4/terraforming)というツールは `terraform import` コマンドが公式にできる前からあった、サードパーティーなツールです。

## tfファイルをリファクタリングする
Terraformのコードは成長してくると、リファクタリングしたくなってきます。
リファクタリングしたくなる理由は様々ですが、リソース名の表記ゆれを揃えたくなったり、よく使うリソースのセットをmoduleに切り出したりなど。ここで問題になるのがtfstateをどうするかです。

簡単な例を見てみましょう。以下のような `null_resource.hoge` リソースがあるとして、

```main.tf
provider "null" {}

resource "null_resource" "hoge" {}
```

これを `null_resource.fuga` リソースにリネームしたいとします。

```main.tf
provider "null" {}

resource "null_resource" "fuga" {}
```

何も考えずにリネームしてしまうと、以下のように、 `null_resource.hoge` を一度削除して、`null_resource.fuga` を新しく作成するplanが生成されてしまいます。

```
$ terraform plan

Terraform will perform the following actions:

  + null_resource.fuga
      id: <computed>

  - null_resource.hoge


Plan: 1 to add, 0 to change, 1 to destroy.
```

再生成可能なリソースであればこれでも構わないのですが、実際問題DBなど作り直しづらいリソースも存在します。
こういう場合は `terraform state mv` コマンドを使います。
このコマンドはtfstate内のリソースの位置を移動しますが、このとき名前を変更すると同時にリネームもできます。

```
$ terraform state mv null_resource.hoge null_resource.fuga
Moved null_resource.hoge to null_resource.fuga
```

リネーム後に再度planしてみると差分がなくなりました。

```
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

null_resource.fuga: Refreshing state... (ID: 8190077603963424291)

------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.
```

# Terraformをデバッグする技術
## デバッグログを出力する
Terraformのバグを踏んだかな？と思ったらデバッグログを出力してみましょう。
`TF_LOG=DEBUG` を環境変数にセットするとデバッグログが出ます。ログレベルはTRACE, DEBUG, INFO, WARN, ERROR が指定可能です。

```
$ TF_LOG=DEBUG terraform init
2017/12/05 23:27:52 [INFO] Terraform version: 0.11.1  a42fdb08a43c7fabb8898fe8c286b793bbaa4835+CHANGES
2017/12/05 23:27:52 [INFO] Go runtime version: go1.9
2017/12/05 23:27:52 [INFO] CLI args: []string{"/usr/local/Cellar/tfenv/0.6.0/versions/0.11.1/terraform", "init"}
2017/12/05 23:27:52 [DEBUG] Attempting to open CLI config file: /Users/minamijoyo/.terraformrc
2017/12/05 23:27:52 [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2017/12/05 23:27:52 [INFO] CLI command args: []string{"init"}
2017/12/05 23:27:52 [DEBUG] plugin: waiting for all plugin processes to complete...
Terraform initialized in an empty directory!

The directory has no Terraform configuration files. You may begin working
with Terraform immediately by creating Terraform configuration files.
```

## Terraformのソースコードをコンパイルする
terraformコマンドは使うだけなら意識することはないですが、内部的にはマルチプロセスで動いています。内部構造もわりと複雑でデバッグログを出してもソースコードとの対応がぱっと見分かりづらいです。デバッグログを眺めつつソースコードを追うのに、ファイル名と行番号も出ると幸せになれそうです。
これには現状ソースコードをちょっといじる必要があります。
というわけでTerraformをソースコードからコンパイルしてみましょう。

TerraformはGo言語で書かれており、 `go get` してきて、コードをいじって、 `go install` しなおせば修正バージョンを手元で動かすことができます。Go言語の開発環境の構築は割愛します。適宜ググって下さい。
コンパイルに必要なGoのバージョンは `.travis.yml` あたりを見るとよいでしょう。現在はGo 1.9.1のようです。

```
$ go get github.com/hashicorp/terraform
$ cd $GOPAHT/src/github.com/hashicorp/terraform
(コードいじる)
$ go install
```

これはTerraform本体だけでなくproviderも同じです。普通に `$GOPATH/bin` にパスが通ってればproviderも検索対象に含まれ、自分でコンパイルしたバージョンを使用できます。

```
$ go get github.com/terraform-providers/terraform-provider-null
$ cd $GOPAHT/src/github.com/terraform-providers/terraform-provider-null
(コードいじる)
$ go install
```

## デバッグログにソースコードのファイル名と行番号を付ける
コンパイルの仕方がわかったところで、 デバッグログにソースコードのファイル名と行番号を付けてみましょう。
`hashicorp/terraform` の `main.go` の中にある main関数の先頭で、ログの設定をちょっといじってみます。

https://github.com/hashicorp/terraform/blob/8e57c4361c7981010a34b6cb866d91d188f3e91f/main.go#L32


```main.go
func main() {
	log.SetFlags(log.Llongfile) // ★この行を追加
	// Override global prefix set by go-dynect during init()
	log.SetPrefix("")
	os.Exit(realMain())
}
```

やってること自体は、Goの標準logパッケージの `log.Llongfile` をセットするだけです。
コンパイルして `$GOPATH/bin` 配下にバイナリをインストールします。

```
$ go install
```

実行してみましょう。

```
$ TF_LOG=DEBUG $GOPATH/bin/terraform init
/Users/minamijoyo/src/github.com/hashicorp/terraform/main.go:120: [INFO] Terraform version: 0.11.2 dev
/Users/minamijoyo/src/github.com/hashicorp/terraform/main.go:123: [INFO] Go runtime version: go1.9
/Users/minamijoyo/src/github.com/hashicorp/terraform/main.go:124: [INFO] CLI args: []string{"/Users/minamijoyo/bin/terraform", "init"}
/Users/minamijoyo/src/github.com/hashicorp/terraform/main.go:239: [DEBUG] Attempting to open CLI config file: /Users/minamijoyo/.terraformrc
/Users/minamijoyo/src/github.com/hashicorp/terraform/main.go:250: [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
/Users/minamijoyo/src/github.com/hashicorp/terraform/main.go:198: [INFO] CLI command args: []string{"init"}
/Users/minamijoyo/src/github.com/hashicorp/terraform/vendor/github.com/hashicorp/go-plugin/client.go:235: [DEBUG] plugin: waiting for all plugin processes to complete...
Terraform initialized in an empty directory!

The directory has no Terraform configuration files. You may begin working
with Terraform immediately by creating Terraform configuration files.
```

ログを出力している箇所のファイル名のフルパスと行番号が出るようになりました。これでコードリーディングが捗りそうです。

## Terraformをデバッガでステップ実行する
ログを眺めているとデバッガでステップ実行したくなりますよね。
Go言語には [delve](https://github.com/derekparker/delve) というデバッガがあるので、これを使います。
delve自体の使い方の説明は以前書いたことがあるので、こちらの記事も参考にしてみて下さい。

[Golangのデバッガdelveの使い方](https://qiita.com/minamijoyo/items/4da68467c1c5d94c8cd7)

ただterraformでdelveを使う場合注意すべきことがあります。それはterraformは内部的に複数のプロセスで構成されていることです。terraformはpanicをラップして綺麗なログを出すために内部的に `mitchellh/panicwrap` というライブラリを使って、自分自身を別のプロセスとして起動し直してます。コードを読めばわかりますが、 `TF_FORK=0` という環境変数をセットすると、この動作を回避して直接プロセスを起動できます。
delveでデバッグするときは、デバッグ対象のコマンドに渡す引数は `--` 以降に記載します。
なので、 `terraform init` を動かす場合は、こんなかんじ。

```
$ TF_LOG=TRACE TF_FORK=0 dlv debug -- init
Type 'help' for list of commands.
(dlv) b main.main
Breakpoint 1 set at 0x27b28af for main.main() ./main.go:32
(dlv) c
> main.main() ./main.go:32 (hits goroutine(1):1 total:1) (PC: 0x27b28af)
    27: const (
    28:         // EnvCLI is the environment variable name to set additional CLI args.
    29:         EnvCLI = "TF_CLI_ARGS"
    30: )
    31:
=>  32: func main() {
    33:         log.SetFlags(log.Llongfile) // ★この行を追加
    34:         // Override global prefix set by go-dynect during init()
    35:         log.SetPrefix("")
    36:         os.Exit(realMain())
    37: }
```

ところでterraformのメインプロセスと、providerのプロセスは分かれており、内部的にRPCでプロセス間通信を行っています。
このprovider側のプロセスにdelveをアタッチする方法はまだ編み出せていません。delveにはリモートプロセスにアタッチする機能もあるのですが、providerはデーモンのように常時起動しているわけではなく、terraformのコマンドが実行されている間だけ起動しているので、タイミングを見計らってアタッチするのも難しそうです。

現状provider側のコードをデバッグするには、適当なログ出力を仕込む、いわゆるprintデバッグ以上の有効な技を知らないので、誰かもっといいprovider側のデバッグ方法を知ってる人がいたら教えて下さい。

---
(2019/06/27追記)
providerのプロセスはterraformのコアから起動されるのでdelveで起動したバイナリを差し込むの難しそうだなーって思ってたんですけど、issue漁ってたらproviderをデバッグするのacceptance testをdlv testで起動すりゃいいよって情報を見つけて、なるほどーって思って試したらできました。
https://github.com/go-delve/delve/issues/496#issuecomment-413049532

```
$ TF_ACC=1 dlv test ./aws -- -test.v -test.run=TestAccAWSIAMRole_basic
```

# おわりに
Terraformを使っていて日々学んだ知見を淡々とまとめてみました。
「だいたい知ってたわー」、「あるある過ぎてツライw」、「こんな超絶技巧テクニックも知ってるよー」
というTerraform職人の皆様は、ぜひ知見を共有して下さい。

(2020/12/11追記)
情報が古くなっちゃった感が否めないので、3年ぶりに続編書いた。こちらもどうぞ↓
[Terraform職人再入門2020](https://qiita.com/minamijoyo/items/3a7467f70d145ac03324)