📝

Azure on CDKTFと1ヶ月以上に渡る格闘をした話

に公開
Azure
CDK for Terraform
Container Apps
vnet
Entra ID
tech

Azure on CDKTFにEntraID認証とVnet構築を組み合わせたContainerApps環境をビルドして動作確認するまでに1ヶ月以上の時間を要している原因を分析し、根本的な対策を検討してみた話

🔍 時間がかかる根本原因の分析

1. 技術選択の問題

CDKTF (Cloud Development Kit for Terraform) の複雑性

  • 多層の抽象化: TypeScript → CDKTF → Terraform → Azure API
  • デバッグの困難さ: エラーが発生した際、どの層で問題が起きているか特定が困難
  • ドキュメントの不足: CDKTFのベストプラクティスや具体例が少ない

Azure Container Apps + VNet統合の複雑性

  • 新しいサービス: Container Appsは比較的新しく、VNet統合のパターンが確立されていない
  • 委譲の問題: サブネット委譲の管理が複雑で、エラーメッセージが不明瞭

2. 開発プロセスの問題

フィードバックループの遅さ 

コード修正 → GitHub Actions実行 → Azure API呼び出し → 結果確認
   ↑_______________________________________________|
          (5-10分のサイクル × 数十回 = 数時間)

段階的な検証不足

  • ローカルでの事前検証が困難
  • 一度に多くの要素を変更して原因特定が困難

🎯 即効性のある対策

1. 技術選択の見直し

オプション A: Pure Terraform への移行 ⭐️ 推奨 

# main.tf (シンプルで直接的)
resource "azurerm_container_app_environment" "main" {
  name                     = "container-app-env-dev"
  location                = "Japan East"
  resource_group_name     = "rg-jpe-01"
  infrastructure_subnet_id = azurerm_subnet.container_apps.id
}

resource "azurerm_container_app" "frontend" {
  name                         = "container-app-frontend-dev"
  container_app_environment_id = azurerm_container_app_environment.main.id
  resource_group_name         = "rg-jpe-01"
  revision_mode               = "Single"

  template {
    container {
      name   = "frontend"
      image  = "mcr.microsoft.com/azuredocs/containerapps-helloworld:latest"
      cpu    = 0.25
      memory = "0.5Gi"
    }
  }
}

メリット:

  • ✅ エラーメッセージが直接的
  • ✅ ドキュメントが豊富
  • ✅ デバッグが容易
  • ✅ 実行時間が短縮

オプション B: Azure CLI + Bicep への移行 

# deploy.sh (最もシンプル)
az containerapp env create \
  --name "container-app-env-dev" \
  --resource-group "rg-jpe-01" \
  --location "Japan East" \
  --infrastructure-subnet-resource-id "/subscriptions/.../subnets/..."

2. 開発プロセスの改善

高速フィードバックループの構築 

# ローカル検証スクリプト
./scripts/validate-local.sh  # 30秒
./scripts/plan-only.sh       # 2分
./scripts/deploy-dev.sh      # 5分

段階的な検証戦略 

# Stage 1: ネットワーク基盤のみ (2分)
terraform apply -target=azurerm_virtual_network.main

# Stage 2: Container Apps Environment (3分)  
terraform apply -target=azurerm_container_app_environment.main

# Stage 3: アプリケーション (2分)
terraform apply -target=azurerm_container_app.frontend

🚀 長期的な対策

1. インフラストラクチャ設計の標準化

CDKTFコアライブラリの活用 

// 既存の実績あるパターンを使用
import { ContainerEnvironment } from '@cdktf/core';

new ContainerEnvironment(this, 'environment', {
  // 実績のある設定パターン
});

2. 開発環境の改善

ローカル開発環境の構築 

# 1. Azurite (ローカルAzure Storage)
npm install -g azurite
azurite --silent &

# 2. Terraform plan専用環境
export TF_VAR_environment="local"
terraform plan -out=plan.tfplan

# 3. 設定検証
./scripts/validate-config.sh

テスト駆動インフラストラクチャ 

// tests/infrastructure.test.ts
describe('Container Apps Infrastructure', () => {
  it('should create VNet with correct configuration', () => {
    // テストケース
  });
});

📊 時間短縮の効果予測

現在の状況 

問題発生 → 調査 → 修正 → GitHub Actions → 結果確認
   1日      2時間    30分      10分         30分
= 約3時間/サイクル × 10サイクル = 30時間

改善後の予測 

問題発生 → ローカル検証 → 修正 → plan → apply
   30分        2分        5分    1分   3分
= 約11分/サイクル × 3サイクル = 33分

⚡ 約90%の時間短縮が可能

🎯 即座に実行可能な解決策

今すぐできること

  1. Pure Terraformへの移行 (推定: 2-3時間)

    # 1. 現在のCDKTF構成をTerraformに変換
cdktf synth
# 2. 生成されたTerraformファイルを手動で整理
# 3. 直接terraform apply

  2. CDKTFコアパターンの採用* (推定: 1-2時間)

    # 実績のあるコンストラクトをコピー
cp ../cdktf-core/src/constructs/container-environment.ts ./src/

  3. 段階的デプロイメントの実装 (推定: 30分)

    # ネットワークのみ先行デプロイ
terraform apply -target=module.network

推奨される最速ルート

💡 結論

根本原因: CDKTFの複雑性 + VNet統合の新規性 + 長いフィードバックループ

即効性のある解決策:

  1. Pure Terraformへの移行 (90%の時間短縮)
  2. 段階的デプロイメント (問題の局所化)
  3. ローカル検証環境 (高速フィードバック)

これらの対策により、残り作業時間を数時間に短縮できるはずです。

皆様ならどのアプローチを採用されますか？

最も効果的な Pure Terraform移行 がオススメ。

何故CDKTFを採用したのか？
どこかに未発見の虎の巻が隠されているに違いない

Discussion