前回の heroku の import の続き。

まとめ

• Terraforming は本当にすごい。超簡単。.tfstate だけでなく .tf も出力できるし、IAM の KEY さえあれば特に何も書かなくてよい。
• 逆に terraform import はなかなか大変。（詳細は前回のterraform import heroku_appはできたけど…使い方が悩ましい参照。）import はまだおまけ的な感じで、terraform が正しく動作するために .tf を書き、これを validate すると required な option がボロボロ出てくる。
• 対応サービスの数は Terraform の方が多いが、ものによっては Terraforming でしか対応できていなかったりするので、しばらくは両方知っておくのがよさそう。
• AWS Certificate Manager は承認のプロセスが挟まるので完全自動にはできないんだなぁ
• AWS S3 の Bucket の Policy は使い方別に整理した方がよさげ

Terraforming by dtan4

ちなみに似たツールとして terraformer というものがあったが、これは terraforming の fork でかつ実運用もしていない、対応 provider も少ないものだった。

S3 + CloudFrontで配信する静的サイトが複数あるものとする

すると必要なものは

1. S3 ( aws_s3_bucket )
2. IAM Policy ( aws_iam_policy_document ) / IAM User Policy
3. CloudFront ( aws_cloudfront_distribution )
4. ACM ( AWS Certificate Manager )

いったん Log および Metrics は置いておく（CloudWatch とか）。また、ACM については承認プロセスの関係上、素直な方法では自動化できないので除外とする。というわけで 1 から 3 について試してみた。

aws_s3_bucket

特に難しいことはなかった。

resource "aws_s3_bucket" <bucket_name> {
  bucket = <bucket_name>
}

こんな感じで bucket_name で統一して、

terraform import aws_s3_bucket.<name> <bucket_name>

ちなみに

terraforming s3

にすると何も考えずに権限のある S3 の情報が全部ぶっこぬけます。めっちゃ楽。

AWS: aws_s3_bucket - Terraform by HashiCorp

aws_cloudfront_distribution

これはいろいろ required な attribute があって面倒くさかった。何がつらいって terraforming が対応していないこと。どうにか調べて試して動くようにしなければいけない。結局 Terraform の Provider と Resource の情報は自分で調べられないといけない。

resource "aws_cloudfront_distribution" <distribution_cname> {
  default_cache_behavior {
    allowed_methods  = []
    cached_methods   = []
    forwarded_values = []
    default_ttl      = 0
    min_ttl          = 0
    max_ttl          = 0
    target_origin_id = ""
    viewer_protocol_policy = ""
  }
  viewer_certificate {}
  enabled = ""
  origin {
    domain_name = ""
    origin_id   = ""
  }
  restrictions {
    geo_restriction {
      restriction_type = ""
    }
  }

  (logging_config)
}

として

terraform import cloudfront_distribution.<distribution_cname> <distribution_id>

みたいな感じ。import は

terraform import TYPE.NAME ID

が基本だが、NAME として理解しやすいのは Distribution ID ではなく CNAME の方なのではないかと思う。CNAME を指定していないなら Distribution ID でよいと思う。

AWS: cloudfront_distribution - Terraform by HashiCorp

aws_iam_user

これは簡単。

resource "aws_iam_user" <user_name> {
  user_name = <user_name>
}

で

terraform import aws_iam_user.<user_name> <user_name>

AWS: aws_iam_user - Terraform by HashiCorp

aws_iam_user_policy

今度は terraform v 0.11.1 が 2017-12-26 時点では import に対応していなかったので terraforming で。

terraforming iamup

やってみて気づいたこと

IAM Policy の適用ポリシー (言ってみたかっただけ :-) が揺れている。

これについては後日。

まぁ、これまで WebUI であっちこっちに行くことでよく分からなくなっていた、立ち止まるのが面倒で放置していたこういう状況の俯瞰のためにも terraform import あるいは terraforming は使えるってことだなーと思った。

参考

• TerraformでAWS S3バケットを操作 - Qiita
• sjevs/terraform-static-website-s3-cloudfront: Terraform template to create static website on AWS S3 & Cloudfront based on variables
• ringods/terraform-website-s3-cloudfront-route53: Terraform scripts to setup an S3 based static website, with a CloudFront distribution and the required Route53 entries.
• S3 + CloudFront + Aws Certificate Manager + Route53 + Middleman + terraformを使ってHTTPS対応した静的Webを100円/月で構築する - Qiita