LoginSignup
1

More than 3 years have passed since last update.

posted at

updated at

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

これはなに?

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のユニークさ

注意点

  • 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

設定例

  • 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に限らず)

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

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

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

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
1