第60章:最終まとめ:自力で直せる人になる🏆🎉
今日は“卒業試験”です🎓✨ API(Node/TS)+DB を Composeで一発起動して、わざと1個だけ不具合を仕込んで、ログ→切り分け→修正までを一人で通します💪😄
この章でできるようになること✅
- 「起動できない/繋がらない」を 落ち着いて分解できる🧠🧩
- ログ→状態→中身確認の順番で、最短距離で原因に当たれる🔍🪵
- “直せた手順”を テンプレ化して、次回から秒速で復旧できる⚡📦
1) 卒業試験セット:API+DB を一発起動する🚀
ここから先は、“起動の儀式”を固定化していきます🧘♂️✨
Composeは今どき docker compose(V2系) が標準で、公式ドキュメントもこの形でまとまっています。(Docker Documentation)
1-1. まずは「健康診断つき」compose.yml を用意🩺🐳
ポイントは2つだけ👇
- DBに healthcheck を付ける✅
- APIは DBが “使える状態” になるまで待つ(depends_on + service_healthy)⏳
services:
db:
image: postgres:16
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: postgres
POSTGRES_DB: todo
volumes:
- db-data:/var/lib/postgresql/data
# (必要なら)ホストから直でDBを見る用。不要なら消してOK
ports:
- "5432:5432"
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres -d todo"]
interval: 5s
timeout: 3s
retries: 20
api:
build: ./api
environment:
PORT: 3000
DATABASE_URL: postgres://postgres:postgres@db:5432/todo
ports:
- "3000:3000"
depends_on:
db:
condition: service_healthy
volumes:
db-data:
“depends_onで起動順を制御できる”のがComposeの基本。さらに healthcheck を使うと「起動した」じゃなく「使える」まで待てます👌(Docker Documentation)
1-2. 起動コマンドはこれで固定🎮✨
docker compose up --build --wait
--wait は サービスが running/healthy になるまで待ってくれるオプションです(healthcheckがあると強い🔥)。しかも waitを付けると自動でデタッチ挙動になります。(Docker Documentation)
起動したら状態確認👀
docker compose ps
ログも見る👂🪵
docker compose logs -f api
2) わざと1個だけ壊す:DB待ち問題を仕込もう🧨😈
「DBは起動中っぽいのに、APIが繋げなくて落ちる」 これ、現場でめっちゃ多いです😵💫(DBって“起動直後”は準備中になりがち)
2-1. 仕込み方(どれか1つでOK)🎲
仕込みA:depends_on を “待たない版” にする
condition: service_healthy を一旦消してこう👇
depends_on:
- db
仕込みB:DBの healthcheck を消す healthcheckブロックを丸ごと削除。
2-2. 症状を観察(ここが大事)👀🔍
起動:
docker compose up --build
よくある症状👇
- APIログに
ECONNREFUSEDやtimeout系が出る - APIが即終了して再起動ループ(または落ちっぱなし)
3) 直す前に:デバッグの“型”で詰める🧱🕵️♂️
ここからは 順番が命です🧠✨ (感情で殴らない。ログで殴る💪🪵)
3-1. まず「誰が死んでる?」を確認☠️➡️👀
docker compose ps
- api が
Exitedなら、まず api ログ - db が
healthyじゃないなら、db ログ
3-2. ログで「最初の失敗1行」を探す🔎🪵
docker compose logs --tail=200 api
docker compose logs --tail=200 db
コツ👇
- 一番最初に出てるエラーが“親”で、後続は“子”になりがち👶
connection refusedは「到達できない」password authentication failedは「設定ミス」database does not existは「DB名/初期化」
3-3. “箱の中”で設定を確認(環境変数)🎛️📦
docker compose exec api sh
中に入ったら:
printenv DATABASE_URL
- ホスト名が
dbになってる?(localhostになってたら事故率高い🚨) - ポートは
5432? - DB名は
todo?
3-4. “名前解決できてる?”を超ミニチェック🏷️🌐
(OSコマンドが無くても、Nodeならだいたい動く👍)
node -e "require('dns').lookup('db', (e,a)=>console.log(e||a))"
ここでIPが出れば 少なくとも名前は引けてる✅
4) 修正:DBが“使える状態”まで待つ🛠️✅
4-1. 正解の戻し方(おすすめ)🏁
- db に healthcheck を戻す
- api の depends_on を
condition: service_healthyに戻す - 起動は
--waitで固定
docker compose up --build --wait
--wait は “running/healthy まで待つ” ので、healthcheckとセットで事故率が激減します💥🔧(Docker Documentation)
Composeは依存関係順で起動するけど、「使える」保証までは別。だから healthcheck が効くんだね〜って理解が勝ちです🏆(Docker Documentation)
4-2. もう一段つよくする(保険)🛡️✨
もしAPI側が「起動時にDB接続テストして即死」タイプなら、アプリ側でリトライも入れると堅いです🙂 (ただし、この章の本筋は “Composeで待てるようにする” なので、まずは 4-1 を完成させよう!)
5) “直せた手順”をテンプレ化して勝ち逃げ🏃♂️💨
毎回コマンド打つの面倒なので、npm scripts に封印します📜✨ (Windowsでも回しやすい👍)
{
"scripts": {
"dev": "docker compose up --build --wait",
"down": "docker compose down",
"reset": "docker compose down -v --remove-orphans",
"logs": "docker compose logs -f --tail=200"
}
}
npm run devで起動🚀npm run logsで追跡🪵npm run resetは“全部やり直しボタン”💣(データ消えるので注意⚠️)
6) AIに頼る(ズルじゃない、道具😎🤖)
そのままコピペで使える“質問テンプレ”置いときます📌✨
-
ログ要約&次の一手
- 「このログを3行で要約して、次に打つべきコマンドを3つだけ提案して」🪵➡️🎯
-
compose.ymlレビュー
- 「このcompose.ymlを、起動待ち・安全性・開発体験の観点で改善案を箇条書きで」🧩🛠️
-
原因の当たり付け
- 「症状A(貼る)から考えられる原因候補トップ3と、切り分け順を出して」🔍🥇
7) 卒業チェックリスト✅🎉
ここ、全部できたら Docker初心者は卒業です🎓🐳
-
docker compose up --build --waitで迷わず起動できる -
docker compose psを最初に見る癖がついた -
docker compose logs --tail=200で “最初の失敗” を拾える -
docker compose exec api shで中に入って環境変数を確認できる - DBの “起動した/使える” の差を理解した(healthcheck)
- 直した手順を npm scripts に固定できた
8) 次に伸ばすなら(おまけ)🚀✨
8-1. Compose Watch で “保存したら反映” にする⚡👀
Composeには watch があり、ファイル変更を自動で反映してくれる仕組みがあります。開発の体感が一段上がります🧑💻✨(Docker Documentation)
8-2. profiles で「必要な時だけ追加サービス」を起動🧩🎛️
例えば「DB管理ツールだけ必要な時に起動」みたいなのが簡単になります👌(Docker Documentation)
8-3. Nodeは “LTSが安心” を覚えておく📌
2026年初頭時点だと、Nodeは v24がActive LTSとして案内されています(安定寄りで選ぶならここが安心枠)🟢(Node.js)
必要なら、あなたの 今のTodo APIの compose.yml / Dockerfile をここに貼ってくれたら、第60章の卒業試験仕様に寄せて“最短で直る形”にリライトして返すよ😄👍