Terraform meetup tokyo#4

今回は、Terraform meetup tokyo#4に参加してきました。 いつものスタイルと違ったので、ちょっと戸惑いました。。。

アジェンダ

• 会社紹介
• スポンサーセッション
• ワールド・カフェに関して

会社紹介

• 「これからの食卓・これからの〇〇」
• Oisix + らでぃっしゅぼーや + 大地を守る会
  • オイシックス・ラ・大地
  • Purple Carrot
• ミールキット「Kit Oisix」が人気です。
• エンジニアの会場は誰でも借りれます！
• エンジニアは内製している。
• Kubernetes, Terraform etc…使ってます。

誰でも借りれるって行っていたので、機会があれば、是非使いたい！が、ちょっと大崎というのが個人的にはアクセスがあまり。。。笑

スポンサーセッション

ワールド・カフェに関して

下記スライド参照。
https://docs.google.com/presentation/d/1mjuzsWV2Pl8barIM9ZG1xVao6AeTP93U5p7PgR0wQlo/edit#slide=id.p

Hashicorp Japan さんから

• Hashicorp 「Japan」でも、GitHub を持ってます。 https://github.com/hashicorp-japan
• Vault の紹介
  • アプリが必要な時に、Vault 側で DB の credentials とかを generate できる。
  • TTL が設定されるので、テンポラリーな credentials にできる。 https://github.com/hashicorp-japan/vault-workshop
• こんなスライドもあるのかと思った。 https://docs.google.com/presentation/d/14YmrOLYirdWbDg5AwhuIEqJSrYoroQUQ8ETd6qwxe6M/edit

さて、本題

以下、「その場で上がっていた課題感」とその「対策」に関して、ざっくりまとめてみました。

その場で上がっていた課題感

• ワークスペース利用するかどうか
• どうディレクトリを切ったらいいのか
• 本番適用するのはどこから適用するか
  • 手動か？CI/CD サービスなどのツールからか？
• terraform の OSS に PR を出したいが、リポジトリが大きくて、どこから手を出していいかわからない
• terraform の artifact を他のツール（ansible etc…）とかの input にしたい場合はどうすれば良いか

対策

ワークスペース利用するかどうか

結論としては、「使わなくていいんじゃない？」って人が多かったように思う。理由としては

• 分けることのメリットがあまりない。
• hashicorp 側でも「環境毎にワークスペースを分けて~」「環境毎に分けないで~」など、公式の best practice がバラバラ？

２つ目の理由に関しては、公式ドキュメントにある通り、複数ワークスペースを利用する場合は、例えば「本番環境をデプロイする前に、同等の環境のコピーを用意する場合に利用する」と記載されているため、そうではない場合は、ワークスペースではなく、そもそも別のものとして分けるのが良いを私は信じたい。

In particular, organizations commonly want to create a strong separation
between multiple deployments of the same infrastructure serving different
development stages (e.g. staging vs. production) or different internal teams.
In this case, the backend used for each deployment often belongs to that deployment,
with different credentials and access controls.
Named workspaces are not a suitable isolation mechanism for this scenario.

c.f. https://www.terraform.io/docs/state/workspaces.html#when-to-use-multiple-workspaces

どうディレクトリを切ったらいいのか

これは、結局「サービスレイヤー」と「環境レイヤー」のどっちを上に置くべきかという話がメインの課題だったように感じた。これに関しては、その場でも明確な結論は出ていなかったように思う。理由としては、おそらくシステムアーキテクチャ・組織構造（e.g. マイクロサービスかどうか。どの単位でチームが構成されているか）と密接に絡むため、どっちがいいとかがなかったからかと思う。個人的には、最近の潮流を鑑みると mercari さんの構成が良きかなと思っている。ただ terraform 導入フェーズから完璧にこの構成にする必要はないと思っているため、色々なフェーズに合わせて、構成は柔軟に変更したらいいかなと思う。

ベースとなる構成は、ここのサイトが参考になるかなと思う。 https://www.terraform-best-practices.com/examples/terraform

本番適用するのはどこから適用するか

この課題は、「証跡・履歴」と「アクセスコントロール」の話。基本的には、CircleCI とか Jenkins とかとかから実行するのがベストかと思われる。これに関しては、特に異論はなかったように思う。

terraform の OSS に PR を出したいが、リポジトリが大きくて、どこから手を出していいかわからない

これは、OSS の活動をしたことがないので、困った。笑
https://github.com/hashicorp/terraform
確かに、大きそうには見えるが、完全に何がしたいか次第かなと思ったりもした。根本のところの修正をしようとすると確かに、キャッチアップが必要かもしれないが、↓ の PR のように、puppet の provisioner を追加するだけなら、まぁなんかいけなくもないかなと感じた。笑（PR にめっちゃ突っ込んでくれて、suggest を出してくれて、直してくれてる雰囲気を感じた笑）

https://github.com/hashicorp/terraform/pull/18851

terraform の artifact を他のツール（ansible etc…）とかの input にしたい場合はどうすれば良いか

これは私がちょこちょこ聞いていた質問だが、回答としては、

• AWS なら、EC2 の tag を使うことで、間接的に、連携できる。
• AWS の parameter store を利用する。 https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/services-parameter-store.html
• null resource 使って、local file として吐き出す。

1 つ目に関しては、よくやる手かなと思った。
2 つ目に関しては、AWS ならではという感じですが、なるほど。
3 つ目に関しては、あまり使う機会も少ないですが、null resource x provisioner（local-exec）の組み合わせをすればいいという話。resource が単位で provisioner を設定するのがオーソドックスかもしれないが、null resource を使えば、まとめて実行できそうですし、ファイルを吐き出すだけじゃなくても、local-exec で script を実行すれば、まぁ確かに、なんでもできそう。あまりやらないので、今度そういう機会があれば、やってみようと思った。

c.f. https://www.terraform.io/docs/providers/null/resource.html#example-usage

さいごに

今回は、「ワールドカフェ」という自分の中では、新しいスタイルでした。就活のグループディスカッションを思い出しました。笑