私がTerraformを使うポイント/The point I use Terraform

2019/03/16(土) に開催された HashiCorp Terraform & Vault Enterprise 勉強会 in 金沢 での発表です。

Transcript

1. 私が Terraform を使うポイント HashiCorp Terraform & Vault Enterprise 勉強会 in 金沢 2019年03月16日(土) 無量井 健 from Kanazawa.rb
2. Contents • 自己紹介 • Terraform 利用者としての私の立ち位置 • Terraform を選んだポイント • Terraform を使うときに私が意識しているポイント
3. 自己紹介 • name: 無量井 健 a.k.a @muryoimpl • 2018年8月から金沢に戻ってきたリモートワーカー • 3.times { muryoimpl.participate_in ‘Kanazawa.rb’ } • Terraform はお仕事で使ったり、個人開発で使ってみたり しています
4. Terraform 利用者としての私の立ち位置 • ※あくまで個人の意見/感想です • Terraform 利用歴は1年くらい • AWS に環境を作る際に使っている • インフラ構築を専門に扱っている人ではない • 中小規模の環境を作ることがほとんど
5. を選んだポイント
6. Terraform を選んだポイント 1. 即時実行されず、実行前に差分がわかる 2. 作ったものは簡単に壊せる 3. 比較的読みやすい DSL とドキュメントがある 4. Terraform の不得意なところを許容できた
7. 私が Terraform を 選んだポイント `terraform apply` を入力したとしても、必ず差分を 表示して実行していいか確認してくれる。 ※即実行してくれ！っていう人もいそう 私はこれに救われている… - あの設定忘れてた！を流す前に気づく - 焦って無駄打ち|削除！が減った - ここが変わるってわかる安心感 - 定義のリファクタリングに便利←ポイント 1. 即時実行されず、実行前に 差分がわかる 2. 作ったものは簡単に壊せる 3. 比較的読みやすいDSLとド キュメントがある 4. Terraform の不得意なとこ ろを許容できた
8. 私が Terraform を 選んだポイント `terraform destroy` するだけで作ったものが削除 できる。 以下は必要ない！ - 消す際の定義変更 or 消すタスクの追加 - 削除の手間を惜しんで飛んでいくお金 - 中途半端に残った設定を運用中の設定から削 除する苦痛を味わわなくて済む 1. 即時実行されず、実行前に 差分がわかる 2. 作ったものは簡単に壊せる 3. 比較的読みやすいDSLとド キュメントがある 4. Terraform の不得意なとこ ろを許容できた
9. 私が Terraform を 選んだポイント DSL - JSON程ごちゃごちゃでなく、YAMLほどindent や配列の記法に気を使わなくてもいい - formatter が付属していて整形できる terraform fmt コマンド - resource.name.attribute でアクセスできるの が好き 例) aws_instance.bastion.id ドキュメント - 設定値に説明がある - 割と設定例が載ってる - フォント小さいけどそのおかげで遷移、スクロー ルが少ない 1. 即時実行されず、実行前に 差分がわかる 2. 作ったものは簡単に壊せる 3. 比較的読みやすいDSLとド キュメントがある 4. Terraform の不得意なとこ ろを許容できた
10. 私が Terraform を 選んだポイント Ansible にあるような “--tags” で部分適用する - 差分判断して適用してくれるから不要 - ディレクトリをわけることで設定の塊ごとに実行 できるようにして回避できる アプリを deploy する - Terraform は “Define infrastructure as code to increase operator productivity and transparency.” != deploy tool と割り切った - deploy は別のツールを使う 例) ecs-deploy ちょっととっつきにくい 繰り返し expression - count と element と index の組み合わせ… - 数が少ない場合は無理に繰り返さない、慣れる - 0.12で for … in, for_each が入るかも 1. 即時実行されず、実行前に 差分がわかる 2. 作ったものは簡単に壊せる 3. 比較的読みやすいDSLとド キュメントがある 4. Terraform の不得意なとこ ろを許容できた
11. ここまで: Terraform を選んだポイント 1. 即時実行されず、実行前に差分がわかる 2. 作ったものは簡単に壊せる 3. 比較的読みやすい DSL とドキュメントがある 4. Terraform の不得意なところを許容できた 便利に使わせていただいております
12. を使うときに 私が意識するポイント
13. Data Source, Random provider を活用する Data Source は名前等の情報から既存リソースの情報を取得できる。 Random はパスワード等の自動生成に利用できる。 - resource の情報をvariable として持たなくてもよい - 少ない手間で定義上にもたなければならない秘匿情報も減らせる Vault や AWS System Manager Parameter Store 用 Data Sourceもある ので、秘匿情報をそちらに登録しておいて参照、ということも可能。
14. 汎用性、再利用を必要になるまで考えない やりたいことは “今必要な環境を作る”ことなので 無理にmodule作らない、不 要なoptionalな属性を変数にして消耗しない - 環境は対象によって異なる == 再利用が難しい、のが現実 - まず今必要な環境のためだけの定義を書く - 必要になるまで module は使わない - module の定義は override できるけど、override で “module の設定を 潰す” が入ってくると途端に読みにくくなる - 論理的な分割はファイルとディレクトリで行う
15. 消したい単位でディレクトリ分割する `terraform destroy` は有効活用したいの で、一緒に消せない、消したくないものは 独立させる。 - backend 用の S3 buckt - ネットワーク作り直したいけど、ECR の docker image は消したくない etc ※これは実験的にmoduleを 　使ったものなので 　module使てるやん！の 　ﾂｯｺﾐはﾅｼでお願いします
16. ここまで: Terraform を使うときに意識するポイント 1. Data Source, Random provider を活用する 2. 汎用性、再利用を必要になるまで考えない 3. 消したい単位でディレクトリ分割する
17. 消耗せずに楽しくさくっと 環境構築していきましょう