ln-783-container-launcher

パス： ファイルパス（references/、../ln-*）は、このスキルディレクトリからの相対パスです。

ln-783-container-launcher

タイプ： L3 ワーカー
カテゴリー： 7XX プロジェクトのブートストラップ

---

目的

Docker イメージをビルドし、コンテナを起動して、Docker ネイティブのヘルスチェックと再試行戦略を使用した包括的な健全性検証を実行します。

対象範囲：

• docker-compose.yml の設定を検出して検証する
• Docker イメージをビルドする
• 適切な起動順序でコンテナを起動する
• ネイティブのヘルスチェックを使用してコンテナの健全性を検証する
• アクセス URL とクリーンアップ手順を提示する

対象外：

• アプリケーションコードのビルド（ln-781 が担当）
• テストの実行（ln-782 が担当）
• 単一ホストを超えるコンテナオーケストレーション（Kubernetes、Swarm）

---

使用するタイミング

シナリオ	このスキルを使用
単独で実行可能	はい
コンテナを単独で起動	はい
開発環境のセットアップ	はい
本番環境へのデプロイ	いいえ。適切な CI/CD を使用してください

---

ワークフロー

ステップ 1：事前チェック

Docker 環境が使用可能な状態か確認します。

チェック	失敗時の対応
Docker デーモンが実行中	インストール手順を添えてエラーを報告
Docker Compose が利用可能	エラーを報告し、インストールを提案
Compose ファイルが存在する	エラーを報告し、想定される場所を列挙
必要なポートが空いている	競合を報告し、代替案を提案
ディスク容量が十分	空き容量が少ない場合（2GB 未満）は警告

ステップ 2：Compose 設定の解析

docker-compose.yml からサービス情報を抽出します。

情報	目的
サービス名	監視対象のコンテナを特定する
公開ポート	チェックするポートを把握する
ヘルスチェック定義	定義されている場合はネイティブのヘルスチェックを使用する
依存関係（depends_on）	起動順序を把握する
ボリュームマウント	パスの存在を確認する

ステップ 3：イメージのビルド

Compose ファイルで定義されているすべてのイメージをビルドします。

項目	方針
ビルドコンテキスト	Compose ファイルのパスを使用する
ビルド引数	Compose の設定から引き継ぐ
キャッシュ	高速化のため Docker レイヤーキャッシュを使用する
失敗時	ビルドエラーを完全なログとともに報告する

ステップ 4：コンテナの起動

適切なオーケストレーションでコンテナを起動します。

項目	方針
起動順序	depends_on と healthcheck の条件に従う
デタッチモード	バックグラウンドで実行する
ネットワーク	Compose で定義されたネットワークを使用する
ボリューム	定義されているすべてのボリュームをマウントする

ステップ 5：健全性の検証

適切な方法を使用して、すべてのコンテナが正常であることを確認します。

戦略の選択：

条件	戦略
サービスに Compose 内で healthcheck: がある	Docker ネイティブのヘルスステータスを使用する
サービスに depends_on: condition: service_healthy がある	Docker のヘルスステータスを待つ
ヘルスチェックが定義されていない	再試行付きの外部 HTTP プローブを使用する

再試行の設定：

パラメーター	値	理由
最大試行回数	10	起動に時間がかかるサービスに対応する
初期待機時間	5s	コンテナの起動時間を確保する
バックオフ	指数（5、10、20、40s）	サービスへの過度な負荷を避ける
最大総待機時間	120s	妥当な上限

ヘルスチェック方法：

方法	使用する場面
Docker ヘルスステータス	コンテナに healthcheck が定義されている場合
公開ポートへの HTTP GET	ヘルスチェックのない Web サービスの場合
コンテナ内での exec	公開ポートのないサービスの場合
TCP ポートチェック	データベースやメッセージキューの場合

Step 6: 結果を報告する

構造化された結果をオーケストレーターに返します。

結果の構造：

フィールド	説明
containers	コンテナの状態オブジェクトの配列
healthChecks	ヘルスチェック結果の配列
accessUrls	サービス名からアクセス URL へのマップ
overallStatus	healthy / unhealthy / partial
startupDuration	起動からすべてが healthy になるまでの時間

コンテナ状態オブジェクト：

フィールド	説明
name	コンテナ名
service	compose のサービス名
status	running / exited / restarting
health	healthy / unhealthy / starting / none
port	公開ポート（ある場合）
startedAt	コンテナの起動タイムスタンプ

ヘルスチェック結果：

フィールド	説明
url	チェックした URL またはエンドポイント
status	HTTP ステータスコードまたはチェック結果
responseTime	応答時間（ミリ秒）
healthy	ヘルス状態を示すブール値

---

エラー処理

エラーの種類	対応
Docker デーモンが実行されていない	起動手順とともに報告する
ポートがすでに使用中	競合を報告し、先に docker compose down を実行するよう提案する
イメージのビルドに失敗	ビルドログとともに報告する
コンテナが終了	コンテナログとともに報告する
ヘルスチェックがタイムアウト	最後に確認された状態とログを報告する
ネットワークに到達できない	Docker ネットワークの設定を確認する

---

オプション

オプション	デフォルト	説明
keepRunning	true	検証後もコンテナを実行したままにする
stopAfter	false	検証成功後にコンテナを停止する
healthTimeout	120	healthy 状態になるまで待機する最大秒数
showLogs	true	失敗時にコンテナログを表示する
buildFirst	true	起動前にイメージをビルドする
pullLatest	false	ビルド前にベースイメージを取得する

---

クリーンアップ手順

レポートにクリーンアップ用のコマンドを記載します。

操作	説明
コンテナを停止	実行中のコンテナを停止し、データは保持する
コンテナとネットワークを削除	ボリュームは残してコンテナをクリーンアップする
すべて削除	ボリュームとイメージを含めて完全にクリーンアップする

---

重要なルール

1. 利用可能な場合はネイティブのヘルスチェックを使用する — 外部プローブより信頼性が高くなります
2. バックオフ付きの再試行を実装する — サービスの初期化には時間が必要です
3. 失敗時は必ずログを収集する — デバッグに不可欠です
4. ポートは compose ファイルから解析する — ポート番号をハードコードしないでください
5. depends_on の順序を守る — データベースに依存するサービスでは不可欠です

Monitor との統合（Claude Code 2.1.98+）

必ず読んでください： references/monitor_integration_pattern.md を読み込みます

コンテナのヘルス確認には、Monitor を使用してコンテナログをストリーミングします。

パターン	コマンド	timeout_ms
準備完了シグナル	docker compose logs -f 2>&1 | grep --line-buffered -iE 'ready|listening|healthy|started'	healthTimeout * 1000
エラー監視	docker compose logs -f 2>&1 | grep --line-buffered -iE 'error|fatal|panic|exit'	healthTimeout * 1000

keepRunning が true で、継続的なログ監視が必要な場合は persistent: true を使用します。 代替手段：Monitor を利用できない場合は、sleep と curl によるヘルスチェックを使った再試行ループを使用します。

---

完了の定義

• Docker 環境を確認済み
• すべてのイメージのビルドに成功
• すべてのコンテナが実行中
• すべてのヘルスチェックに合格
• アクセス URL を提示済み
• 結果をオーケストレーターに返却済み

---

参考ファイル

• 親：../ln-780-bootstrap-verifier/SKILL.md

---

バージョン： 2.0.0 最終更新日： 2026-01-10