GCP 公開の Terraform modules から module による効果的な抽象化を学ぶ

Terraform はずっとほぼ AWS でしか使っていなくて、最近 GCP で使い始めたところ結構使い勝手が違って驚いている。その中でも公式提供されている Terraform modules がかなり良くて、 GCP 使わない人でも参考になるので紹介してみる。

Terraform modules for Google Cloud

上記 GitHub Organization にて、現時点で 64 の module が公開されている。 Organization のメンバーを見ると GCP に属している方が多いので、どうも Google 公認で提供されているものらしい。 AWS にも Terraform AWS modules という Organization があるが、こちらは見る限り AWS 関係者ではなく有志による提供となっている。昨今のアレじゃないけど、 Google のほうが OSS コミュニティと良い関係を築こうという意思が見て取れるなぁという気がしなくもない。

公開されている module はいろいろあるが、一例として IAM に関して見てみる。 GCP の IAM に関する Terraform resources は Google: google_project_iam - Terraform by HashiCorp で触れられている通り、何種類かのものが存在するのだが、ざっくり以下2種類に気を付ける必要がある。

GCP ではあらかじめ複数の権限が割り当てられた Role というものが存在し（ AWS のマネージドポリシーみたいなものと考えればいいかもしれない）、これとメンバーを紐つけて権限の割り当てを行う。前者の member は1対1対応しか作れないので、ある Role に複数のメンバーを結びつけたい場合（が大半だと思うが）はちょっと不便だ。しかし一方で binding はある Role と紐付く すべての メンバーを管理する。そのため Terraform を apply する前に、すでに Role と紐ついたメンバーがいて、 Terraform 内ではそのメンバーを宣言していなかった場合、 apply 時に除外されてしまうことになるので注意が必要となる。

という、それぞれ一長一短ある resource をうまいこと使い分けなくてはならないのだが、 GCP が module で解決策を提示してくれている。 terraform-google-iam/modules/projects_iam at master · terraform-google-modules/terraform-google-iam からサンプルを引用する。

 1module "project-iam-bindings" {
 2  source   = "terraform-google-modules/iam/google//modules/projects_iam"
 3  projects = ["my-project_one", "my-project_two"]
 4  mode     = "additive"
 5
 6  bindings = {
 7    "roles/compute.networkAdmin" = [
 8      "serviceAccount:my-sa@my-project.iam.gserviceaccount.com",
 9      "group:my-group@my-org.com",
10      "user:my-user@my-org.com",
11    ]
12    "roles/appengine.appAdmin" = [
13      "serviceAccount:my-sa@my-project.iam.gserviceaccount.com",
14      "group:my-group@my-org.com",
15      "user:my-user@my-org.com",
16    ]
17  }
18}

2つの resource の使い分けを気にする必要はなく、 bindings 変数に role と members の1対多のリストを渡せばいいだけ。既存の紐付きを置き換える ( authoritative ) のか、既存のものは触らず新たな紐付きを追加する ( additive ) のかは mode 変数で指定ができ、さらにデフォルトは安全側に倒れて additive となっている。だいぶ使いやすく抽象化されていると言っていい。

抽象化のロジックを見てみる。呼び出している module 自体はわりと簡素な内容になっている。というのも、見ればわかるのだが、ロジック部分を helper という別の module に飛ばしているからだ。ここではほぼ resource 作成だけが行われている。

 1module "helper" {
 2  source   = "../helper"
 3  bindings = var.bindings
 4  mode     = var.mode
 5  entity   = var.project
 6  entities = var.projects
 7}
 8
 9resource "google_project_iam_binding" "project_iam_authoritative" {
10  for_each = module.helper.set_authoritative
11  project  = module.helper.bindings_authoritative[each.key].name
12  role     = module.helper.bindings_authoritative[each.key].role
13  members  = module.helper.bindings_authoritative[each.key].members
14}
15
16resource "google_project_iam_member" "project_iam_additive" {
17  for_each = module.helper.set_additive
18  project  = module.helper.bindings_additive[each.key].name
19  role     = module.helper.bindings_additive[each.key].role
20  member   = module.helper.bindings_additive[each.key].member
21}

使っている resource は、やはり先程見た iam_binding と iam_member の2つだ。それぞれ for_each が使われていることから、変数 bindings で指定された role と members と project あたりをいい感じに list に変換して、選択された mode に応じて module.helper.set_authoritative か module.helper.set_additive に代入しているのだろうと想像がつく。代入されていないほうの変数は空のリストになるので、 resource の作成は行われない。

実際に helper を覗いてみると、確かにそのようなロジックになっている。 module.helper.set_authoritative について追ってみる。

1  set_authoritative = (
2    local.authoritative
3    ? toset(local.keys_authoritative)
4    : []
5  )

local.authoritative による三項演算子だ。 local.authoritative は先の mode が authoritative だった場合にのみ値が代入されるようになっており、 やはり authoritative を指定した場合に限り、 set_authoritative にリストが代入されているとわかる。そして代入される値は、 keys_authoritative を set に変換したものとなっている。では keys_authoritative とは何か。

1  keys_authoritative = distinct(flatten([
2    for alias in local.aliased_entities
3    : [
4      for role in keys(var.bindings)
5      : "${alias}--${role}"
6    ]
7  ]))

local.aliased_entities は project のリストと思ってよい。二重ループになっているため少しわかりづらいが、各 project ごとに bindings から keys, すなわち role の値を取り出し、 project 名と繋げた文字列の配列を作っている。前述したサンプルのように、 projects と role をそれぞれ2つずつ指定している場合であれば、 2 × 2 で長さ4の配列が作られることになるわけだ。 helper の別のところでは、この4つの project - role それぞれに紐つけるべきメンバーのリストが生成されている。最終的に for_each のループによって、これらを組み合わせて iam_binding が生成されている。

ここではざっくりと GCP Terraform modules の中身を見てみたが、これ以外にも非常に多くの Terraform functions を上手く使って抽象化を試みている。コメントも多く盛り込まれていて読みやすいので、各 functions はどういう場面でどのように活用できるのか、とても参考になる。

Conclusion

Terraform provider はその仕組み上、各クラウドサービスの API サービスをそのまま愚直に変換したものであり、 API の仕様を把握していなければ上手く扱えないこともある。しかし我々が欲しているのはクラウドリソースのコード化という点のみであり、 API の仕様を細部まで常に気にしなくてはならない、という状況は歓迎したくない。 GCP の modules はそういった低レイヤーな知識がなくとも、簡潔な記載でクラウドリソースを使えるようにしてくれているものが多い。 Terraform modules を作るとき、単に組織内でのデフォルト値を埋め込んでいるだけ、のような使い方になってしまうことも少なくないと思うが、 GCP のそれは「抽象化」という観点で module を作る上で、大きなヒントになりそう。

Appendix: GCP with Terraform 所感

おまけで、 Terraform で GCP を扱うときに、 AWS を扱うときとこのへんが感覚違うなーと思う点をいくつか。