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

Ac6dba8ce93944d17714de362ca17e54?s=47 muryoimpl
March 16, 2019

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

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

Ac6dba8ce93944d17714de362ca17e54?s=128

muryoimpl

March 16, 2019
Tweet

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. 消耗せずに楽しくさくっと 環境構築していきましょう