LoginSignup
157
121

More than 5 years have passed since last update.

Infrastructure as Codeを少し楽にするterraformerが出た

Last updated at Posted at 2019-06-08

過去に Terraform Best Practices in 2017 という記事を書きました。

そのあと、2019年2月のJAWS Days Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理するを話しました。

その中で、Dev環境を手で作業して、その内容をExportして、Stg, Prodに展開出来たら良いのになー。という話をしていたのですが、それの兆しが見えるツールが登場したので紹介します。

terraformer

2019年5月頭にひっそりと terraformer という何かと間違えるようなツールが出ていました。
少し驚いたのが、提供元がGoogleCloudPlatformでした。

CLI tool to generate tf and tfstate files from existing infrastructure (reverse Terraform).

既存の環境を確認してtfファイルとtfstateファイルを出力してくれるとな。
しかも、GoogleCloudPlatformが出しているだけあってGCPが中心だけど、AWSやKubernetes、Github、Datadogまで同じように出力可能だと。公開1ヶ月で1,000スター超え。中々なお手前で。
ちなみに、まだ公開1ヶ月程度なので対象となるリソースはそこまで多くない。けど1ヶ月にしては十分なリソースをサポートしている。

やってみた

1. インストール

# Terraform入れてない人は
$ brew install terraform

# ここからterraformer
$ git clone https://github.com/GoogleCloudPlatform/terraformer.git
$ cd terraformer
$ GO111MODULE=on go mod vendor
$ go build -v
$ echo 'provider "aws" {}' > init.tf
$ terraform init

2. サンプル通りにVPCとSubnetを出力

注)SwitchRoleはまだ対応していません。IAMユーザを利用ください。
対象が多い場合は少し時間がかかります。

$ terraformer import aws --resources=vpc,subnet --connect=true --regions=eu-west-1
2019/06/08 14:11:45 aws importing region eu-west-1
2019/06/08 14:11:45 aws importing... vpc
2019/06/08 14:12:04 aws importing... subnet
2019/06/08 14:12:12 aws Connecting....
2019/06/08 14:12:12 aws save vpc
2019/06/08 14:12:12 [DEBUG] New state was assigned lineage "24ce6300-2fa2-48cc-ec79-0e85f0b06293"
2019/06/08 14:12:12 aws save tfstate for vpc
2019/06/08 14:12:12 aws save subnet
2019/06/08 14:12:12 [DEBUG] New state was assigned lineage "271b76a2-eb11-73e8-d834-f69de988381e"
2019/06/08 14:12:12 aws save tfstate for subnet

3. 中身を確認

こんな感じのディレクトリなんだけれども、 generated ってディレクトリにtfファイル等が作成されるみたいです。

$ ls -l
total 214976
-rw-r--r--   1 shogo.muranushi  staff        302  6  6 15:17 AUTHORS
-rw-r--r--   1 shogo.muranushi  staff       3210  6  6 15:17 CODE_OF_CONDUCT.md
-rw-r--r--   1 shogo.muranushi  staff       1100  6  6 15:17 CONTRIBUTING.md
-rw-r--r--   1 shogo.muranushi  staff      11357  6  6 15:17 LICENSE
-rw-r--r--   1 shogo.muranushi  staff      15473  6  6 15:17 README.md
drwxr-xr-x  11 shogo.muranushi  staff        352  6  6 15:17 cmd
drwxr-xr-x   3 shogo.muranushi  staff         96  6  6 15:17 docs
drwxr-xr-x   3 shogo.muranushi  staff         96  6  8 14:12 generated
-rw-r--r--   1 shogo.muranushi  staff       5726  6  6 15:17 go.mod
-rw-r--r--   1 shogo.muranushi  staff      58248  6  6 15:17 go.sum
-rw-r--r--   1 shogo.muranushi  staff         18  6  6 15:25 init.tf
-rw-r--r--   1 shogo.muranushi  staff        783  6  6 15:17 main.go
drwxr-xr-x   8 shogo.muranushi  staff        256  6  6 15:17 providers
drwxr-xr-x  12 shogo.muranushi  staff        384  6  6 15:17 terraform_utils
-rwxr-xr-x   1 shogo.muranushi  staff  102264716  6  6 15:22 terraformer
drwxr-xr-x   7 shogo.muranushi  staff        224  6  6 15:17 tests
drwxr-xr-x  10 shogo.muranushi  staff        320  6  6 15:18 vendor

面白いのが、aws/subnet/eu-west-1 単体で terraform plan とかできるように provider.tf とか生成されているんですよね。

$ tree generated
generated
└── aws
    ├── subnet
    │   └── eu-west-1
    │       ├── outputs.tf
    │       ├── provider.tf
    │       ├── subnet.tf
    │       ├── terraform.tfstate
    │       └── variables.tf
    └── vpc
        └── eu-west-1
            ├── outputs.tf
            ├── provider.tf
            ├── terraform.tfstate
            └── vpc.tf

さらに、subnetの中を見ると、vpc_idはちゃんと aws/vpc/eu-west-1/outputs.tfを参照するようになっている。賢い。

$ cat generated/aws/subnet/eu-west-1/subnet.tf
resource "aws_subnet" "subnet-93463df7" {
  assign_ipv6_address_on_creation = false
  cidr_block                      = "172.31.0.0/20"
  map_public_ip_on_launch         = true
  tags                            {}
  vpc_id                          = "${data.terraform_remote_state.vpc.aws_vpc_vpc-0d593d69_id}"
}

resource "aws_subnet" "subnet-ceddabb8" {
  assign_ipv6_address_on_creation = false
  cidr_block                      = "172.31.16.0/20"
  map_public_ip_on_launch         = true
  tags                            {}
  vpc_id                          = "${data.terraform_remote_state.vpc.aws_vpc_vpc-0d593d69_id}"
}

resource "aws_subnet" "subnet-de4acf86" {
  assign_ipv6_address_on_creation = false
  cidr_block                      = "172.31.32.0/20"
  map_public_ip_on_launch         = true
  tags                            {}
  vpc_id                          = "${data.terraform_remote_state.vpc.aws_vpc_vpc-0d593d69_id}"
}

なるほど。これはExportとしては優秀だ。以前からあった terraforming はここまでやってくれなかったような。

こんな感じで各リソースと連動してExportしてくれると、ハードコードもなくなるし書かなくてよくなるな(そんなん出来るんかいな)。と思いつつ、他のリソースを取得してみた。

4. Route53のレコードとALBは連動してくれるのか

Route53でALBとドメインを紐付けることも多いと思います。ALBが変わったらRoute53のレコードを自動で更新するような事もあると思います。
上のように data リソースで参照すると自動更新はできるのですが、ハードコードだとできません。
果たしてハードコードなのか、 data リソースなのか。

$ terraformer import aws --resources=route53,alb --connect=true --regions=us-west-2
2019/06/08 14:26:45 aws importing region us-west-2
2019/06/08 14:26:45 aws importing... route53
2019/06/08 14:27:13 aws importing... alb
2019/06/08 14:27:47 aws Connecting....
2019/06/08 14:27:47 aws save alb
2019/06/08 14:27:48 [DEBUG] New state was assigned lineage "f8158b24-0428-83ff-e206-18fda16fff3a"
2019/06/08 14:27:48 aws save tfstate for alb
2019/06/08 14:27:48 aws save route53
2019/06/08 14:27:48 [DEBUG] New state was assigned lineage "a5815164-aba8-639e-396f-4629b26d2adc"
2019/06/08 14:27:48 aws save tfstate for route53

さて、 Route53 のレコードの値は data リソースなのか、ハードコードなのか

$ cat generated/aws/route53/us-west-2/route53_record.tf
resource "aws_route53_record" "ZZZZZZZZZZZZZZ_api--test--dev--abeja--test--_A" {
  alias {
    evaluate_target_health = false
    name                   = "internal-xxx-internal-alb-123456789.us-west-2.elb.amazonaws.com"
    zone_id                = "ZXXXXXXXXXXXXX"
  }

  name    = "api.test.dev.abeja.test"
  type    = "A"
  zone_id = "${aws_route53_zone.ZZZZZZZZZZZZZZ_dev--abeja--test.zone_id}"
}

残念でした。ALBの値はハードコードでした。ただ、 Route53 内の zone_id はリソース指定で参照してますね。ということは、ただ値を出力するだけのツールではなさそう。
これから連動する部分が増えてくると使い回しやすくなるので嬉しい。

terraformerのまとめ

Exporterとしてはかなり優秀。GCPやKubernetes、Github、Datadogもあるしね

以下のユースケースの際に Infrastructure as Code を維持しようとするとかなりしんどいんですよね。

  • 手作業で作った割と大きくなった既存環境をコード化する
  • コード化を維持して頑張ってるんだけど、誰かがたまに手作業をしてしまったので整合取る必要がある

特に前者の場合は、既存の環境をそのままコード化できるので、かなり入り口としては低くなった印象です。

で、Dev環境を手で作業して、その内容をExportして、Stg, Prodに展開出来たら良いのになー。は実現出来るのか?

現時点では全てを実施するには 厳しい

というのも、上の例で行くと ALB の接続先はハードコードなので、そのままstg環境に plan/apply してもdevの接続先に向くので意味ありません。

また、s3バケットも出力できましたが、s3バケット名はグローバルでユニークである必要があるため、ハードコードされたコードを実行しても重複エラーが出ます。

つまり、グローバルでユニークな値が存在するサービス(URLやS3バケット名など)に関してはまだ難しい状態です。

ただし、ものによっては実現可能

ただし、VPC や Subnet などグローバルで一意の値が必要ないものに関しては、簡単に流用できました。

# Dev 環境の VPC, Subnet を Export
$ terraformer import aws --resources=vpc,subnet --connect=true --regions=eu-west-1
# IAM を Stg 環境に変更
$ terraform init
$ terraform plan
$ terraform apply

でも、SecurityGroupのように VPC ID を指定するようなものも、Dev環境のVPC IDがハードコードされたりして、たぶんダメだと思う。ものによる。

どのようになれば実現可能か

1. VPCとSubnetのように サービス間で data リソースで受け渡しが実現される

  • Route53 は ALB の outputs.tf の ALB DNSレコードを参照する(ハードコードじゃない)
  • Security Group は VPC の outputs.tf の vpc_id を参照する
  • そうすることで、dev, stg, prod環境のvpc_id違いなどを吸収する

2. グローバルで固定になりそうな値(S3バケット名など)はvariable.tfに書き込まれる

  • (そんなこと出来たら良いなと思いつつ)workspace名(dev,stg)などと一緒にvariableの値が生成される

上の二つが実現できると、夢が広がる

そうなると reverse Terraform どころか、automate creation Terraform じゃん。
terraformer がリソース間連携を少し実装してくれてるし、みんなでコミットすれば良い感じのところまでいけそう。

よし、Golang勉強しよう。

157
121
3

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
  3. You can use dark theme
What you can do with signing up
157
121