@k2works/claude-code-booster 4.6.0 → 4.8.0

package/lib/assets/docs/article/getting-start-docker-kubernetes/18-case-load-testing.md

@@ -0,0 +1,294 @@
+# 第 18 章 ケーススタディの負荷テスト
+
+## はじめに
+
+第 12 章「12.3 負荷テスト」では、Python 製の負荷テストツール **Locust** をコンテナで動かす考え方を学びました。負荷生成ツール・シナリオ・テスト対象をすべてコンテナとして扱うことで、負荷テスト環境を「コードから一括で構築し、終わったら破棄する」ことができます。
+
+この章では、その考え方を第 13〜16 章の 4 ケース（同一ドメイン = Cargo Tracker の 4 アーキテクチャ）に適用します。各ケースに Locust の負荷テスト一式を用意し、**Docker Compose 版**と **Kubernetes 版**の 2 通りで実行できるようにしました。
+
+実装はすべて各ケースの [`loadtest/`](https://github.com/k2works/getting-started-docker-kubernetes/tree/main/apps/case-studies) ディレクトリにあります。
+
+| ケース | アーキテクチャ | loadtest ディレクトリ |
+|--------|--------------|----------------------|
+| case-1 | モノリス | `apps/case-studies/case-1-monolith/loadtest/` |
+| case-2 | イベント駆動 MS | `apps/case-studies/case-2-event-driven/loadtest/` |
+| case-3 | ES/CQRS（Axon） | `apps/case-studies/case-3-escqrs-axon/loadtest/` |
+| case-4 | ES/CQRS（Kafka） | `apps/case-studies/case-4-escqrs-kafka/loadtest/` |
+
+---
+
+## 18.1 構成
+
+各ケースの `loadtest/` には次のファイルが入っています。シナリオ（`locustfile.py`）は Compose 版・Kubernetes 版で共有します。
+
+| ファイル | 役割 |
+|---------|------|
+| `locustfile.py` | 負荷シナリオ（仮想ユーザーの振る舞い） |
+| `compose.loadtest.yaml` | Docker Compose 版 Locust の起動定義（Web UI: 8089） |
+| `kustomization.yaml` | Kubernetes 版 Locust の Kustomize 定義 |
+| `k8s-locust.yaml` | Kubernetes 版 Locust の Deployment / Service |
+| `README.md` | 実行手順・対象エンドポイント |
+
+### 現行 Locust API を使う
+
+第 12 章で引用したサンプル（`senario.py`）は、Locust 旧 API（`HttpLocust` / `TaskSet`）で書かれていました。これらは現行の Locust では廃止されているため、本章のシナリオは**現行 API（`HttpUser` / `@task` / `between`）**と公式イメージ `locustio/locust` で記述しています。
+
+```python
+from locust import HttpUser, between, task
+
+
+class CargoTrackerUser(HttpUser):
+    # 各タスクの実行間隔（記事の min_wait / max_wait に相当）
+    wait_time = between(1, 3)
+
+    @task(5)
+    def bookings(self):
+        self.client.get("/api/v1/bookings", name="/api/v1/bookings")
+```
+
+旧 API の `min_wait` / `max_wait`（ミリ秒）は、現行では `wait_time = between(min, max)`（秒）に置き換わっています。`HttpLocust` は `HttpUser`、`task_set` を持つ `TaskSet` は `HttpUser` に直接 `@task` を書く形になりました。
+
+---
+
+## 18.2 ケースごとの対象エンドポイントと認証
+
+負荷テストで重要なのは「**副作用のない読み取り系（GET）に、認証を通して負荷をかける**」ことです。4 ケースは認証方式が異なるため、シナリオもそれに合わせています。
+
+| ケース | 公開ポート（Compose） | 認証方式 | シナリオの方針 |
+|--------|---------------------|---------|--------------|
+| case-1 | 18080（app） | セッション + フォームログイン | 認証不要の GET のみ（`/actuator/health`、`/login`、`/public/tracking`） |
+| case-2 | 9080（gateway） | JWT（gateway で強制） | ログインで JWT を取得し、Read 系 GET に付与 |
+| case-3 | 9081（gateway） | JWT（gateway で強制） | ログインで JWT を取得し、CQRS Query 側へ |
+| case-4 | 9082（gateway） | `local` では認可無効 | 匿名で Read Model を GET |
+
+### case-1: 認証不要の GET（セッション認証のため）
+
+モノリス版は Spring Security のフォームログイン（セッション + CSRF）で保護されています。負荷テストでは、確実に匿名アクセスできる GET だけを対象にしています。
+
+| メソッド | パス | 説明 |
+|---------|------|------|
+| GET | `/actuator/health` | ヘルスチェック |
+| GET | `/login` | ログイン画面（HTML） |
+| GET | `/public/tracking` | 公開追跡の検索画面 |
+
+### case-2 / case-3: JWT ログインしてから GET
+
+両ケースとも gatewayms が JWT 認証を強制します。Locust の `on_start`（仮想ユーザー開始時に 1 回呼ばれる）でログインしてトークンを取得し、以降の GET に `Authorization: Bearer <token>` を付けます。
+
+```python
+def on_start(self):
+    """ログインして JWT を取得する。失敗時はトークンなしで続行する。"""
+    self.token = None
+    with self.client.post(
+        "/api/v1/auth/login",
+        json={"username": USERNAME, "password": PASSWORD},
+        name="/api/v1/auth/login",
+        catch_response=True,
+    ) as res:
+        if res.status_code == 200:
+            data = res.json() if res.text else {}
+            self.token = data.get("token") or data.get("accessToken")
+            if self.token:
+                res.success()
+            else:
+                res.failure("token がレスポンスに含まれていません")
+        else:
+            res.failure(f"ログイン失敗: HTTP {res.status_code}")
+```
+
+既定ユーザーはシード済みの `admin` / `password` です。case-3 は CQRS の Query 側（`/api/v1/bookings`、`/api/v1/voyages`、`/api/v1/billing/invoices` など）の Read Model 読み取りに負荷をかけます。
+
+### case-4: 認証なしで Read Model を GET
+
+case-4 は `local`（`local-docker`）プロファイルで起動するため、gateway / 各サービスの Spring Security 認可が無効になります。そのためログイン処理なしで、ページング付きの一覧 API に直接負荷をかけられます。
+
+```python
+@task(5)
+def bookings(self):
+    """予約一覧（Read Model、ページング）。"""
+    self.client.get("/api/v1/bookings?page=0&size=20", name="/api/v1/bookings")
+```
+
+`name=` を明示しているのは、`?page=0&size=20` のようなクエリ違いを Locust の統計上で同じエンドポイントとして集計するためです。
+
+---
+
+## 18.3 Docker Compose 版
+
+Compose 版は、第 12 章のサンプルと同様に「負荷生成側（Locust）を独立した Compose として用意する」方式です。ただし本ケーススタディは `dev:<case>` でアプリ本体を起動し、gateway/app を**ホストポートに公開**します。そこで Locust 側は、`host.docker.internal` 経由でそのホスト公開ポートへ負荷をかけます（どの Compose ネットワークからでも到達できます）。
+
+出典: `apps/case-studies/case-4-escqrs-kafka/loadtest/compose.loadtest.yaml`
+
+```yaml
+name: loadtest-case4
+
+services:
+  locust:
+    image: locustio/locust:2.32.5
+    ports:
+      - "8089:8089"
+    volumes:
+      - ./locustfile.py:/mnt/locust/locustfile.py:ro
+    environment:
+      LOCUST_LOCUSTFILE: /mnt/locust/locustfile.py
+      # 負荷対象。ホストに公開された 9082 番（gatewayms: 9082:8080）へ向ける。
+      LOCUST_HOST: ${TARGET_URL:-http://host.docker.internal:9082}
+    extra_hosts:
+      - "host.docker.internal:host-gateway"
+```
+
+ポイントは次のとおりです。
+
+- `image` に公式イメージ `locustio/locust` を使い、`volumes` でシナリオファイルをマウントします。イメージを再ビルドせずにシナリオを差し替えられます。
+- `LOCUST_LOCUSTFILE` / `LOCUST_HOST` は、Locust の CLI オプション（`-f` / `--host`）に対応する環境変数です。
+- `extra_hosts` で `host.docker.internal` を `host-gateway` に解決し、Linux でもホスト公開ポートへ到達できるようにしています。
+
+### 実行手順（Compose 版）
+
+```bash
+# 1. アプリ本体を起動（gateway をホスト 9082 に公開）
+npx gulp dev:case4
+
+# 2. Locust を起動（Web UI: http://localhost:8089）
+npx gulp loadtest:case4
+
+# 3. ブラウザで同時ユーザー数・増加レートを指定してテスト開始
+
+# 4. 終了
+npx gulp loadtest:case4:down
+```
+
+CI 向けに、UI なしで一定時間だけ実行して終了するヘッドレス実行も用意しています。
+
+```bash
+# 既定: 50 ユーザー / 毎秒 5 ユーザー増 / 1 分間
+npx gulp loadtest:case4:headless
+
+# パラメータを環境変数で上書き
+USERS=100 SPAWN=10 DURATION=3m npx gulp loadtest:case4:headless
+```
+
+---
+
+## 18.4 Kubernetes 版
+
+Kubernetes 版は、第 12 章の「負荷生成側とテスト対象を同一オーケストレータに載せる」考え方をそのまま適用します。**アプリと同じ名前空間に Locust をデプロイ**し、クラスタ内のサービス（`gatewayms` など）へ DNS 名で直接負荷をかけます。`host.docker.internal` やポートフォワードを介さず、より本番に近い経路で計測できます。
+
+シナリオ（`locustfile.py`）は Kustomize の `configMapGenerator` で ConfigMap として配布し、Compose 版と同じファイルを共有します。
+
+出典: `apps/case-studies/case-4-escqrs-kafka/loadtest/kustomization.yaml`
+
+```yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+
+namespace: cargo-tracker
+
+configMapGenerator:
+  - name: locust-scenario
+    files:
+      - locustfile.py
+
+resources:
+  - k8s-locust.yaml
+```
+
+出典: `apps/case-studies/case-4-escqrs-kafka/loadtest/k8s-locust.yaml`（抜粋）
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: locust
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: locust
+  template:
+    metadata:
+      labels:
+        app: locust
+    spec:
+      containers:
+        - name: locust
+          image: locustio/locust:2.32.5
+          args:
+            - "-f"
+            - "/mnt/locust/locustfile.py"
+            - "--host"
+            - "http://gatewayms:8080"   # クラスタ内サービスへ直接
+          ports:
+            - name: web
+              containerPort: 8089
+          volumeMounts:
+            - name: scenario
+              mountPath: /mnt/locust
+      volumes:
+        - name: scenario
+          configMap:
+            name: locust-scenario
+```
+
+ポイントは次のとおりです。
+
+- `namespace` をアプリと同じにすることで、`--host http://gatewayms:8080` のように**サービス名だけ**で負荷対象を指定できます（同一名前空間内の DNS 解決）。
+- `configMapGenerator` は ConfigMap 名にハッシュ（`locust-scenario-xxxx`）を付けます。Volume の `configMap.name` への参照は Kustomize が自動で書き換えるため、シナリオを変更すると新しいハッシュになり、Pod が確実に最新シナリオで再起動します。
+- 負荷対象は、case-1 は `cargo-tracker:80`、case-2〜4 は `gatewayms:8080` です（各サービスのクラスタ内ポート）。
+
+### 実行手順（Kubernetes 版）
+
+```bash
+# 1. アプリ本体を Kubernetes にデプロイ
+npx gulp k8s:case4
+
+# 2. Locust をデプロイ（同じ名前空間 cargo-tracker へ）
+npx gulp loadtest:case4:k8s
+
+# 3. Web UI を port-forward して開く（http://localhost:8089、Ctrl+C で終了）
+npx gulp loadtest:case4:k8s:open
+
+# 4. 削除
+npx gulp loadtest:case4:k8s:delete
+```
+
+なお、アプリの `k8s:<case>:open` タスクは、Locust をデプロイ済みであれば負荷テストの Web UI（`http://localhost:8089`）も Kibana などと一緒に自動で開きます（未デプロイのときは `svc/locust` が見つからずスキップされます）。アプリ・ログ可視化・負荷テスト UI を 1 コマンドでまとめて開けます。
+
+```bash
+npx gulp k8s:case4            # アプリをデプロイ
+npx gulp loadtest:case4:k8s   # 負荷テストをデプロイ
+npx gulp k8s:case4:open       # アプリ + Kibana + Locust(8089) をまとめて開く
+```
+
+---
+
+## 18.5 運用タスクとして統合する
+
+これらの負荷テストは、本プロジェクトの運用タスク（Gulp）に `loadtest:<case>` として統合されています。`dev:<case>`（Compose 起動）・`k8s:<case>`（Kubernetes デプロイ）と同じ命名規約で扱えます。
+
+| タスク | 説明 |
+|--------|------|
+| `loadtest:<case>` | Compose 版 Locust の Web UI を起動 |
+| `loadtest:<case>:headless` | Compose 版を UI なしで実行（`USERS` / `SPAWN` / `DURATION` で調整） |
+| `loadtest:<case>:down` | Compose 版を停止・破棄 |
+| `loadtest:<case>:k8s` | Kubernetes 版をデプロイ |
+| `loadtest:<case>:k8s:open` | Kubernetes 版の Web UI を port-forward して開く |
+| `loadtest:<case>:k8s:delete` | Kubernetes 版を削除 |
+| `loadtest:help` | 一覧とヘルプを表示 |
+
+ES/CQRS のケース（case-3 / case-4）では、書き込み（コマンド）から Read Model への投影が非同期です。シード直後は一覧が空のことがあるため、デプロイ後しばらく待ってから負荷テストを実行してください。
+
+---
+
+## まとめ
+
+- 第 12 章で学んだ Locust の負荷テストを、4 ケース（モノリス / イベント駆動 / ES・CQRS Axon / ES・CQRS Kafka）に適用しました
+- シナリオは現行 Locust API（`HttpUser` / `@task` / `between`）で記述し、Compose 版・Kubernetes 版で共有します
+- 認証方式の違い（セッション / JWT / 認可無効）に合わせ、副作用のない読み取り系 GET に負荷をかけるシナリオにしました
+- Compose 版は `host.docker.internal` 経由でホスト公開ポートへ、Kubernetes 版は同一名前空間からクラスタ内サービスへ、それぞれ負荷をかけます
+- 運用タスク（`loadtest:<case>`）として統合し、`dev:<case>` / `k8s:<case>` と同じ流れで「構築 → 負荷テスト → 破棄」を繰り返せます
+
+---
+
+- 前の章: [第 17 章 ケーススタディ実装比較まとめ](17-case-comparison-summary.md)
+- シリーズ目次: [Docker/Kubernetes 実践コンテナ解説](index.md)

package/lib/assets/docs/article/getting-start-docker-kubernetes/appendix-a-dev-tools-setup.md

@@ -0,0 +1,265 @@
+# 付録 A 開発ツールのセットアップ
+
+## はじめに
+
+本編で扱った Docker や Kubernetes を快適に学習・開発するには、いくつかの周辺ツールをそろえておくと便利です。この付録では、書籍『Docker/Kubernetes 実践コンテナ開発入門（第 2 版）』の付録に沿って、次の 4 つの開発ツールのセットアップ方法を解説します。
+
+- A.1 WSL2 — Windows 上で Linux 環境を動かす基盤
+- A.2 asdf — 複数言語・ツールのバージョンを統一管理する
+- A.3 kind — Docker の中に Kubernetes クラスタを立ち上げる
+- A.4 Rancher Desktop — Docker Desktop の代替となるローカル開発環境
+
+それぞれのツールは「何を解決するのか」という観点から整理します。ツールを導入する目的が明確であれば、自分の環境に合わせて取捨選択できるからです。
+
+なお、本付録には 2 種類の情報が含まれます。1 つは本リポジトリ（`getting-started-docker-kubernetes`）に実在する設定ファイルやスクリプトを引用した内容で、もう 1 つは各ツールの一般的な利用手順です。前者には出典を明示し、後者は「一般的な手順」と区別して記載します。コマンドの実行結果は環境やバージョンによって変わるため、確実でないものは「例」と明記するか省略しています。
+
+---
+
+## A.1 WSL2
+
+### WSL2 は何を解決するか
+
+Docker や Kubernetes のツールチェーンは Linux を前提に作られているものが多く、Windows でそのまま動かそうとすると差異に悩まされがちです。WSL2（Windows Subsystem for Linux 2）は、Windows 上で本物の Linux カーネルを動かす仕組みで、この「Windows と Linux の隔たり」を解決します。
+
+WSL の初代（WSL1）が Linux システムコールを翻訳する方式だったのに対し、WSL2 は軽量な仮想マシン上で実際の Linux カーネルを動作させます。これにより、ファイルシステムの互換性やネットワーク、Docker のようなコンテナ技術との相性が大きく改善されました。
+
+### WSL2 の導入
+
+最近の Windows 10/11 では、管理者権限の PowerShell またはコマンドプロンプトから次のコマンド 1 つで WSL2 と既定のディストリビューション（通常は Ubuntu）をまとめて導入できます。
+
+```bash
+wsl --install
+```
+
+実行後は再起動を求められることがあります。再起動後、初回起動時に Linux ユーザー名とパスワードの設定を求められます。
+
+インストール済みの状態を確認したい場合は、次のコマンドでバージョンや稼働状態を確認できます。
+
+```bash
+# WSL のバージョンと状態を確認する
+wsl --status
+
+# インストール済みディストリビューションを一覧表示する
+wsl --list --verbose
+```
+
+`wsl --list --verbose` の `VERSION` 列が `2` になっていれば WSL2 で動作しています。
+
+### ディストリビューションの導入
+
+既定以外のディストリビューションを使いたい場合は、導入可能な一覧を確認してから指定してインストールします。
+
+```bash
+# インストール可能なディストリビューションの一覧を表示する
+wsl --list --online
+
+# ディストリビューションを指定してインストールする（例: Ubuntu-22.04）
+wsl --install -d Ubuntu-22.04
+```
+
+既存のディストリビューションを WSL2 に変換したい場合は、バージョンを明示的に設定します。
+
+```bash
+# 既定のバージョンを WSL2 にする
+wsl --set-default-version 2
+
+# 個別のディストリビューションを WSL2 に変換する（例）
+wsl --set-version Ubuntu-22.04 2
+```
+
+### Docker との連携
+
+WSL2 は、コンテナ開発環境との連携において中心的な役割を果たします。代表的な連携方法は次の 2 つです。
+
+1. Docker Desktop の WSL2 バックエンドを利用する方法。Docker Desktop の設定で WSL2 ベースのエンジンを有効化すると、Windows 側にインストールした Docker を WSL2 のディストリビューションから透過的に利用できます。
+2. WSL2 のディストリビューション内に直接 Docker Engine をインストールする方法。Docker Desktop を使わず、Linux と同じ手順で Docker をセットアップします。後述の Rancher Desktop も WSL2 を基盤として利用します。
+
+開発時のポイントとして、ソースコードは Windows 側（`/mnt/c/...`）ではなく WSL2 のファイルシステム上（例: `~/projects`）に置くと、ファイル I/O が高速になり、ファイル変更検知（ホットリロード）も安定します。
+
+> 注: 上記コマンドは Windows 環境で一般的に有効なものです。利用可能なディストリビューションや既定の挙動は Windows のバージョン・更新状況によって異なります。
+
+---
+
+## A.2 asdf
+
+### asdf は何を解決するか
+
+開発を進めると、Go や Node.js といった言語ランタイムに加えて、`kustomize`、`helm`、`tilt` などの CLI ツールを多数使うことになります。これらは「プロジェクトごとに必要なバージョンが違う」「チームメンバー間でバージョンがそろわず、手元では動くのに他の環境で動かない」といった問題を起こしがちです。
+
+asdf は、複数の言語・ツールのバージョンを 1 つの仕組みでまとめて管理するバージョンマネージャです。プロジェクトのルートに置いた `.tool-versions` ファイルでツールとバージョンを宣言しておくことで、チーム全体で同じバージョンを再現できます。
+
+### `.tool-versions` でバージョンを固定する
+
+本リポジトリのサンプルアプリ `taskapp` では、`apps/taskapp/.tool-versions`（出典: `getting-started-docker-kubernetes` リポジトリ）で次のようにツールとバージョンを固定しています。
+
+```text
+golang 1.21.6
+tilt 0.33.10
+kustomize 5.3.0
+kubectx 0.9.5
+helm 3.13.3
+```
+
+このファイルが示すとおり、`taskapp` の開発には Go 本体に加えて、Kubernetes 開発で頻出する次のツール群が必要です。
+
+- `golang` — アプリケーション本体の実装に使う言語ランタイム
+- `tilt` — Kubernetes 上での開発を高速化する開発ツール
+- `kustomize` — Kubernetes マニフェストを環境差分込みで管理するツール
+- `kubectx` — `kubectl` のコンテキスト・名前空間を素早く切り替えるツール
+- `helm` — Kubernetes アプリケーションのパッケージマネージャ
+
+別のサンプルである `echo` アプリでは、`apps/echo/.tool-versions`（出典: 同リポジトリ）でより最小限の構成になっており、`kustomize` のみを固定しています。
+
+```text
+kustomize 5.3.0
+```
+
+このように、`.tool-versions` をプロジェクトごとに置くことで、「そのプロジェクトに必要なツールとバージョン」が明文化され、リポジトリをクローンした人は同じ環境を再現できます。
+
+### asdf のインストールとプラグイン追加
+
+asdf は本体を導入したあと、ツールごとに「プラグイン」を追加して使います。一般的な利用の流れは次のとおりです。
+
+```bash
+# プラグインを追加する（例: golang と kustomize）
+asdf plugin add golang
+asdf plugin add kustomize
+
+# .tool-versions に書かれたバージョンを一括インストールする
+asdf install
+
+# ツールのバージョンをグローバルに設定する（例）
+asdf global golang 1.21.6
+```
+
+`asdf plugin add` で対象ツールのプラグインを登録し、`asdf install` で `.tool-versions` の内容に従ってバージョンをインストールします。`asdf global` は、カレントディレクトリに `.tool-versions` がない場面でのデフォルトバージョンを設定するためのコマンドです（プロジェクト単位で固定したい場合は `asdf local` を使い、`.tool-versions` を更新します）。
+
+### `.tool-versions` から一括セットアップするスクリプト
+
+`taskapp` には、`.tool-versions` を読み取ってプラグイン追加とインストールをまとめて実行するセットアップスクリプトが用意されています。出典は `apps/taskapp/hack/install-tools.sh`（`getting-started-docker-kubernetes` リポジトリ）です。
+
+```bash
+#!/usr/bin/env bash
+
+cat .tool-versions | while read line
+do
+  echo $line | awk '{print $1}' | xargs -I{} asdf plugin add {}
+  if [ $? -ne 0 ]; then
+    continue
+  fi
+done
+
+asdf install
+```
+
+このスクリプトが行っていることは次のとおりです。
+
+1. `.tool-versions` を 1 行ずつ読み込む。
+2. 各行の先頭フィールド（ツール名）を `awk` で取り出し、`asdf plugin add` に渡してプラグインを追加する。
+3. プラグイン追加に失敗した行（`$? -ne 0`）はスキップして次の行へ進む。
+4. すべてのプラグイン追加が終わったら、最後に `asdf install` で `.tool-versions` に書かれたバージョンを一括インストールする。
+
+つまり、`.tool-versions` を更新してこのスクリプトを実行するだけで、必要なツール群を宣言どおりにそろえられます。バージョン管理の「単一の情報源（Single Source of Truth）」を `.tool-versions` に集約し、手作業のばらつきを排除する典型的なパターンです。
+
+> 注: `.tool-versions` の内容（ツール名・バージョン）は上記のとおり実ファイルからの引用ですが、`asdf plugin add` / `asdf install` / `asdf global` の使い方は asdf の一般的な利用手順です。
+
+---
+
+## A.3 kind
+
+### kind は何を解決するか
+
+kind（Kubernetes IN Docker）は、その名のとおり Docker コンテナをノードに見立てて Kubernetes クラスタを立ち上げるツールです。本来 Kubernetes クラスタの構築には複数のマシンや仮想マシンが必要ですが、kind を使えば Docker さえあれば手元のマシン 1 台でクラスタを起動・破棄できます。
+
+これにより「Kubernetes を学習・検証したいが、本格的なクラスタを用意するのは大変」という問題を解決できます。起動も破棄も速く、CI 環境での Kubernetes テストにも広く使われています。
+
+### クラスタの作成と削除
+
+最も基本的な使い方は次のとおりです（一般的な手順）。
+
+```bash
+# 既定設定でクラスタを作成する
+kind create cluster
+
+# 名前を付けてクラスタを作成する（例）
+kind create cluster --name dev
+
+# 作成済みクラスタの一覧を表示する
+kind get clusters
+
+# クラスタを削除する（名前を付けた場合は --name で指定）
+kind delete cluster --name dev
+```
+
+`kind create cluster` を実行すると、kind が Docker コンテナとしてノードを起動し、`kubectl` の接続先（kubeconfig のコンテキスト）も自動的に設定します。作成後はそのまま `kubectl get nodes` などでクラスタを操作できます。
+
+### kind-config.yaml によるマルチノード構成
+
+既定では単一ノード（コントロールプレーン兼ワーカー）のクラスタになりますが、設定ファイルを渡すことで複数ノードのクラスタを構成できます。次は 1 つのコントロールプレーンと 2 つのワーカーノードを持つ構成の例です（一般的な例）。
+
+```text
+# kind-config.yaml
+kind: Cluster
+apiVersion: kind.x-k8s.io/v1alpha4
+nodes:
+  - role: control-plane
+  - role: worker
+  - role: worker
+```
+
+この設定ファイルを指定してクラスタを作成します。
+
+```bash
+# 設定ファイルを指定してマルチノードクラスタを作成する
+kind create cluster --name multi --config kind-config.yaml
+```
+
+複数ノード構成にすると、Pod のスケジューリングやノード間の挙動を、本番に近い形でローカル検証できます。Kubernetes の基本概念については本編の第 5 章も参照してください。
+
+> 注: 上記の kind-config.yaml と各コマンドは kind の一般的な使い方を示した例です。実際の `apiVersion` やノード設定は kind のバージョンによって異なる場合があります。
+
+---
+
+## A.4 Rancher Desktop
+
+### Rancher Desktop は何を解決するか
+
+Rancher Desktop は、ローカルでコンテナと Kubernetes をまとめて動かせるデスクトップアプリケーションです。Docker Desktop の代替として利用でき、ライセンス面や軽量さを理由に選ばれることがあります。Windows・macOS・Linux に対応し、GUI からバージョンやランタイムを切り替えられます。
+
+「Docker Desktop に依存せずに、ローカルでコンテナと Kubernetes の両方を手軽に扱いたい」というニーズを解決するのが Rancher Desktop です。
+
+### コンテナランタイムの切り替え（containerd / dockerd）
+
+Rancher Desktop の特徴の 1 つは、コンテナランタイムを切り替えられる点です。設定画面から次の 2 種類を選択できます。
+
+- containerd — Kubernetes が標準的に利用するコンテナランタイム。Rancher Desktop では `nerdctl` という Docker 互換 CLI を通じてイメージのビルドやコンテナの実行を行います。
+- dockerd（Moby） — 従来の Docker と同じランタイム。`docker` コマンドや `docker-compose` をそのまま使いたい場合に選択します。
+
+既存の `docker` コマンドや本編で扱った操作をそのまま使いたい場合は dockerd を、Kubernetes 寄りの運用に合わせたい場合は containerd を選ぶ、といった使い分けができます。
+
+### 内蔵 Kubernetes（k3s）
+
+Rancher Desktop には軽量な Kubernetes ディストリビューションである k3s が内蔵されています。アプリの設定で Kubernetes を有効化すると、追加のインストールなしでローカル Kubernetes クラスタが起動し、`kubectl` で操作できるようになります。利用する Kubernetes のバージョンも GUI から選択できます。
+
+Windows では、Rancher Desktop は WSL2 を基盤として動作します（A.1 を参照）。そのため、WSL2 が有効になっていることが前提になります。kind がクラスタを都度作成・破棄するのに対し、Rancher Desktop の k3s は「常駐するローカルクラスタ」として使える点が異なります。用途に応じて、kind と Rancher Desktop を使い分けるとよいでしょう。
+
+> 注: ランタイムの切り替えや Kubernetes 有効化は Rancher Desktop の GUI から行う操作であり、画面構成はバージョンによって異なります。ここではコマンド出力の掲載は省略します。
+
+---
+
+## まとめ
+
+本付録では、Docker / Kubernetes を学習・開発するための周辺ツールを 4 つ紹介しました。それぞれが解決する課題を整理すると次のとおりです。
+
+- WSL2 — Windows 上で Linux 環境を動かし、Linux 前提のツールチェーンや Docker をスムーズに利用できるようにする。
+- asdf — `.tool-versions` で言語・ツールのバージョンを宣言的に固定し、チーム全体で同じ環境を再現する。本リポジトリの `apps/taskapp/.tool-versions` と `apps/taskapp/hack/install-tools.sh` がその実例である。
+- kind — Docker さえあれば手元でマルチノードの Kubernetes クラスタを起動・破棄でき、学習や CI に適する。
+- Rancher Desktop — Docker Desktop の代替として、containerd/dockerd の切り替えと内蔵 k3s により、ローカルでコンテナと Kubernetes をまとめて扱える。
+
+これらのツールは排他的なものではなく、目的に応じて組み合わせて使えます。たとえば「Windows で WSL2 を基盤に Rancher Desktop を動かし、プロジェクトのツールは asdf で固定し、検証用クラスタは kind で立てる」といった構成も成り立ちます。自分の開発スタイルと、本編で学んだコンテナ・Kubernetes の知識に合わせて、必要なツールを選んでください。
+
+### 関連リンク
+
+- [付録 B さまざまなコンテナオーケストレーション環境](appendix-b-orchestration-environments.md)
+- [第 1 章 コンテナと Docker の基礎](01-container-and-docker-basics.md)
+- [第 5 章 Kubernetes 入門](05-kubernetes-introduction.md)