February 5, 2020

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さんから


さて、本題

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

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


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

対策


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


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

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

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

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にしたい場合はどうすれば良いか

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

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

さいごに

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

(C) Jun Kitamura 2020

Powered by Hugo & Kiss.