Slide 1

Slide 1 text

私が Terraform を使うポイント HashiCorp Terraform & Vault Enterprise 勉強会 in 金沢 2019年03月16日(土) 無量井 健 from Kanazawa.rb

Slide 2

Slide 2 text

Contents ● 自己紹介 ● Terraform 利用者としての私の立ち位置 ● Terraform を選んだポイント ● Terraform を使うときに私が意識しているポイント

Slide 3

Slide 3 text

自己紹介 ● name: 無量井 健 a.k.a @muryoimpl ● 2018年8月から金沢に戻ってきたリモートワーカー ● 3.times { muryoimpl.participate_in ‘Kanazawa.rb’ } ● Terraform はお仕事で使ったり、個人開発で使ってみたり しています

Slide 4

Slide 4 text

Terraform 利用者としての私の立ち位置 ● ※あくまで個人の意見/感想です ● Terraform 利用歴は1年くらい ● AWS に環境を作る際に使っている ● インフラ構築を専門に扱っている人ではない ● 中小規模の環境を作ることがほとんど

Slide 5

Slide 5 text

を選んだポイント

Slide 6

Slide 6 text

Terraform を選んだポイント 1. 即時実行されず、実行前に差分がわかる 2. 作ったものは簡単に壊せる 3. 比較的読みやすい DSL とドキュメントがある 4. Terraform の不得意なところを許容できた

Slide 7

Slide 7 text

私が Terraform を 選んだポイント `terraform apply` を入力したとしても、必ず差分を 表示して実行していいか確認してくれる。 ※即実行してくれ!っていう人もいそう 私はこれに救われている… - あの設定忘れてた!を流す前に気づく - 焦って無駄打ち|削除!が減った - ここが変わるってわかる安心感 - 定義のリファクタリングに便利←ポイント 1. 即時実行されず、実行前に 差分がわかる 2. 作ったものは簡単に壊せる 3. 比較的読みやすいDSLとド キュメントがある 4. Terraform の不得意なとこ ろを許容できた

Slide 8

Slide 8 text

私が Terraform を 選んだポイント `terraform destroy` するだけで作ったものが削除 できる。 以下は必要ない! - 消す際の定義変更 or 消すタスクの追加 - 削除の手間を惜しんで飛んでいくお金 - 中途半端に残った設定を運用中の設定から削 除する苦痛を味わわなくて済む 1. 即時実行されず、実行前に 差分がわかる 2. 作ったものは簡単に壊せる 3. 比較的読みやすいDSLとド キュメントがある 4. Terraform の不得意なとこ ろを許容できた

Slide 9

Slide 9 text

私が Terraform を 選んだポイント DSL - JSON程ごちゃごちゃでなく、YAMLほどindent や配列の記法に気を使わなくてもいい - formatter が付属していて整形できる terraform fmt コマンド - resource.name.attribute でアクセスできるの が好き 例) aws_instance.bastion.id ドキュメント - 設定値に説明がある - 割と設定例が載ってる - フォント小さいけどそのおかげで遷移、スクロー ルが少ない 1. 即時実行されず、実行前に 差分がわかる 2. 作ったものは簡単に壊せる 3. 比較的読みやすいDSLとド キュメントがある 4. Terraform の不得意なとこ ろを許容できた

Slide 10

Slide 10 text

私が 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 の不得意なとこ ろを許容できた

Slide 11

Slide 11 text

ここまで: Terraform を選んだポイント 1. 即時実行されず、実行前に差分がわかる 2. 作ったものは簡単に壊せる 3. 比較的読みやすい DSL とドキュメントがある 4. Terraform の不得意なところを許容できた 便利に使わせていただいております

Slide 12

Slide 12 text

を使うときに 私が意識するポイント

Slide 13

Slide 13 text

Data Source, Random provider を活用する Data Source は名前等の情報から既存リソースの情報を取得できる。 Random はパスワード等の自動生成に利用できる。 - resource の情報をvariable として持たなくてもよい - 少ない手間で定義上にもたなければならない秘匿情報も減らせる Vault や AWS System Manager Parameter Store 用 Data Sourceもある ので、秘匿情報をそちらに登録しておいて参照、ということも可能。

Slide 14

Slide 14 text

汎用性、再利用を必要になるまで考えない やりたいことは “今必要な環境を作る”ことなので 無理にmodule作らない、不 要なoptionalな属性を変数にして消耗しない - 環境は対象によって異なる == 再利用が難しい、のが現実 - まず今必要な環境のためだけの定義を書く - 必要になるまで module は使わない - module の定義は override できるけど、override で “module の設定を 潰す” が入ってくると途端に読みにくくなる - 論理的な分割はファイルとディレクトリで行う

Slide 15

Slide 15 text

消したい単位でディレクトリ分割する `terraform destroy` は有効活用したいの で、一緒に消せない、消したくないものは 独立させる。 - backend 用の S3 buckt - ネットワーク作り直したいけど、ECR の docker image は消したくない etc ※これは実験的にmoduleを  使ったものなので  module使てるやん!の  ツッコミはナシでお願いします

Slide 16

Slide 16 text

ここまで: Terraform を使うときに意識するポイント 1. Data Source, Random provider を活用する 2. 汎用性、再利用を必要になるまで考えない 3. 消したい単位でディレクトリ分割する

Slide 17

Slide 17 text

消耗せずに楽しくさくっと 環境構築していきましょう