↓の本の「8章 本番レベルのTerraformコード」のメモを残します。
前章のメモ
本番レベルのインフラ構築に時間がかかる理由
- DevOpsが発展途上な分野だから
- あるタスクに取り組む前にやるべきタスクがあるから
- そもそも構築するのに必要なタスクが多い
本番レベルのインフラのチェックリスト
本番レベルのインフラを構築するために考慮することはたくさんある。
- ソフトウェアのインストール
- ソフトウェアの設定
- インフラリソースのプロビジョニング
- アプリケーションのデプロイ
- 高可用性
- スケーラビリティ
- パフォーマンス
- ネットワーク
- セキュリティ
- メトリクス
- ログ
- データのバックアップ
- コスト最適化
- ドキュメント作成
- インフラコードの自動テスト
本番レベルのインフラモジュール
先ほどのタスクを実装する、再利用可能なモジュールのベストプラクティスを見ていく
小さなモジュール
JavaやPythonで関数をコーディングするときと同じく、Terraformのモジュールも小さくて独立しているのが理想です
コード量の多い、大きなモジュールだと
とデメリットしかないので、やめましょう!
組み合わせ可能なモジュール
小さく独立したモジュールを組み合わせるために何が必要でしょうか?
答えは、モジュールの入力変数と出力変数です。
これによりそれぞれのモジュールで作成したリソースを連携させます。
テスト可能なモジュール
テストするため、モジュールをデプロイできるサンプルコードを作ってみるのがいい。
サンプルコード ⇒ モジュール の順にコーディングしていくテスト駆動開発という手法もある。
先に入力/出力変数を決めておくことでUXが直感的になりやすい
バリデーション
入力変数にバリデーションを設定できる。
validationブロックに条件とエラーメッセージを定義。
事前条件、事後条件
validationよりも動的なチェックを行えるpreconditionとpostconditionブロックがある。
precondition:リソースのデプロイ前にチェック ⇒ エラーなら作成されない
postcondition:リソースのデプロイ後にチェック ⇒ エラーでも作成はされる(ロールバックなし)
validationブロックと同じく条件とエラーメッセージを定義するが、
lifecycleブロック内にprecondition/postconditionブロックを書く。
validation, precondition, postcondition の使い分け
- validation
- 変数に入ってくる値のチェック。
- 直接、変数に定義するため条件を把握しやすい。
- precondition
- 満たされるべき前提のチェック。
- リソースやデータソースのチェック。
- validationブロックでは難しい変数のチェック。
- postcondition
- デプロイ後の振る舞いの約束事のチェック。
- 高度なチェックは自動テストツールで実装
バージョン管理されたモジュール
モジュールを使う上で考慮すべきバージョンは↓の3点。
- Terraformのバージョン
- terraformブロックのrequired_versionパラメータで指定可能
- tfenv × .terraform-versionファイル も便利
- プロバイダのバージョン
- required_providersブロックのversionパラメータで指定可能
- terraform init 時に作成される .terraform.lock.hcl ファイルでも管理している
- モジュールのバージョン
- Gitの場合はタグをつけ、使用する際にはタグまで指定する。
- 自作のモジュールはTerraformレジストリに登録するのもあり。
- 登録するにはいくつかルールがある
Terraformモジュールの先へ
Terraformと他のツール(Bashスクリプト、Docker、Packerなど)を連携させるには
- プロビジョナ
- デフォルトではリソースの作成時のみに実行
- null_resource × プロビジョナ
- リソースとしては何も作成しない
- triggersの値が変化すると再作成され、プロビジョナも再実行される
- 外部データソース
- Bashスクリプトなど、何かを実行した結果を使いたい場合に適する
次章のメモ
コメント