mcpField
O
opentofu-modules

opentofu-modules

github.com/ionfuryクラウド・DevOps2572 回インストール今日更新
リポジトリ

opentofu-modules について

homelab インフラ向けの OpenTofu モジュールとテストを作成するためのスキルです。モジュール構成を定め、リソースを作成しない plan 検証、出力のアサーション、機能フラグのテストを重視します。

主な機能

  1. 01モジュールのファイル構成を定義
  2. 02plan による構成テスト
  3. 03入力規則と出力の検証
  4. 04機能フラグ状態のテスト
  5. 05観点ごとのテスト整理

活用シーン

  1. 01homelab モジュールのファイルとテストの準備
  2. 02リソースを作成せずに構成を検証
  3. 03変数検証と機能フラグ動作のテスト

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ionfury/homelab --skill opentofu-modules

インストール後、Claude Code で/opentofu-modulesを入力して読み込まれたか確認します。

同梱ファイルreferences/opentofu-testing.mdtests.yaml

詳細

OpenTofu モジュールとテスト

ホームラボのインフラストラクチャ用に OpenTofu モジュールとテストを作成します。モジュールは infrastructure/modules/ に、テストは infrastructure/modules/<name>/tests/ に配置します。task tg:test-<module>（例：task tg:test-config）でテストを実行し、task tg:fmt でフォーマットします。OpenTofu のバージョンは .opentofu-version で固定されています。

モジュール構造

すべてのモジュールに必須です：

infrastructure/modules/<name>/
├── variables.tf    # Input definitions with descriptions and validations
├── main.tf         # Primary resources and locals
├── outputs.tf      # Output definitions
├── versions.tf     # Provider and OpenTofu version constraints
└── tests/          # Test directory
    └── *.tftest.hcl

テストファイルの構造

拡張子には .tftest.hcl を使用します。すべての run ブロックに継承されるデフォルト値として、トップレベルに variables を定義します。

# Top-level variables set defaults for ALL run blocks
variables {
  name     = "test-cluster"
  features = ["gateway-api", "longhorn"]

  networking = {
    id           = 1
    internal_tld = "internal.test.local"
    # ... other required fields
  }

  # Default machine - inherited unless overridden
  machines = {
    node1 = {
      cluster = "test-cluster"
      type    = "controlplane"
      install = { selector = "disk.model = *" }
      interfaces = [{
        id           = "eth0"
        hardwareAddr = "aa:bb:cc:dd:ee:01"
        addresses    = [{ ip = "192.168.10.101" }]
      }]
    }
  }
}

run "descriptive_test_name" {
  command = plan  # Use plan mode - no real resources created

  variables {
    features = ["prometheus"]  # Only override what differs
  }

  assert {
    condition     = output.some_value == "expected"
    error_message = "Descriptive failure message"
  }
}

主なパターン

常に command = plan を使用します。これにより、リソースを作成せずに設定を検証できます。トップレベルのデフォルトと異なる変数のみを run ブロックに含めます。継承される変数を繰り返し記述する必要はありません。内部リソースではなく、モジュールの出力に対してアサーションを行います。

機能フラグのテスト

有効状態と無効状態の両方をテストします：

run "feature_enabled" {
  command = plan
  variables { features = ["longhorn"] }

  assert {
    condition = alltrue([
      for m in output.talos.talos_machines :
      contains(m.install.extensions, "iscsi-tools")
    ])
    error_message = "Extension should be added when feature enabled"
  }
}

run "feature_disabled" {
  command = plan
  variables { features = [] }

  assert {
    condition = alltrue([
      for m in output.talos.talos_machines :
      !contains(m.install.extensions, "iscsi-tools")
    ])
    error_message = "Extension should not be present without feature"
  }
}
バリデーションのテスト

expect_failures を使用して、変数のバリデーションルールを検証します：

run "invalid_version_rejected" {
  command = plan
  variables {
    versions = {
      talos = "1.9.0"  # Missing v prefix - should fail
      # ...
    }
  }
  expect_failures = [var.versions]
}

テストの構成

関心事ごとにテストを整理します：

  • plan.tftest.hcl - 基本構造と出力の検証
  • validation.tftest.hcl - 入力のバリデーションルール
  • feature_<name>.tftest.hcl - 機能フラグの動作
  • edge_cases.tftest.hcl - 境界条件

詳細なリファレンス

OpenTofu のテスト構文、モックプロバイダー、高度なパターンについては、次を参照してください： references/opentofu-testing.md

コメント

Markdown 対応