4.3 KiB
4.3 KiB
| description | applyTo |
|---|---|
| Azure用の現代的なTerraformコード生成のガイドライン | **/*.tf |
1. 最新のTerraformとプロバイダーを使用
常に最新の安定版TerraformとAzureプロバイダーをターゲットにします。コードでは、必要なTerraformとプロバイダーのバージョンを指定してこれを強制します。新機能と修正を取得するため、プロバイダーバージョンを最新に保ちます。
2. コードを整理する
論理的なファイル分離でTerraform設定を構造化します：
- リソース用に
main.tfを使用 - 入力用に
variables.tfを使用 - 出力用に
outputs.tfを使用 - 一貫した命名規則とフォーマット（
terraform fmt）に従う
これにより、コードのナビゲートと保守が容易になります。
3. モジュールでカプセル化
再利用可能なインフラコンポーネントをグループ化するためにTerraformモジュールを使用します。複数のコンテキストで使用されるリソースセットに対しては：
- 独自の変数/出力を持つモジュールを作成
- コードの重複ではなくそれを参照
- これにより再利用性と一貫性が促進される
4. 変数と出力を活用
- すべての設定可能な値を型と説明を持つ変数を使用してパラメータ化
- オプション変数について適切な場合はデフォルト値を提供
- 他のモジュールやユーザー参照のため、キーリソース属性を公開するために出力を使用
- シークレットを保護するため、機密値を適切にマーク
5. プロバイダーの選択（AzureRM対AzAPI）
- ほとんどのシナリオでは**
azurermプロバイダーを使用** – 高い安定性を提供し、Azureサービスの大部分をカバー azapiプロバイダーは以下が必要な場合のみ使用：- 最新のAzure機能
azurermでまだサポートされていないリソース
- コードコメントで選択を文書化
- 必要に応じて両方のプロバイダーを一緒に使用できるが、疑わしい場合は
azurermを優先
6. 最小限の依存関係
- プロジェクトの範囲を超えて確認なしに追加のプロバイダーやモジュールを導入しない
- 特別なプロバイダー（例：
random、tls）や外部モジュールが必要な場合：- 説明するためのコメントを追加
- ユーザーの承認を確保
- インフラストラクチャスタックを軽量に保ち、不要な複雑さを避ける
7. 冪等性を確保
- 同じ結果で繰り返し適用できる設定を作成
- 非冪等アクションを避ける：
- すべての適用で実行されるスクリプト
- 二度作成されると競合する可能性があるリソース
- 複数の
terraform apply実行によってテストし、2回目の実行がゼロ変更となることを確保 - ドリフトや外部変更を適切に処理するため、リソースライフサイクル設定や条件式を使用
8. 状態管理
- Terraform状態を安全に保存するためにリモートバックエンド（状態ロック付きのAzure Storageなど）を使用
- チームコラボレーションを有効にする
- 状態ファイルをソース管理にコミットしない
- これにより競合を防ぎ、インフラストラクチャ状態を一貫して保つ
9. ドキュメント化と図表化
- 最新のドキュメントを維持
- コードが変更されるたびに新しい変数、出力、使用方法の指示でREADME.mdを更新
- 自動化のため
terraform-docsのようなツールの使用を検討 - 各重要な更新後にインフラストラクチャ変更を反映するためアーキテクチャ図を更新
- よく文書化されたコードと図表により、チーム全体がインフラストラクチャを理解できる
10. 変更の検証とテスト
- 変更を適用する前に**
terraform validateを実行**し、terraform plan出力をレビュー - エラーや意図しない変更を早期に捕捉
- 自動チェックの実装を検討：
- CIパイプライン
- プレコミットフック
- フォーマット、リンティング、基本検証を強制