これはなに？

Terraformを使ってリソースをimportしてから、リソースを削除し、再びplan / applyで同じように作れるかのテストの際に、気がついたあたりを書き出します。
完全に個人メモ用です。
（WIPで随時更新）

補足情報

# 20190810時点
$ terraform -v
Terraform v0.12.6
+ provider.aws v2.23.0

planで通ってもapplyの段階でNGになるもの

S3

bucket name

bucket nameのユニークさ
- URLとしてユニークになる必要がある
- Ref. https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/BucketRestrictions.html
- バケット作成の設定を書いてterraform planしたところでは、バケット名のユニークさまではチェックされなかった
- applyしたら「その名前は使われてます！」と怒られてエラーに

注意点

TerraformのtfstateをS3上で管理するため、バケットを以下のように指定
ありがちな my-terraform-state-storage といった名前にすると、planした際にバケット名（アクセスできるエンドポイント）がユニークにならないとエラーが発生してしまう
仮装ホスト形式
- http://{自分のバケット名}.s3.amazonaws.com/ になる
- 考えてみると、バケット名をexample...とかtest...とした場合、重複する可能性は高い
リージョン指定で作成しリージョンごとのエンドポイントの形式でもアクセスできるけれど、やっぱり http://{自分のバケット名}.s3.amazonaws.com/ としてのユニークさが必要

設定例


terraform {
  required_version = ">= 0.11.7"

  # backendでは変数を利用できないので、先にバケットとテーブルを作成しておき固定値を入れる
  backend "s3” {
    # bucketに注意！！
    bucket         = "my-terraform-state-storage"
    key            = "terraform.tfstate"
    region         = "ap-northeast-1"
    dynamodb_table = "terraform-state-lock"
  }
}

※サンプルのソースコードなどの設定をそのまま使ってしまったりすると、詰むことがあります...。

ALB (Application Load Balancer)

subnet

ALBを作成する際には、異なるアベイラビリティゾーンに所属する2つ以上のサブネットを指定しないといけない
- Ref. https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/create-application-load-balancer.html
- VPC から少なくとも 2 つのアベイラビリティーゾーンを選択します。のあたり。
- planの段階では subnets = [] （ブランク）でもOKが出てしまう

設定例

Jenkinsを立てるのでその前にALBを配置したいという例で
- ターゲットグループやリスナーは別に設定なので、resource: aws_alb のみ抜粋


resource "aws_alb" "jenkins-alb" {
  name               = "jenkins-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = ["${aws_security_group.allow-tls.id}", "${aws_security_group.allow-http.id}”]

  # subnets指定なので2つ以上必要
  # subnets = [ ] でブランクでは作成できない
  subnets = [
    "${aws_subnet.terraform-sample-subnet-1d.id}",
    "${aws_subnet.terraform-sample-subnet-1c.id}"
  ]

  enable_deletion_protection = false

  access_logs {
    bucket = "${aws_s3_bucket.jenkins-alb_logs.bucket}"
    enabled = true
  }

  tags = {
    Environment = "production"
  }
}

そもそも権限が足りない

rootアカウントや、rootアカウントの代替用として作った強いアカウントではなく、ある程度の権限を与えたアカウントで作業する方針にしている場合、planの際にどうしても権限エラーで失敗してしまうことがあります。

感想など（時々追加するかも）

自動でも手動（コンソール）でもどちらも同じですが、明確に1リソースに対しての処理を行うのではなく、複数の依存するリソースを更新・削除といったことをする場合、1箇所でエラーが発生すると、「何が残っていて何が消えたのか」がわかりにくくなります。
(これはAWSに限らず）

最初のうちや、無料枠で試している際は、便利なウィザードを使って一式試している場合などに、消し忘れで課金が発生...ということもあるかもしれません。

なるべく綺麗な環境で作る -> 壊すことで確認が大事とは実感しています。

そういう意味で、自動で構成する場合はタグ付けといった措置で、ある程度把握できるのかなとは思いますが、なかなかそこまでわたしは頭が回りません。

Terraformのメモ（awsのリソース設定でうっかりしてたあたり）[WIP]