85 lines
4.3 KiB
Markdown
85 lines
4.3 KiB
Markdown
---
|
||
description: 'Azure用の現代的なTerraformコード生成のガイドライン'
|
||
applyTo: '**/*.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パイプライン
|
||
- プレコミットフック
|
||
- フォーマット、リンティング、基本検証を強制
|