Terraform活用事例 / Terraform Use Cases

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyright © OPTiM Corp. All Right Reserved. 2  名前: Yabata  担当: AI・IoTプラットフォーム「OPTiM Cloud IoT OS（CIOS）」の運用作業 • KubernetesへのAPI/Appのリリース • Terraformを使った構成変更 • etc  興味のある技術分野 • Container Orchestration • Infrastructure as Code • Policy as Code 自己紹介

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Copyright © OPTiM Corp. All Right Reserved. 5  Infrastructureをコードで管理するツール • Infrastructure as Code  管理可能なInfrastructureの例 • low-level components • compute instances • storage • network • high-level components • DNS entries • SaaS • etc Terraformの概要

Slide 6

Slide 6 text

Copyright © OPTiM Corp. All Right Reserved. 6  HCLを使用して、ファイルにInfrastructureを定義 • HCL = HashiCorp Configuration Language  TerraformのCLIで以下の作業実施 • 定義ファイルの読み取り • 実行プランを確認 • 設定内容に間違いがないか確認し、適用 Terraformの実行の流れ https://www.terraform.io/

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Copyright © OPTiM Corp. All Right Reserved. 9  安全かつ効率的にInfrastructureを構築、変更、version管理可能 • provisioningの自動化 • 手動で設定した場合と比べて、設定時間が少なくなる • 類似している複数のInfrastructureを簡潔なコードで管理可能 • 手動で設定した場合と比べて、設定ミスが少なくなる • 設定変更前にファイルのPR/MRや実行プランで設定内容のreviewが可能 • 変更点が明確になり、設定ミスを事前に気づきやすくなる • ファイルをversion管理することで設定変更の履歴が確認可能 • 問題発生時に原因調査がしやすくなる Terraformを使用する利点

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Copyright © OPTiM Corp. All Right Reserved. 11  DNS recordの管理にmeta argumentのcountを使用していた • countは指定の数の分だけリソースを複数構築する  管理対象のDNS recordを一部削除する際に意図しない再作成処理が発生する場合がある  for_eachを使用して、再作成が発生しないコードに変更複数リソースの管理で意図しない再作成処理の発生

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Copyright © OPTiM Corp. All Right Reserved. 14 resource name DNS record a_records[0] foo.example.com a_records[1] bar.example.com a_records[2] baz.example.com countの挙動 resource name DNS record a_records[0] foo.example.com a_records[1] (delete) bar.example.com (delete) a_records[2] => a_records[1] baz.example.com (new) bar.example.comを削除すると添字が詰められて、baz.example.comが再作成される

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyright © OPTiM Corp. All Right Reserved. 16 resource name DNS record a_records["foo"] foo.example.com a_records["bar"] bar.example.com a_records["baz"] baz.example.com for_eachの挙動 resource name DNS record a_records["foo"] foo.example.com a_records["bar"] (delete) bar.example.com (delete) a_records["baz"] baz.example.com bar.example.comを削除した場合でもbaz.example.comは再作成されない

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Copyright © OPTiM Corp. All Right Reserved. 18  チームとして知見を共有する場所がなく、作業効率が悪かった • 管理方法: ディレクトリ分割/module/workspace/multiple provider • backend: local/s3/remote • CIの設定ファイル  exampleリポジトリを作成し、知見を共有する形にした作成者によってTerraformのファイルの書き方がバラバラ

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Copyright © OPTiM Corp. All Right Reserved. 20  環境差分の吸収方法 • tfvars (変数を集めたファイル)  実行方法 • 実行コマンドはMakefileに記載 • 環境名をmakeコマンドに渡して実行 • GitLab CIを使ってGitOps  レビュー方法 • tfnotifyで通知されたterraform planの結果を参考にレビュー • 以下の実行結果が問題ないかレビュー • terraform fmt • terraform validate • tflint exampleリポジトリに記載されている内容

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Copyright © OPTiM Corp. All Right Reserved. 24  moduleの活用 • 構成を再利用できる機能 • 冗長なコードを減らすため、より使用頻度を増やしたい  terratestの導入 • terraform apply後に動作確認するためのterraformのテストツール • 動作確認のミスや作業時間を減らすため、導入したい  conftestの導入 • Policy as Codeのツール • terraform planする前に設定内容に問題ないか確認するツール • セキュリティ上問題のある設定の検知や高額なインスタンス構築によるクラウド破産回避のため、導入したい今後取り組みたいこと(予定)

Slide 25

Slide 25 text