【読書メモ】【8章】詳解 Terraform 第3版 ―Infrastructure as Codeを実現する

↓の本の「8章　本番レベルのTerraformコード」のメモを残します。

前章のメモ

【読書メモ】【7章】詳解 Terraform 第3版 ―Infrastructure as Codeを実現する

本番レベルのインフラ構築に時間がかかる理由

本番レベルのインフラを構築するために考慮することはたくさんある。

先ほどのタスクを実装する、再利用可能なモジュールのベストプラクティスを見ていく

JavaやPythonで関数をコーディングするときと同じく、Terraformのモジュールも小さくて独立しているのが理想です

コード量の多い、大きなモジュールだと

とデメリットしかないので、やめましょう！

小さく独立したモジュールを組み合わせるために何が必要でしょうか？

答えは、モジュールの入力変数と出力変数です。

これによりそれぞれのモジュールで作成したリソースを連携させます。

できる限り環境変数は使わず、入力/出力変数を使うようにしましょう
作成するリソースの一貫性を保ちやすくなります

テストするため、モジュールをデプロイできるサンプルコードを作ってみるのがいい。

サンプルコード ⇒ モジュール の順にコーディングしていくテスト駆動開発という手法もある。

先に入力/出力変数を決めておくことでUXが直感的になりやすい

入力変数にバリデーションを設定できる。

validationブロックに条件とエラーメッセージを定義。

条件式では、ブロックがある入力変数のみ参照可能。

validationよりも動的なチェックを行えるpreconditionとpostconditionブロックがある。

precondition：リソースのデプロイ前にチェック ⇒ エラーなら作成されない

postcondition：リソースのデプロイ後にチェック ⇒ エラーでも作成はされる（ロールバックなし）

validationブロックと同じく条件とエラーメッセージを定義するが、
lifecycleブロック内にprecondition/postconditionブロックを書く。

precondition/postconditionは他のリソースやデータも参照可能。
ただ、自身を参照する場合にはself.<ATTRIBUTE>を使う。

validation
- 変数に入ってくる値のチェック。
- 直接、変数に定義するため条件を把握しやすい。
precondition
- 満たされるべき前提のチェック。
- リソースやデータソースのチェック。
- validationブロックでは難しい変数のチェック。
postcondition
- デプロイ後の振る舞いの約束事のチェック。
高度なチェックは自動テストツールで実装

モジュールを使う上で考慮すべきバージョンは↓の3点。

Terraformのバージョン
- terraformブロックのrequired_versionパラメータで指定可能
- tfenv × .terraform-versionファイルも便利
プロバイダのバージョン
- required_providersブロックのversionパラメータで指定可能
- terraform init 時に作成される .terraform.lock.hcl ファイルでも管理している
モジュールのバージョン
- Gitの場合はタグをつけ、使用する際にはタグまで指定する。
- 自作のモジュールはTerraformレジストリに登録するのもあり。
  - 登録するにはいくつかルールがある

本番レベルでは、勝手にバージョンが上がってしまわないように
メジャーだけでなく、マイナー、パッチバージョンも指定しましょう

Terraformと他のツール（Bashスクリプト、Docker、Packerなど）を連携させるには

プロビジョナ
- デフォルトではリソースの作成時のみに実行
null_resource × プロビジョナ
- リソースとしては何も作成しない
- triggersの値が変化すると再作成され、プロビジョナも再実行される
外部データソース
- Bashスクリプトなど、何かを実行した結果を使いたい場合に適する