@k2works/claude-code-booster 6.1.0 → 6.3.0

package/lib/assets/docs/article/getting-start-docker-kubernetes/13-case-monolith-compose-vs-kustomize.md

@@ -1,346 +0,0 @@
----
-type: Article
-title: "第 13 章 モノリスのデプロイ — Docker Compose 対 Kustomize"
-description: "第 5 部では、実在の業務システム「国際貨物輸送システム（Cargo Tracker）」を題材に、アーキテクチャの違いがコンテナのデプロイ手段の選択にどう影響するかを学びます。"
-tags: [article, getting-start-docker-kubernetes]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-06-26T00:29:42Z }
----
-
-# 第 13 章 モノリスのデプロイ — Docker Compose 対 Kustomize
-
-## はじめに
-
-第 5 部では、実在の業務システム「国際貨物輸送システム（Cargo Tracker）」を題材に、アーキテクチャの違いがコンテナのデプロイ手段の選択にどう影響するかを学びます。同じ貨物追跡というドメインを、モノリス・イベント駆動マイクロサービス・ES/CQRS（Axon）・ES/CQRS（Kafka）という 4 つのアーキテクチャで実装した題材を使い、Docker Compose・Kustomize・Helm を比較します。
-
-この章では最初のケースとして、**モノリス**版（Spring Boot + PostgreSQL の単一アプリケーション）を取り上げ、**Docker Compose** と **Kustomize** の 2 つの手段でデプロイして比較します。
-
-実装は [`apps/case-studies/case-1-monolith/`](https://github.com/k2works/getting-started-docker-kubernetes/tree/main/apps/case-studies/case-1-monolith) にあります。アプリ本体のソース（`cargo-tracker/`）も同梱しているため、リポジトリ単体でビルド・デプロイを再現できます。
-
----
-
-## 1. アーキテクチャ概要
-
-モノリス版の Cargo Tracker は、貨物追跡の業務（予約・経路設計・荷役・追跡・請求）を 1 つの Spring Boot アプリケーションにまとめた構成です。
-
-- **アプリケーション**: Spring Boot 4 / Java 25。Thymeleaf による画面、Spring Security による認証、Flyway による DB マイグレーション、MyBatis による永続化を持つ
-- **データベース**: PostgreSQL 16
-- **公開ポート**: 8080（`/actuator/health` でヘルスチェック）
-
-```plantuml
-@startuml
-title モノリス版 Cargo Tracker
-
-actor 利用者
-node "cargo-tracker\n(Spring Boot, :8080)" as app
-database "PostgreSQL\n(:5432)" as db
-
-利用者 --> app : HTTP
-app --> db : JDBC
-@enduml
-```
-
-デプロイの観点では「アプリ 1 つ + DB 1 つ」というシンプルな構成です。コンテナの数が少ないため、デプロイ手段による差は小さく見えますが、**単一ホスト向けの Compose とクラスタ向けの Kustomize の考え方の違い**を理解する好例になります。
-
-### アプリイメージのビルド
-
-アプリは multi-stage build で、ビルドステージ（`eclipse-temurin:25-jdk`）で Gradle により `bootJar` を生成し、実行ステージ（`eclipse-temurin:25-jre`）に成果物だけをコピーします。
-
-```bash
-docker build -t cargo-tracker:0.0.1 apps/case-studies/case-1-monolith/cargo-tracker
-```
-
----
-
-## 2. Docker Compose による実装
-
-Docker Compose は、複数のコンテナを 1 つの YAML ファイルにまとめて単一ホスト上で起動する手段です。`apps/case-studies/case-1-monolith/compose/compose.yaml` を見てみましょう。
-
-```yaml
-services:
-  postgres:
-    image: postgres:16
-    environment:
-      POSTGRES_DB: cargo_tracker
-      POSTGRES_USER: cargo_tracker
-      # パスワードはファイルで渡す（実体は secrets で注入）
-      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
-    secrets:
-      - db_password
-    volumes:
-      - postgres_data:/var/lib/postgresql/data
-    healthcheck:
-      test: ["CMD-SHELL", "pg_isready -U cargo_tracker"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-
-  app:
-    build:
-      context: ../cargo-tracker
-    image: cargo-tracker:0.0.1
-    depends_on:
-      postgres:
-        condition: service_healthy
-    environment:
-      SPRING_PROFILES_ACTIVE: product
-      DB_URL: jdbc:postgresql://postgres:5432/cargo_tracker
-      DB_USERNAME: cargo_tracker
-    # DB_PASSWORD は secrets のファイルから読み込んで起動する
-    command:
-      - "sh"
-      - "-c"
-      - 'export DB_PASSWORD="$$(cat /run/secrets/db_password)" && exec java $${JAVA_OPTS} -jar /app/app.jar'
-    secrets:
-      - db_password
-    ports:
-      - "18080:8080"
-    healthcheck:
-      test: ["CMD-SHELL", "curl -f http://localhost:8080/actuator/health || exit 1"]
-      interval: 15s
-      timeout: 5s
-      retries: 5
-      start_period: 60s
-
-secrets:
-  db_password:
-    file: ./secrets/db_password
-
-volumes:
-  postgres_data:
-```
-
-ポイントは次のとおりです。
-
-- **サービス間の名前解決**: `app` は `DB_URL` で `postgres` というサービス名を指定するだけで DB に接続できます。Compose が同一ネットワーク内で名前解決します
-- **起動順序の制御**: `depends_on` の `condition: service_healthy` により、PostgreSQL が healthy になってからアプリを起動します
-- **永続化**: `postgres_data` という named volume で DB データを永続化します
-- **設定の注入**: `environment` で Spring の `product` プロファイルと DB 接続情報を渡します
-- **機密情報のファイル注入**: パスワードは `environment` に直書きせず、`secrets` でコンテナ内の `/run/secrets/db_password` にマウントします。PostgreSQL は `POSTGRES_PASSWORD_FILE` でファイルを読み、アプリは `command` でファイルを読み出して `DB_PASSWORD` を組み立ててから起動します（第 4 章のタスクアプリと同じ方式）
-
-### 起動と動作確認
-
-secrets の実体ファイルを初回起動前に作成します。
-
-```bash
-cd apps/case-studies/case-1-monolith/compose
-mkdir -p secrets && printf 'cargo_tracker' > secrets/db_password
-docker compose up -d
-```
-
-アプリが起動すると、ヘルスチェックと画面アクセスが確認できます。
-
-```bash
-curl http://localhost:18080/actuator/health
-# {"groups":["liveness","readiness"],"status":"UP"}
-
-curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}\n' http://localhost:18080/
-# 302 -> http://localhost:18080/login   （Spring Security による認証リダイレクト）
-```
-
-Flyway により DB マイグレーションが自動適用され、`cargo` や `tracking_record` などの業務テーブルが作成されます。
-
----
-
-## 3. Kustomize による実装
-
-Kustomize は、Kubernetes のマニフェストをリソース種別ごとのファイルに分割し、`kustomization.yaml` で束ねる手段です。`apps/case-studies/case-1-monolith/k8s/kustomize/` は次の構成です。
-
-```
-k8s/kustomize/
-├── kustomization.yaml   # 束ねる定義 + イメージタグ管理
-├── namespace.yaml       # cargo-monolith namespace
-├── secret.yaml          # DB 認証情報
-├── postgres.yaml        # PVC + Deployment + Service
-├── app.yaml             # Deployment + Service
-└── ingress.yaml         # Ingress
-```
-
-`kustomization.yaml` がエントリポイントです。
-
-```yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-namespace: cargo-monolith
-
-resources:
-  - namespace.yaml
-  - secret.yaml
-  - postgres.yaml
-  - app.yaml
-  - ingress.yaml
-
-images:
-  - name: cargo-tracker
-    newTag: 0.0.1
-```
-
-Compose との対応を見ると、考え方の違いが分かります。
-
-- **Compose のファイル `secrets`（DB 認証）→ Kubernetes の `Secret`**: Compose では `secrets` でパスワードをファイル注入していましたが、Kubernetes では `secret.yaml` に DB 認証情報を定義し、アプリの `Deployment` から `secretKeyRef` で参照します
-- **Compose の named volume → `PersistentVolumeClaim`**: `postgres.yaml` で PVC を宣言し、PostgreSQL の Pod にマウントします
-- **Compose の `ports` 公開 → `Service` + `Ingress`**: クラスタ内通信は `Service`、外部公開は `Ingress` で行います
-- **Compose の `healthcheck` → `readinessProbe` / `livenessProbe`**: アプリの `Deployment` で `/actuator/health` を監視します
-
-アプリの `Deployment`（`app.yaml`）では、`product` プロファイルと DB 接続情報を環境変数で渡し、ヘルスチェックをプローブとして定義しています。
-
-```yaml
-          env:
-            - name: SPRING_PROFILES_ACTIVE
-              value: product
-            - name: DB_URL
-              value: jdbc:postgresql://postgres:5432/cargo_tracker
-            - name: DB_USERNAME
-              valueFrom:
-                secretKeyRef:
-                  name: db-credentials
-                  key: POSTGRES_USER
-            - name: DB_PASSWORD
-              valueFrom:
-                secretKeyRef:
-                  name: db-credentials
-                  key: POSTGRES_PASSWORD
-          ports:
-            - name: http
-              containerPort: 8080
-          readinessProbe:
-            httpGet:
-              path: /actuator/health
-              port: http
-            initialDelaySeconds: 30
-            periodSeconds: 10
-            failureThreshold: 12
-```
-
-`DB_HOST` 相当はクラスタ内の `Service` 名 `postgres` で解決されます。Compose と同様、サービス名による名前解決が効く点は共通です。
-
-### デプロイと動作確認
-
-```bash
-kubectl apply -k apps/case-studies/case-1-monolith/k8s/kustomize
-kubectl -n cargo-monolith get pods
-# NAME                            READY   STATUS    RESTARTS   AGE
-# cargo-tracker-xxxxxxxxx-xxxxx   1/1     Running   2          78s
-# postgres-xxxxxxxxxx-xxxxx       1/1     Running   0          78s
-
-kubectl -n cargo-monolith port-forward svc/cargo-tracker 18081:80
-curl http://localhost:18081/actuator/health
-# {"groups":["liveness","readiness"],"status":"UP"}
-```
-
-> 補足: アプリ起動が DB 準備より早いと初回プローブで再起動（`RESTARTS`）が発生することがありますが、`readinessProbe` の `failureThreshold` の範囲で復帰し、最終的に `1/1 Running` になります。
-
-`kubectl kustomize apps/case-studies/case-1-monolith/k8s/kustomize` を実行すると、適用前に生成されるマニフェストを確認できます。
-
----
-
-## 4. 環境差分の扱い
-
-実運用ではローカル・ステージング・本番で設定が変わります。両手段の差分管理の考え方は次のとおりです。
-
-- **Docker Compose**: ベースの `compose.yaml` に対し、`compose.override.yaml` や `-f` による複数ファイル合成、`.env` ファイルでの変数差し替えで対応します。第 2 部で見た echo の検証でも、ポートだけを差し替えるオーバーライドを使いました
-- **Kustomize**: `base/` に共通定義を置き、`overlays/<env>/` で `patches` や `images`・`replicas` を上書きします。本ケースは単一構成のため base のみですが、第 8 章で見た taskapp のように overlay を追加すれば環境ごとの差分を宣言的に管理できます
-
-どちらも「共通部分 + 差分」という構造は同じですが、Kustomize は Kubernetes リソースのフィールド単位でパッチを当てられる点が強力です。
-
----
-
-## 5. ロギング基盤（EFK + DaemonSet）
-
-[第 9 章](09-container-operations.md) で原則として学んだ **EFK（Elasticsearch + Fluentd + Kibana）+ DaemonSet** のログ集約パターンを、本ケースにも実装として組み込んでいます。各 Pod は標準出力にログを出すだけで、ノード単位で常駐する Fluentd がそれを収集し、Elasticsearch に蓄積、Kibana で検索・可視化します。
-
-`k8s/kustomize/logging/` に次の 4 ファイルを置き、`kustomization.yaml` の `resources` に追加しています。
-
-```
-logging/
-├── elasticsearch.yaml      # ConfigMap + PVC + Service + Deployment（単一ノード）
-├── fluentd-daemonset.yaml  # ServiceAccount + ClusterRole/Binding + DaemonSet
-├── kibana.yaml             # Deployment + Service（NodePort 30051）
-└── kibana-setup-job.yaml   # index pattern を自動作成する Job
-```
-
-### Fluentd を DaemonSet で常駐させる
-
-第 9 章のとおり、Fluentd は各ノードの `/var/log/containers` を `hostPath` で読み取り、ノード上の全 Pod のログをまとめて収集します。ここで本実装固有の要点が **ログ形式のパース**です。近年の Kubernetes（kind / Docker Desktop など）は containerd を使い、ログが CRI 形式（`<time> stdout F <message>`）で書かれます。Fluentd 既定の JSON パーサのままだと一致せず警告が出続けるため、環境変数で CRI 用のパーサを指定します。
-
-```yaml
-          env:
-            - name: FLUENT_ELASTICSEARCH_HOST
-              value: "elasticsearch"
-            # containerd の CRI ログ形式に合わせる（既定の json だと不一致になる）
-            - name: FLUENT_CONTAINER_TAIL_PARSER_TYPE
-              value: "/^(?<time>.+) (?<stream>stdout|stderr) (?<logtag>[FP]) (?<log>.*)$/"
-```
-
-DaemonSet は Kubernetes API から Pod のメタデータを付与するため、`ServiceAccount` と読み取り専用の `ClusterRole`（`pods`・`namespaces` への get/list/watch）を与えています。ClusterRole はクラスタスコープのため、ケース間で名前が衝突しないよう `fluentd-cargo-monolith` のように namespace で修飾しています。
-
-### Elasticsearch の運用上の勘所
-
-ログは蓄積されるデータなので `PersistentVolumeClaim` で永続化します。学習用の単一ノード構成（`discovery.type=single-node`）ですが、2 点の実運用上の注意があります。
-
-- **メモリ**: JVM heap（`-Xms512m -Xmx512m`）に加え、Lucene の mmap やダイレクトバッファなどのオフヒープが必要です。コンテナのメモリ上限を heap と同程度にすると OOMKilled になるため、`limits.memory` は heap の 3〜4 倍（2Gi）を確保します。
-- **更新戦略**: 単一インスタンスが RWO の PVC を握るため、`strategy: Recreate` を指定します。既定の RollingUpdate だと旧 Pod の終了前に新 Pod が起動し、同じデータディレクトリを奪い合って `failed to obtain node locks` で起動に失敗します。
-
-```yaml
-spec:
-  replicas: 1
-  strategy:
-    type: Recreate          # RWO PVC のため旧 Pod を終了してから新 Pod を起動
-```
-
-### Kibana を「開いたらすぐ使える」状態にする
-
-Kibana は通常、初回に手動で index pattern を作成する必要があります。これを `kibana-setup` という `Job` で自動化し、Kibana の起動を待って index pattern `logstash-*` を作成、既定ビューを Discover に設定します。デプロイ後にブラウザを開けば、設定なしでログ検索を始められます。
-
-```bash
-# ロギング基盤はアプリと同時にデプロイされる（kubectl apply -k k8s/kustomize）
-kubectl -n cargo-monolith get pods -l app.kubernetes.io/component=logging
-
-# 収集状況の確認（logstash-* にログが蓄積される）
-kubectl -n cargo-monolith exec deploy/elasticsearch -- curl -s 'http://localhost:9200/logstash-*/_count'
-
-# Kibana を開く（kind では NodePort が localhost に出ないため port-forward が確実）
-kubectl -n cargo-monolith port-forward svc/kibana 18081:5601   # → http://localhost:18081/
-```
-
-第 9 章で原則として学んだ EFK + DaemonSet を、各ケースの構成に組み込むことで、デプロイした瞬間からアプリ・インフラ双方のログを一元的に観測できます。
-
----
-
-## 6. 比較考察
-
-モノリス（アプリ 1 + DB 1）という小さな構成では、両手段の差は次のように整理できます。
-
-| 観点 | Docker Compose | Kustomize |
-|------|----------------|-----------|
-| 対象 | 単一ホスト | Kubernetes クラスタ |
-| ファイル数 | 1 ファイル | リソース種別ごとに分割（6 ファイル） |
-| 記述量 | 少ない | 多い（種別ごとに apiVersion/kind/metadata） |
-| 機密情報 | ファイルベース `secrets` | `Secret` |
-| 永続化 | named volume | PVC |
-| 公開 | ポート公開 | Service + Ingress |
-| スケール・自己修復 | 限定的 | Deployment が標準で提供 |
-| 学習コスト | 低い | 中（Kubernetes の概念が前提） |
-| 適性 | ローカル開発・小規模 | 本番・スケール・可用性が必要な環境 |
-
-モノリスのように構成要素が少ない場合、**ローカル開発や検証では Docker Compose の簡潔さが際立ち**ます。1 ファイルで全体を把握でき、`docker compose up` だけで起動します。
-
-一方、**本番でスケールや自己修復、ローリングアップデートが必要になると Kubernetes（Kustomize）の価値が出てき**ます。記述量は増えますが、それは Service・Ingress・Probe・PVC といった本番運用に必要な関心事を明示的に宣言しているためです。
-
-重要なのは、モノリスではこの差が「好みと運用要件の問題」にとどまる点です。次章以降のマイクロサービスでは構成要素が一気に増え、デプロイ手段の選択がより本質的な意味を持つようになります。
-
----
-
-## まとめ
-
-- モノリス版 Cargo Tracker（Spring Boot + PostgreSQL）を Docker Compose と Kustomize の両方でデプロイし、いずれも `/actuator/health` が UP になることを確認しました
-- Compose の `environment`・named volume・`ports`・`healthcheck` は、Kubernetes ではそれぞれ `Secret`・PVC・`Service`/`Ingress`・`Probe` に対応します
-- 構成要素が少ないモノリスでは、Compose の簡潔さと Kustomize の運用機能のトレードオフは緩やかです
-- 第 9 章の EFK + DaemonSet を本ケースに組み込み、Fluentd（DaemonSet）→ Elasticsearch → Kibana のログ集約を `k8s/kustomize/logging/` で宣言しました（CRI ログ対応・ES の Recreate 戦略・index pattern の自動作成が実装上の勘所）
-- 次章では、構成要素が大幅に増えるイベント駆動マイクロサービス（case-2）を題材に、Kustomize と Helm を比較します
-
----
-
-- 次の章: [第 14 章 イベント駆動マイクロサービスのデプロイ — Kustomize 対 Helm](14-case-event-driven-kustomize-vs-helm.md)
-- シリーズ目次: [Docker/Kubernetes 実践コンテナ解説](index.md)

package/lib/assets/docs/article/getting-start-docker-kubernetes/14-case-event-driven-kustomize-vs-helm.md

@@ -1,324 +0,0 @@
----
-type: Article
-title: "第 14 章 イベント駆動マイクロサービスのデプロイ — Kustomize 対 Helm"
-description: "前章では構成要素の少ないモノリスを題材に、Docker Compose と Kustomize を比較しました。"
-tags: [article, getting-start-docker-kubernetes]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-06-26T00:29:42Z }
----
-
-# 第 14 章 イベント駆動マイクロサービスのデプロイ — Kustomize 対 Helm
-
-## はじめに
-
-前章では構成要素の少ないモノリスを題材に、Docker Compose と Kustomize を比較しました。この章では、同じ国際貨物輸送システム（Cargo Tracker）を**イベント駆動マイクロサービス**として実装した版（case-2）を取り上げます。構成要素が一気に増えるため、デプロイ手段の選択がより本質的な意味を持ちます。
-
-ここでの比較軸は **Kustomize 対 Helm** です。多数の似た構造を持つマイクロサービスを、どちらがどのように扱うかを実装と動作検証を通じて確認します。
-
-実装は [`apps/case-studies/case-2-event-driven/`](https://github.com/k2works/getting-started-docker-kubernetes/tree/main/apps/case-studies/case-2-event-driven) にあります。バックエンド（Gradle マルチプロジェクト）とフロントエンドのソースを同梱しており、リポジトリ単体でビルド・デプロイを再現できます。
-
----
-
-## 1. アーキテクチャ概要
-
-イベント駆動版は、貨物追跡の業務をドメインごとのマイクロサービスに分割し、API ゲートウェイで束ね、サービス間の連携を RabbitMQ のイベントで行う構成です。
-
-```plantuml
-@startuml
-title イベント駆動マイクロサービス版 Cargo Tracker
-
-actor 利用者
-node "frontend\n(nginx, SPA)" as fe
-node "gatewayms\n(Spring Cloud Gateway, :8080)" as gw
-node "authms :8081" as auth
-node "bookingms :8082" as booking
-node "routingms :8083" as routing
-node "trackingms :8084" as tracking
-node "billingms :8086" as billing
-queue "RabbitMQ" as mq
-database "PostgreSQL\n(6 DB)" as db
-
-利用者 --> fe
-fe --> gw : /api/...
-gw --> auth
-gw --> booking
-gw --> routing
-gw --> tracking
-gw --> billing
-booking ..> mq : publish
-tracking ..> mq : subscribe
-auth --> db
-booking --> db
-routing --> db
-tracking --> db
-billing --> db
-@enduml
-```
-
-構成要素は次のとおりです。
-
-- **gatewayms**（8080）: `/api/v1/auth/**` → authms、`/api/booking/**` → bookingms などのパスベースルーティング
-- **6 つのマイクロサービス**: authms(8081)・bookingms(8082)・routingms(8083)・trackingms(8084)・handlingms(8085)・billingms(8086)
-- **frontend**: SPA を配信し `/api/` を gateway へプロキシ
-- **PostgreSQL**: 1 インスタンスに 6 データベース（`auth_db`・`booking_db` …）
-- **RabbitMQ**: bookingms・trackingms 間のイベント連携
-
-モノリスが「アプリ 1 + DB 1」だったのに対し、こちらは **アプリ 8 + インフラ 2（PostgreSQL・RabbitMQ）= 10 個のワークロード**になります。
-
-### イメージのビルド
-
-バックエンドは Gradle マルチプロジェクトです。一度のビルドで全サービスの jar を生成し、各サービスをイメージ化します。
-
-```bash
-cd apps/case-studies/case-2-event-driven/backend
-./gradlew bootJar -x test
-for s in gatewayms authms bookingms routingms trackingms handlingms billingms; do
-  docker build -t "cargo2-$s:0.0.1" "$s"
-done
-cd ../frontend && docker build -t cargo2-frontend:0.0.1 .
-```
-
----
-
-## 2. Kustomize による実装
-
-Kustomize では、リソースを種別・コンポーネントごとのファイルに分割します。`apps/case-studies/case-2-event-driven/k8s/kustomize/base/` の構成は次のとおりです。
-
-```
-base/
-├── kustomization.yaml      # 束ねる定義 + configMapGenerator + images
-├── namespace.yaml
-├── secret.yaml             # DB 認証
-├── init-databases.sql      # 6 DB 作成（ConfigMap 化）
-├── postgres.yaml
-├── rabbitmq.yaml
-├── authms.yaml             # ┐
-├── bookingms.yaml          # │ サービスごとに Deployment + Service を記述
-├── routingms.yaml          # │
-├── trackingms.yaml         # │
-├── handlingms.yaml         # │
-├── billingms.yaml          # ┘
-├── gatewayms.yaml
-├── frontend.yaml
-└── ingress.yaml
-```
-
-注目すべきは、**6 つのバックエンドサービスがほぼ同じ構造の Deployment + Service を持つ**点です。違いは名前・ポート・接続先データベース・RabbitMQ の要否だけですが、Kustomize ではそれぞれを個別のファイルとして書き下します。例として `bookingms.yaml` の要点は次のとおりです。
-
-```yaml
-          env:
-            - name: SPRING_PROFILES_ACTIVE
-              value: local-prod
-            - name: DB_URL
-              value: jdbc:postgresql://postgres:5432/booking_db
-            - name: DB_USERNAME
-              valueFrom:
-                secretKeyRef: { name: db-credentials, key: DB_USERNAME }
-            - name: DB_PASSWORD
-              valueFrom:
-                secretKeyRef: { name: db-credentials, key: DB_PASSWORD }
-            - name: RABBITMQ_HOST
-              value: rabbitmq
-```
-
-`kustomization.yaml` では、6 DB の初期化 SQL を `configMapGenerator` で ConfigMap 化し、イメージタグを `images` で集中管理します。
-
-```yaml
-configMapGenerator:
-  - name: postgres-init
-    files:
-      - init-databases.sql=init-databases.sql
-
-images:
-  - name: cargo2-authms
-    newTag: 0.0.1
-  # ... 8 イメージ分
-```
-
-### デプロイと動作確認
-
-```bash
-kubectl apply -k apps/case-studies/case-2-event-driven/k8s/kustomize/base
-```
-
-10 個の Pod がすべて `1/1 Running` になります（DB 起動待ちで一部 Pod に再起動が入りますが、`readinessProbe` の範囲で復帰します）。
-
-```bash
-kubectl -n cargo-event get pods
-# authms / billingms / bookingms / frontend / gatewayms / handlingms /
-# postgres / rabbitmq / routingms / trackingms  — すべて 1/1 Running
-```
-
-ゲートウェイ経由の疎通を確認します。
-
-```bash
-kubectl -n cargo-event port-forward svc/gatewayms 18090:8080
-curl http://localhost:18090/actuator/health
-# {"groups":["liveness","readiness"],"status":"UP"}
-
-curl -s -o /dev/null -w '%{http_code}\n' http://localhost:18090/api/v1/auth/
-# 401   ← ゲートウェイが authms に到達し、認証が要求された（疎通成功）
-```
-
-`/api/...` が各サービスで `401`（認証要求）を返すことは、ゲートウェイがバックエンドへ正しくルーティングできている証拠です（バックエンド停止なら 502/503 になります）。フロントエンドも `HTTP 200` で SPA を配信します。
-
----
-
-## 3. Helm による実装
-
-Helm は Go テンプレートでマニフェストを生成します。`apps/case-studies/case-2-event-driven/helm/cargo-event/` の構成は次のとおりです。
-
-```
-helm/cargo-event/
-├── Chart.yaml
-├── values.yaml             # 設定値（サービス一覧・認証・ポート）
-└── templates/
-    ├── infra.yaml          # secret + postgres-init + postgres + rabbitmq
-    ├── microservices.yaml  # 6 サービスをループで生成
-    ├── gateway.yaml
-    ├── frontend.yaml
-    └── ingress.yaml
-```
-
-最大の違いは、Kustomize で 6 ファイルに分かれていたバックエンドサービスが、**`values.yaml` のリスト + テンプレートのループ 1 つ**に集約される点です。
-
-`values.yaml`：
-
-```yaml
-services:
-  - name: authms
-    port: 8081
-    database: auth_db
-    rabbit: false
-  - name: bookingms
-    port: 8082
-    database: booking_db
-    rabbit: true
-  # ... routingms / trackingms / handlingms / billingms
-```
-
-`templates/microservices.yaml`（抜粋）：
-
-```yaml
-{{- range .Values.services }}
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: {{ .name }}
-spec:
-  template:
-    spec:
-      containers:
-        - name: {{ .name }}
-          image: cargo2-{{ .name }}:{{ $.Values.imageTag }}
-          env:
-            - name: DB_URL
-              value: jdbc:postgresql://postgres:5432/{{ .database }}
-            {{- if .rabbit }}
-            - name: RABBITMQ_HOST
-              value: rabbitmq
-            {{- end }}
-          ports:
-            - { name: http, containerPort: {{ .port }} }
----
-# ... Service も同じループ内で生成
-{{- end }}
-```
-
-サービスを 1 つ増やすときは、Kustomize では新しいファイルを追加して `resources` と `images` に登録しますが、Helm では `values.yaml` のリストに 1 エントリ追加するだけで済みます。RabbitMQ の要否のような条件分岐も `{{- if .rabbit }}` で表現できます。
-
-### 検証とデプロイ
-
-```bash
-helm lint apps/case-studies/case-2-event-driven/helm/cargo-event
-# 1 chart(s) linted, 0 chart(s) failed
-
-helm template cargo-event apps/case-studies/case-2-event-driven/helm/cargo-event | grep -c '^kind:'
-# 24   （Kustomize の 25 から Namespace を除いた数。Helm は --create-namespace で名前空間を作る）
-
-helm install cargo-event apps/case-studies/case-2-event-driven/helm/cargo-event \
-  --namespace cargo-event --create-namespace
-```
-
-Helm 版も同様に 10 Pod が `1/1 Running` になり、ゲートウェイ経由の疎通（health UP、`/api/...` が 401）を確認できました。Helm はさらに**リリース管理**を提供します。
-
-```bash
-helm history cargo-event -n cargo-event
-# REVISION  STATUS    CHART              DESCRIPTION
-# 1         deployed  cargo-event-0.1.0  Install complete
-
-helm uninstall cargo-event -n cargo-event
-```
-
-`helm upgrade` でリビジョンが増え、`helm rollback` で以前のリビジョンに戻せます。Kustomize（`kubectl apply`）にはこの世代管理がありません。
-
----
-
-## 4. ロギング基盤（EFK + DaemonSet）
-
-[第 9 章](09-container-operations.md) の **EFK（Elasticsearch + Fluentd + Kibana）+ DaemonSet** によるログ集約パターンを、本ケースにも実装として組み込んでいます（[第 13 章](13-case-monolith-compose-vs-kustomize.md) と同じ構成）。各 Pod は標準出力にログを出すだけで、各ノードに常駐する Fluentd がノード上の全 Pod のログを収集し、Elasticsearch に蓄積、Kibana で可視化します。
-
-`k8s/kustomize/base/logging/` に 4 ファイルを置き、`kustomization.yaml` の `resources` に追加しています。
-
-```
-logging/
-├── elasticsearch.yaml      # ConfigMap + PVC + Service + Deployment（単一ノード）
-├── fluentd-daemonset.yaml  # ServiceAccount + ClusterRole/Binding + DaemonSet
-├── kibana.yaml             # Deployment + Service（NodePort 30052）
-└── kibana-setup-job.yaml   # index pattern logstash-* を自動作成する Job
-```
-
-実装上の勘所は第 13 章と共通です。
-
-- **Fluentd**: `hostPath` で `/var/log/containers` を読み取る。containerd の CRI ログ形式に合わせて `FLUENT_CONTAINER_TAIL_PARSER_TYPE` を指定（既定の json だと不一致）。ClusterRole はケース間で衝突しないよう `fluentd-cargo-event` に修飾
-- **Elasticsearch**: RWO PVC のため `strategy: Recreate`、heap の 3〜4 倍（2Gi）のメモリ上限で OOM を回避
-- **Kibana**: `kibana-setup` Job が index pattern と既定ビュー（Discover）を自動設定し、開いたらすぐ使える
-
-マイクロサービス構成では、Fluentd を 1 つの DaemonSet として常駐させるだけで、authms・bookingms・routingms… といった多数のサービスや RabbitMQ・PostgreSQL のログを、横断的に 1 か所（Kibana）で追えるのが利点です。
-
-```bash
-# アプリと同時にデプロイされる（kubectl apply -k k8s/kustomize/base）
-kubectl -n cargo-event get pods -l app.kubernetes.io/component=logging
-kubectl -n cargo-event exec deploy/elasticsearch -- curl -s 'http://localhost:9200/logstash-*/_count'
-# Kibana を開く（kind では NodePort が localhost に出ないため port-forward が確実）
-kubectl -n cargo-event port-forward svc/kibana 18081:5601   # → http://localhost:18081/
-```
-
----
-
-## 5. 比較考察
-
-イベント駆動マイクロサービス（8 アプリ + 2 インフラ）という構成で、両手段の差は前章のモノリスより明確になります。
-
-| 観点 | Kustomize | Helm |
-|------|-----------|------|
-| 似た構造の扱い | サービスごとにファイルを書き下す（6 ファイル） | `values` のリスト + ループで 1 定義に集約 |
-| サービス追加 | ファイル追加 + `resources`/`images` 登録 | `values.yaml` に 1 エントリ追加 |
-| 条件分岐 | パッチ／別ファイルで表現 | `{{- if }}` で表現 |
-| パラメータ化 | overlay でフィールド上書き | `values.yaml` + `--set` |
-| 配布 | Git リポジトリ | チャートのパッケージ配布 |
-| リリース管理 | なし | リビジョン履歴・`rollback` |
-| 学習コスト | 低〜中（YAML + パッチの理解） | 中（テンプレート言語の理解） |
-| 透明性 | 生 YAML に近く読みやすい | テンプレートは `helm template` で展開して確認 |
-
-**Kustomize の強み**は、生の YAML に近く「何がデプロイされるか」が直感的に分かる点です。少数のサービスや、環境差分が主に「値の上書き」で済む場合に向きます。
-
-**Helm の強み**は、**似た構造の繰り返しをテンプレート化して重複を排除**できる点と、**リリース管理（バージョン・ロールバック）**です。マイクロサービスのように同型のコンポーネントが多数あり、チャートとして配布・バージョン管理したい場合に効果を発揮します。
-
-本ケースでは、6 つの同型サービスをテンプレートのループ 1 つにまとめられた点が Helm の価値を最もよく示しています。一方、Kustomize の冗長さは「明示的で読みやすい」という長所の裏返しでもあり、どちらが優れているかは構成の規模とチームの運用方針によります。
-
----
-
-## まとめ
-
-- イベント駆動マイクロサービス版 Cargo Tracker（8 アプリ + PostgreSQL + RabbitMQ）を Kustomize と Helm の両方でデプロイし、いずれも 10 Pod が `1/1 Running` になり、ゲートウェイ経由の疎通を確認しました
-- Kustomize は同型サービスを個別ファイルで明示的に書き下し、Helm は `values` のリスト + テンプレートのループで重複を排除します
-- Helm はリリース管理（リビジョン・ロールバック）を提供し、Kustomize は生 YAML に近い透明性を提供します
-- 第 9 章の EFK + DaemonSet を本ケースにも組み込み、Fluentd（DaemonSet）が多数のサービスのログを横断的に収集して Kibana で観測できるようにしました
-- 次章では、同じドメインを ES/CQRS（Axon）で実装した case-3 を題材に、引き続き Kustomize と Helm を比較します
-
----
-
-- 前の章: [第 13 章 モノリスのデプロイ — Docker Compose 対 Kustomize](13-case-monolith-compose-vs-kustomize.md)
-- 次の章: [第 15 章 ES/CQRS マイクロサービス（Axon）のデプロイ — Kustomize 対 Helm](15-case-escqrs-axon-kustomize-vs-helm.md)
-- シリーズ目次: [Docker/Kubernetes 実践コンテナ解説](index.md)