Slide 1

Slide 1 text

Copyright © OPTiM Corp. All Right Reserved. 1 Terraform活用事例

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

Copyright © OPTiM Corp. All Right Reserved. 3  Terraformとは  過去に発生した問題とその解決  今後取り組みたいこと(予定) 目次

Slide 4

Slide 4 text

Copyright © OPTiM Corp. All Right Reserved. 4 Copyright © OPTiM Corp. All Right Reserved. Terraformとは

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

Copyright © OPTiM Corp. All Right Reserved. 7 HCLの例 https://www.terraform.io/

Slide 8

Slide 8 text

Copyright © OPTiM Corp. All Right Reserved. 8 Terraform CLIの実行 https://www.terraform.io/

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

Copyright © OPTiM Corp. All Right Reserved. 10 Copyright © OPTiM Corp. All Right Reserved. 過去に発生した問題とその解決 サブタイトルの補足

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

Copyright © OPTiM Corp. All Right Reserved. 12 countの例

Slide 13

Slide 13 text

Copyright © OPTiM Corp. All Right Reserved. 13 実行例

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

Copyright © OPTiM Corp. All Right Reserved. 15 for_eachの例

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

Copyright © OPTiM Corp. All Right Reserved. 17  Terraformのドキュメントによると以下の形で使い分けが必要 • 管理対象のリソースがほぼ同一の場合、countを使用する • 引数の一部に整数から導出できない個別の値が必要な場合、for_eachを使用する countとfor_eachの使い分け

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

Copyright © OPTiM Corp. All Right Reserved. 19 exampleリポジトリのディレクトリ構成

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

Copyright © OPTiM Corp. All Right Reserved. 21  管理対象のリソースが多いリポジトリで実行速度低下  --parallelism optionを使って、並列数を変更 • default値: 10 • 変更後の値: 100 terraform planの実行速度低下

Slide 22

Slide 22 text

Copyright © OPTiM Corp. All Right Reserved. 22 --parallelism optionの速度比較

Slide 23

Slide 23 text

Copyright © OPTiM Corp. All Right Reserved. 23  管理対象がSaaS、かつ並列数が多すぎる場合、注意が必要  SaaSのAPI limitに引っかかることがある --parallelism optionの注意

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

Copyright © OPTiM Corp. All Right Reserved. 25