Slide 1
Slide 1 text
Terraform による運用効率化の取り
組みと最新のテストアプローチの紹介
テクノロジー戦略室 SRE チーム
中野竜之介
Slide 2
Slide 2 text
【目次】
1. 自己紹介、発表概要
2. これまでの運用効率化の取り組み
3. Terraform でのテストアプローチ
4. Policy as Code を用いた設定検証
5. 今後の展望
6. 参考情報
Slide 3
Slide 3 text
1 自己紹介、発表概要
Slide 4
Slide 4 text
● 名前：中野竜之介 (33歳)
● 所属：テクノロジー戦略室 SRE チーム
● 出身：三重県伊勢市
● 趣味：温泉、自然散策・登山、鉄道等
● 経歴：
○ 2017年4月 〜 2022年6月
■ HR ビッグデータ事業、 IT ソリューション事業の会社に新卒入社
○ 2022年6月 〜 2025年2月
■ レバレジーズに中途入社し、テク戦 SRE チームに所属して活動
プロフィール
Slide 5
Slide 5 text
【ミッション】
SRE 化を通して、 Developer Experience の改善、事業拡大への対応、お客様に信
頼されるサービスの提供を実現する
【ゴール】
● リソース最適配置を最大限配慮したシステム設計がされており、定期的に見直しや改善を
行う体制になっている
● 事業部毎にユーザー視点に立った SLO が設定され、SLO の達成のために合理的に動け
る様な仕組みが整っている
● ベストプラクティスが社内全体で水平展開出来ている
● システム課題を持続的に改善する文化が根付いている
テク戦 SRE のミッション・ゴール
Slide 6
Slide 6 text
【理想】
SLI / SLO の運用体制の構築を通して、開発生産性の向上、顧客 (社内外) に信頼さ
れるサービスの提供、事業拡大への対応を実現する
【目標】
事業部の開発組織に Product SRE を導入し、 SRE の教育・運用の体制構築を実施
し、Embedded SRE が自然と SLI/SLO の導入・運用を実施出来る様にする
テク戦 SRE の中長期の理想・ 目標
Slide 7
Slide 7 text
社内の今後の目指すべき SRE 体制
● Evangelist SRE Role
○ テク戦 SRE メンバーのことを指す
○ 全社を横断し、運用効率化のツール・仕組みの提供、ノウハウの提供・吸い上げ、アー
キテクチャー相談等を実施する
● Product SRE Role
○ 事業部の開発組織を横断する SRE メンバーのことを指す
○ 開発組織内の SRE 化の支援・浸透や運用効率化の推進等を実施する
● Embedded SRE Role
○ サービス開発チームに所属の SRE メンバーのことを指す
○ SRE プラクティスを適用したり、サービスインフラの構築・運用等を実施する
Slide 8
Slide 8 text
社内の今後の目指すべき SRE 体制
Slide 9
Slide 9 text
本セッションでお話すること
● 全社へのナレッジ・ノウハウの展開を考え、主に次をお話します
○ テク戦 SRE による、これまでの運用効率化に関する動き
○ 現在のインフラ設定のテストにおける考え方・実施方法等
● 発表時間を踏まえ、基本知識・詳細・周辺事項等には触れません
○ セッション内容について、ざっくりと理解頂ければ幸いです
○ 参考情報を共有しておきますので、良ければご確認ください
Slide 10
Slide 10 text
2 これまでの運用
効率化の取り組み
Slide 11
Slide 11 text
● サービス運用の効率化を進めるため、まずはインフラ・監視基盤の IaC
化による整備を推進し、管理・運用の省力化を進めていた
● 実際には開発チームにより IaC ツールの選定にバラツキがあり、開発
チームとテク戦 SRE の双方で次の様な課題感が顕在化し始めた
○ ツールの理解度や習熟度がバラついているため、開発チーム間でのナレッ
ジやノウハウの共有が困難である
○ 開発チームの採用技術、理解度や習熟度に合わせてインフラ・監視基盤の
整備を支援するため、負荷が高い
従来の運用における課題感・打ち手
Slide 12
Slide 12 text
従来の運用における課題感・打ち手
Slide 13
Slide 13 text
● 開発チームのインフラ・監視基盤の整備や、テク戦 SRE からの整備支
援を低工数・低負荷で進めるには、次の取り組みが必要だと考えた
○ 社内標準となる IaC ツールの選定
■ Terraform、OpenTofu、AWS CDK、CDKTF、Pulumi から検討
○ IaC 関連のライブラリ・テンプレートの作成
■ 社内のインフラ標準構成に基づく Terraform Modules の開発
■ Terraform CI/CD 向けの GitHub Composite Actions の開発
■ Terraform のコード管理用の GitHub Repository Template の開発
従来の運用における課題感・打ち手
Slide 14
Slide 14 text
● IaC ツールの認知度・利用度の高さを考え、次を選択肢とした
○ Terraform、OpenTofu、AWS CDK、CDKTF、Pulumi
● 社内状況に適した IaC ツールを選定するために、次を優先条件とした
○ なるべく幅広いサービスで同一ツールが利用可能である
○ ライブラリ・モジュール等で同一パターンを容易に適用可能にする仕組みを持っている
○ ツールにおける学習コストが高くない
● 次の観点で比較評価を行い、 Terraform・OpenTofu が高評価だった
○ 成熟度・カバー範囲、ツールの学習負荷、構築・変更の負荷、状態変更の容易性、
Gen AI との相性
社内標準としての IaC ツールの選定：比較評価
Slide 15
Slide 15 text
社内標準としての IaC ツールの選定：比較評価
比較観点 評価理由
成熟度・カバー範囲
殆どのパブリッククラウドやその他の SaaS におけるプロバイダーが利用可能
で、関連するコミュニティ、知識・知見、ツール等が充実している。
ツールの学習負荷 HCL は JSON ライクで学習しやすく、設定が宣言的で見通しが良い。
構築・変更の負荷
設定が宣言的であるため、クラウドサービスの作成・更新・削除において、コード
変更とズレの無い状態差分で期待通りに適用することが出来る。
状態変更の容易性
専用のブロック設定 (import / moved / removed blocks) を用いて、状態のイン
ポート、変更、除外の操作をコードベースで容易に実施出来る。
Gen AI との相性
宣言的でシンプルな設定が大半なため、変数設定の手直しは必要だが、簡単な
プロンプトで一定以上のクオリティでサンプルコードを生成出来る。
Slide 16
Slide 16 text
● 比較評価だけでなく、ツールの将来的なリスクも考える必要があり、主にライセ
ンス変更による Terraform の利用制限について調査した
● 通常の利用においては概ね従来通りで利用可能であり、利用制限に関するリス
クは見られなかった
○ 社内・個人による HashiCorp 製品の利用においては、利用制限は無い
○ HashiCorp 製品を埋め込んでいる競合製品が提供されている場合、この様な競合製
品は Terraform のライセンスに抵触する (例：Terratest)
● 今後の HashiCorp クラウドサービスとのシームレスな連携・統合の検討可能性
も踏まえ、 OpenTofu ではなく Terraform の方が良いと考えた
社内標準としての IaC ツールの選定：リスク調査
Slide 17
Slide 17 text
● 比較評価やリスク調査の結果、 Terraform を社内標準なツールとして採
用し、Terraform で IaC 化を推進していくことになった
● Terraform の導入・移行における費用対効果が必ずしも高くは無いパ
ターンも考えられるため、導入・移行の例外事項を規定した
○ Terraform へのツール移行
○ Terraform によるサポートが弱い部分への IaC 化
○ 外部サービスの仕組みにおける Terraform の導入
○ 一時的な利用のシステムへの Terraform の導入
社内標準としての IaC ツールの選定： 検討結果
Slide 18
Slide 18 text
社内標準としての IaC ツールの選定： 例外事項
例外パターン 対応方針
Terraform へのツール移行
他ツールで管理下のパブリッククラウドや SaaS では、移行コストと改善
効果性のバランスを考え、 Terraform への移行を検討する。
Terraform によるサポート
が弱い部分への IaC 化
Terraform へのサポートが未対応、またはサポート範囲が狭い部分では
他ツールの利用を認める。
外部サービスの仕組みにお
ける Terraform の導入
パブリッククラウドや SaaS で提供される仕組みにおいて、 Terraform 以
外の手段で構築されている場合は、その手段の利用を認める。
一時的な利用のシステムへ
の Terraform の導入
プロトタイプや実験的な環境等の、一時的な利用が確実に見込まれる様
なシステムでは、 Terraform による IaC 化は強制しない。
Slide 19
Slide 19 text
● 開発チームやテク戦 SRE のサポートメンバーにヒアリングすると、 IaC
化における下記の課題感が明らかになった
○ 実装の際にクラウドサービスの仕様把握が必要で、実装負荷が高い
○ 宣言的な設定のためシンプルで分かりやすいが、リソースが多くなると設定
管理における認知負荷が高まる
○ CI/CD やコード管理の標準構成が無く、設計や構築で時間がかかる
● これらを解決するには、社内の標準構成に基づいたライブラリ・テンプ
レートが必要だと考え、これらを開発することになった
IaC 化の推進における課題感・打ち手
Slide 20
Slide 20 text
ライブラリ・テンプレートの開発： Terraform Modules
● 全社最適のパターンを考え、次のモジュール構成方針を考え出した
○ (1) 個別最適の手段を組み合わせることで、全社最適を図る
■ 社内のサービス・システムに合わせたモジュール
○ (2) 個々に依存せず全社をカバーする形で、全社最適を図る
■ クラウドサービスのリソースに対応するモジュール
● 主に利用負荷、メンテナンス性、拡張性、汎用性から 案 (2) を採用した
● 当時のモジュール構成管理の推奨事項や社内の既存ライブラリの設計思想を
参考に、負荷軽減も考慮して 2種類のモジュール を開発した
Slide 21
Slide 21 text
ライブラリ・テンプレートの開発： Terraform Modules
モジュール構成方針 方針の評価内容
社内のサービス・システムに
合わせたモジュール
サービス・システム毎に特化したモジュールのため、極力少ない設定でイ
ンフラの構築・運用が可能である。
しかし、各々の構成変更に追従してメンテナンスする必要があり、メンテ
ナンス面で大きな課題が見られた。
クラウドサービスのリソース
に対応するモジュール
サービス・システムの個別の設定・構成に依存せずに全社に展開出来る
ため、メンテナンス面の課題は小さい。
社内要件やクラウドサービスにより推奨される設定・構成をベースに作り
込めば、インフラ構築・運用の作業負荷を軽減可能だと考えた。
Slide 22
Slide 22 text
ライブラリ・テンプレートの開発： Terraform Modules
モジュールの種類 モジュールの概要
Component Modules
クラウドサービスの単体リソースに対応する様なモジュール。
例えば、ELB・ECS・EC2・RDS 等のリソース毎に、対応するモジュー
ルで管理する。
Catalog Modules
クラウドサービスの複数リソースに対応する様なモジュール。
例えば、ELB・ECS、CloudFront・WAF 等のリソース群をモジュール
でまとめて管理する。
Slide 23
Slide 23 text
ライブラリ ・テンプレート の開発：GitHub Composite Actions
● 下記の理由で GitHub Actions を採用しており、この処理共通化に関する開発
を行うことになった
○ 社内における CI/CD サービスの利用状況
○ CI/CD サービスの GitHub 向け連携機能の充実さ
● 主に3種類の共通化の方法があり、処理共通化のパターンやコード管理の方針
をもとに、 案 (2) を採用することにした
○ (1) GitHub Custom Actions
○ (2) GitHub Composite Actions
○ (3) GitHub Reusable Actions
Slide 24
Slide 24 text
ライブラリ・テンプレートの開発： GitHub Composite Actions
● 以下は、ライブラリ・テンプレートのコード管理の前提・方針である
○ テク戦、開発チームの GitHub Organization は別々である
○ ライブラリ・テンプレートの管理元の GitHub Repository は、テク戦の GitHub
Organization の配下で管理されている
○ ライブラリ・テンプレート用の、開発チーム用の GitHub Repository の可視性は
Internal or Private である
● テク戦推奨の Terraform CI/CD の構成をもとに GitHub Composite Actions
を作り、Terraform CI/CD の処理共通化・テンプレート作成を行った
Slide 25
Slide 25 text
ライブラリ・ テンプレートの開発： GitHub Repository Template
● 社内で AWS が多く利用されているため、優先的に AWS・Terraform に関する
GitHub Repository Template を優先して作成した
● テク戦推奨の Terraform のコード管理構成をもとに、 Template のファイルや
ディレクトリの構成雛形を考えた
● スクリプトで Template を一気に書き換え、コード・資料の情報を利用者に合わ
せた情報に変更出来る様にした
● 更に、Template に AWS・Terraform に関する初期設定・構築作業等の手順・
雛形も含めて提供している
Slide 26
Slide 26 text
ライブラリ・テンプレートの開発： GitHub Repository Template
● Terraform 向け Repository の作成だけでなく、以下の作業も簡単になる
○ Slack への通知に関する初期設定
■ 通知チャンネルの作成、 Webhook 連携の設定
○ Terraform 関連の初期設定・構築
■ Terraform Backend の構築
■ CI/CD 用の IAM リソースの作成
■ CI/CD の設定作成・有効化
○ AWS サービスの初期設定・構築
■ 月額予算アラートの作成
■ 監査ログやセキュリティの検知・検出リソースの作成
■ 監視アラートの通知基盤に関するリソースの作成
Slide 27
Slide 27 text
3 Terraform での
テストアプローチ
Slide 28
Slide 28 text
従来・現在のテストの実施方法
● 従来はテスト用のツール・機能が充実しておらず、モジュール毎にサンプルコー
ドを用意し、下記を用いて構築検証を行っていた
○ サンドボックス用の AWS アカウント
○ LocalStack 等の擬似的な専用の環境
● 構築後は、コマンドやプログラムでネットワーク疎通やシステム環境のコンポー
ネント間連携等を検証し、リソースを破棄していた
● 現在はチェック・テストに関するツール・機能が充実してきており、先述の手動で
の検証プロセスが概ね自動で実施可能になっている
Slide 29
Slide 29 text
従来・現在のテストの実施方法
テストの種類 ツール・機能の例
静的解析 TFLint、Terraform CLI、Terraform Custom Conditions
セキュリティチェック Trivy、Checkov、Synk、Terrascan
コンプライアンスチェック terraform-compliance
ポリシーチェック Open Policy Agent、Conftest、Hashicorp Sentinel
単体・結合テスト Terratest、Terraform Testing Framework
サーバテスト InSpec、Serverspec、Goss
Slide 30
Slide 30 text
従来・現在のテストの実施方法
テストの種類 ツール・機能の例
静的解析 TFLint、Terraform CLI、Terraform Custom Conditions
セキュリティチェック Trivy、Checkov、Synk、Terrascan
コンプライアンスチェック terraform-compliance
ポリシーチェック (PaC) Open Policy Agent、Conftest、Hashicorp Sentinel
単体・結合テスト Terratest、Terraform Testing Framework
サーバテスト InSpec、Serverspec、Goss
Slide 31
Slide 31 text
Terraform Custom Conditions
● ここでは、 Terraform のテスト・バリデーションに焦点を当て、下記の機
能について概説したい
○ Terraform Custom Conditions
■ Input Variable Varidation
■ Preconditions・Postconditions
○ Terraform Testing Framework
※ Custom Conditions の Checks with Assertion は、ここでは触れない
※ Policy as Code の概要・主要なツール等は、次のセクションで紹介する
Slide 32
Slide 32 text
Custom Conditions：Input Variable Validations
● Terraform v0.13 から、Input Variables で Validation Block という変数設定
のバリデーション機能が追加された
● variable block 内に validation block を宣言し、バリデーションの条件とエラー
メッセージをそれぞれ condition・error_message で設定する
Slide 33
Slide 33 text
Custom Conditions：Input Variable Validations
● Input Variable Validations による設定検証は、 plan の処理時に実行される
● condition が false となれば、 error_message が出力され、異常終了する
● 複数の validation block の設定は可能で、少なくとも 1つの block で検証エ
ラーが発生すれば異常終了する
Slide 34
Slide 34 text
Custom Conditions：Input Variable Validations
● 従来は、condition では validation block の設定先の Input Variable と、組み
込み関数の組み合わせでしか設定出来なかった
● v1.9 のリリースでこの制約が解消され、他の Input Variable や Data Source
等も condition で参照可能になった
● 後述の Preconditions と遜色無いレベルになったが、基本的には変数のバリ
デーションに留める形で実装すると良さそう
● ルートモジュールでは Local Values を用いることが多いため、基本的には再利
用可能モジュールで仕込むと良さそう
Slide 35
Slide 35 text
Custom Conditions：Preconditions・Postconditions
● Terraform v1.2 から Preconditions・Postconditions という、Resource、
Data Source、Outputs の設定検証の機能が追加された
Slide 36
Slide 36 text
Custom Conditions：Preconditions・Postconditions
● lifecycle block 内で precondition block や postcondition block を設定する
ことにより、これらの機能を利用することが出来る
Slide 37
Slide 37 text
Custom Conditions：Preconditions・Postconditions
● Preconditions による設定検証は plan の処理時に、 Postconditions による
設定検証は apply の処理時にそれぞれ実行される
Slide 38
Slide 38 text
Custom Conditions：Preconditions・Postconditions
● Terraform のコード設定のチェックでは Preconditions を、リソースの構築後に
想定通りになっているか確認する場合は Postconditions を利用する
Slide 39
Slide 39 text
Terraform Testing Framework：概要・ディレクトリ構成
● Terraform v1.6 から、Testing Framework というモ
ジュールテストを実施する機能が追加された
● ルートモジュール配下に tests フォルダを作り、そこで
tftest.hcl 拡張子のファイルを作成する
● その後、Terraform CLI の test コマンドをルートモ
ジュール直下で実行し、テストを実施出来る
○ デフォルトでは、ルートモジュール 直 下 、またはそのサ
ブディレクトリの tests でファイルが探索される
○ ファイルの格納場所を指定する場合は、 test コマンドの
test-directory オプションを実行の際に利用する
Slide 40
Slide 40 text
Terraform Testing Framework：テスト処理の基本設定
● テスト処理の設定は、 tftest.hcl ファイルで run block を用いて宣言する
● 主要な引数は command・assert 、これらの設定方法は下記の通りである
○ command には、plan / apply を指定しテストの実行フェーズを設定する
○ assert block には、Custom Conditions と同様で condition・error_message を設定する
Slide 41
Slide 41 text
Terraform Testing Framework：テスト処理の実行順序
● test コマンドを実行すると、次の通りでテスト処理が実行される
○ 格納場所から tftest.hcl ファイルのパス一覧を取得する
○ 名前のアルファベット順に、 tftest.hcl ファイル毎にテストを実施する
■ tftest.hcl ファイル内では、 run block をファイル上部から順番に実行する
■ run block の実行後、この逆順でリソースのクリーンアップを実行する
■ テスト・クリーンアップが完了すると、ファイル内の処理実行は完了する
○ 各 tftest.hcl ファイルにおける処理が完了すると、テストは終了する
Slide 42
Slide 42 text
Terraform Testing Framework：State の管理方法
● テスト用の State が次の様に生成され、メモリで管理・破棄される
○ テストの設定ファイル毎に、 State が生成される
○ run block の設定に関する State は、次の通りで生成される
■ モジュールを参照する run block の設定は、専用の State として生成される
■ モジュールを参照しない run block の設定は、設定ファイルの State に統合され
る
■ 同一モジュールを参照する run block が複数存在する場合は、同一の専用の
State に統合される
○ クリーンアップでは、テストの逆順で State の破棄が実施される
■ ある設定に対応する State が破棄済みの場合は、破棄がスキップされる
Slide 43
Slide 43 text
Terraform Testing Framework：Mocks の概要・利用方法
● Terraform v1.7 から、Mocks というテスト関連の機能が追加された
● この機能で、全体的または部分的にモックオブジェクトを利用出来る
● モジュールの外部依存な部分を Mocks でモック化し、 API の呼び出し
やプロバイダー認証を極力無くす形でテスト出来る
● つまり、本来のソフトウェアの単体テストに近い形で、モジュールの機能
を高速・正確にテスト出来る様になったのである
Slide 44
Slide 44 text
Terraform Testing Framework：全体的なモック化
● mock_provider block により、
Provider、Resource、Data
Source のモック化が出来る
● モック化された Provider とそうで
ないものを使い分けたい場合は
alias を利用すれば良い
Slide 45
Slide 45 text
Terraform Testing Framework：全体的なモック化
● mock_resource、mock_data
で、Resource、Data Source の
モックオブジェクトの属性値を指
定出来る
● 例えば、右の実装例の様に設定
すると、S3 のモックオブジェクトの
ARN を指定出来る
Slide 46
Slide 46 text
Terraform Testing Framework：全体的なモック化
● mock_resource、mock_data
は別のファイルに切り出せる
● 右の実装例の様に、 tfmock.hcl
の拡張子のファイルに切り出し
て、mock_provider の source
で参照パスを指定すれば良い
Slide 47
Slide 47 text
Terraform Testing Framework：部分的なモック化
● Mocks の Override 機能により、特定の既存の Resource、Module、Data
Source を参照し、モックオブジェクトを作成出来る
○ Resource の場合、override_resource でモック化出来る
○ Module の場合、override_module でモック化出来る
○ Data Source の場合、override_data でモック化出来る
● override_resource、override_data では、values で属性値を指定出来る
● override_module では、outputs で属性値を指定可能である
Slide 48
Slide 48 text
Terraform Testing Framework：部分的なモック化
Slide 49
Slide 49 text
Terraform Testing Framework：部分的なモック化
Slide 50
Slide 50 text
4 Policy as Code
を用いた設定検証
Slide 51
Slide 51 text
Policy as Code とは何か？
● Policy as Code (PaC) とは、組織やシステムの遵守事項をポリシーの
コードとして宣言し、ポリシーを運用・管理する手法である
● この手法を用いることで、ポリシーの変更管理や各種設定への一貫した
適用等が容易かつ効率的になる
● 主に、セキュリティ、コンプライアンス、リソース設 定 等の要 件やルール
の順守における検証で利用される
Slide 52
Slide 52 text
主要な PaC ツールの紹介： Open Policy Agent・Conftest
● Open Policy Agent (OPA) とは、OSS のポリシーエンジンである
● ポリシーエンジンとは、ポリシーに違反した情報が無いかチェックし、事
前に定義されたアクションを実行する機構である
● OPA を用いる場合、 Rego という言語でポリシーを宣言し、 OPA CLI を
実行してポリシーに則った検証を行う
Slide 53
Slide 53 text
主要な PaC ツールの紹介： Open Policy Agent・Conftest
● Conftest とは、OPA をエンジンとしたポリシーの検証ツールである
● OPA と同様で、 Rego でポリシーを宣言して Conftest CLI を実行して ポ
リシーに則った検証を行う
● Dockerfile、HCL / HCL2、JSON、YAML、XML 等の様々なファイルを
検証可能であり、実際に導入する場合は Conftest の方が良い
Slide 54
Slide 54 text
主要な PaC ツールの紹介 ：Open Policy Agent・Conftest
Slide 55
Slide 55 text
主要な PaC ツールの紹介： Hashicorp Sentinels
● Hashicorp Sentinel とは、Hashicorp により提供される PaC の言語や
フレームワークである (Rego とは異なる言語が用いられる )
● 無料利用は可能だが、基本的に Hashicorp のクラウドサービスとの連
携を前提とした機能が多く、実際は有料機能の検討が必要になる
● Hashicorp のクラウドサービスを導入予定の場合はこのツールが望ま
しいが、そうでは無い場合は Conftest で運用するのが良い
Slide 56
Slide 56 text
どの様にテストを組み込むか？
● 基本的には、まずは現在の必要最小限なテストパターンを洗い出し、それらを自
動化して運用し始めるのが良い
● 私見だが、従来のテスト手法と各種機能で出来ることを整理すると、初めの内は
下記のみから組み込み始めるだけでも十分に良いと考えている
○ Terraform Custom Conditions：Input Variable Validation、Preconditions
● 実際に運用し始めて、必要に迫られた時に以下も追加で検討すれば良い
○ TFLint、Trivy
○ Terraform Testing Framework (with Mocks)
○ Policy as Code：Conftest
Slide 57
Slide 57 text
5 今後の展望
Slide 58
Slide 58 text
今後のテク戦 SRE の動き
● 今後は、特に Terraform Modules に焦点を当て、開発・展開をさらに迅速に進
めるために、体制構築・負荷軽減の取り組みにも専念する予定です
○ メンテナー体制の構築
■ メンテナー向けのガイドラインの作成
■ 機能開発・テスト等のフローの自動化
○ 利用者向けの負荷軽減
■ 利用者向けのガイドラインの作成
■ 機能・仕様情報のガイドラインに沿った修正
○ リリース展開・FB 吸い上げの体制の構築
Slide 59
Slide 59 text
6 参考情報
Slide 60
Slide 60 text
参考情報のリンク一覧
● これまでの運用効率化の取り組み
○ レバレジーズテックブログ
● Terraform でのテストアプローチ
○ Terraform Custom Conditions
○ Terraform Testing Framework
○ Terraform CLI：Testing
○ Terraform Tutorials：Write Terraform Tests
Slide 61
Slide 61 text
参考情報の リンク一覧
● Policy as Code を用いた設定検証
○ Open Policy Agent
○ Conftest
○ Hashicorp Sentinel
● その他
○ 詳解 Terraform 第3版 (O'Reilly)
○ Infrastructure as Code (O'Reilly)
Slide 62
Slide 62 text
ご清聴、ありがとうございました！