Skip to main content

第13章：開発中のデータ破壊を怖がらない：リセット手順を標準装備💣➡️🧯

この章はズバリ、「開発でDBやデータがぐちゃった時に、迷わず安全に“最初からやり直せる”状態を作る」回です😎✨ “怖くないリセット”ができると、migration や seed を気軽に試せて、開発スピードが爆上がりします🚀

この章のゴール🎯​

  • ✅ docker compose down と docker compose down -v の違いが説明できる
  • ✅ “消える範囲”を理解した上で、安心して初期化し直せる
  • ✅ ワンコマンドで「初期化からやり直す」（標準装備）できる🎛️✨
  • ✅ “誤爆”を避けるための 確認手順を持てる🧯

まず結論：リセットは「3段階」で考えると怖くない😌🧱​

開発のリセットは、いきなり最終兵器を撃たないのがコツです💡 よく使うのはこの3つ👇

  1. **ソフトリセット（コンテナだけ作り直す）**🧼
  2. **DBだけリセット（DBのvolumeだけ消す）**🐘💥
  3. **フルリセット（composeで作ったvolume全部消す）**💣

そして “フルリセット” の代表が docker compose down -v です。 この -v が付くと、Composeファイルの volumes: で宣言した名前付きボリューム + コンテナに付いてる匿名ボリュームを削除します。(Docker Documentation)

docker compose down と down -v を正しく怖がる😱➡️😎​

docker compose down（ふつうのdown）🧹​

  • コンテナ停止＆削除、ネットワーク削除（など）
  • ボリュームは基本消えない（＝DBデータは残りがち）
  • 匿名ボリュームはデフォでは消えない（ただし次の up で自動再マウントされないことが多い）(Docker Documentation)

docker compose down -v（データも消すdown）💥​

  • 上に加えて、ボリュームも削除
  • 特に重要：Composeファイルに書いた named volume も消える(Docker Documentation)

さらに安心オプション：--remove-orphans🧹🧟​

Composeファイルから消したサービスのコンテナが残ってると、地味に事故ります。 --remove-orphans は「Composeファイルに定義されてないサービスのコンテナ」を掃除します。(Docker Documentation)

誤爆しないための「確認3ステップ」🧯✅✅✅​

✅STEP0：今どの“プロジェクト名”で動いてるか把握する🪪​

Composeはプロジェクト名でリソース名が変わります。デフォルトは ディレクトリ名です。(Docker Documentation) まず一覧を見る👇

docker compose ls

（docker compose ls はプロジェクト一覧を表示できます）(Docker Documentation)

✅STEP1：プロジェクト名を“固定”して、事故の確率を下げる🔒​

おすすめは compose.yml のトップレベル name: で固定することです👍 （フォルダ名変更で別プロジェクト扱い→別volume作成…みたいな混乱が減ります）

name: myapp
services:
  # ...
volumes:
  # ...

この name は Compose のプロジェクト名として扱われます。(Docker Documentation)

✅STEP2：消していいvolumeだけ“見える化”する🔎📦​

Composeが作ったリソースには com.docker.compose.project などのラベルが付きます。(docs.docker.jp) Dockerは volume 一覧を --filter label=... で絞れます。(Docker Documentation)

たとえばプロジェクト名が myapp の場合👇

docker volume ls --filter label=com.docker.compose.project=myapp

これで「消す対象」を目で見てから動けます👀✨

ここから実践：3種類のリセット手順🛠️🔥​

以降のコマンドは、**基本はプロジェクト直下（compose.ymlのある場所）**で実行します👍 （VS Code のターミナルでOK！）

1) ソフトリセット：データは残して、コンテナだけ作り直す🧼​

「アプリの設定ミスった」「コンテナが変」くらいならこれで十分なこと多いです😊

docker compose down
docker compose up -d --build
  • DBのvolumeは残るので、DBの中身は基本そのままです📦

2) DBだけリセット：DBのvolumeだけ消す🐘💥（おすすめ頻出）​

「migration失敗でDBが崩壊」「seedやり直したい」みたいな時はこれが最強です💪

やり方A：volume名が分かってるなら、ピンポイント削除🎯​

  1. まず volume を見つける（ラベル絞り）🔎
docker volume ls --filter label=com.docker.compose.project=myapp
  1. DBっぽい名前（例：myapp_db-data）だけ削除💥
docker compose down
docker volume rm myapp_db-data
docker compose up -d --build

やり方B：より簡単にしたいなら「DBだけ別プロジェクト」にしない（＝構成で対応）​

この章の範囲では、まずAが現実的です👍

3) フルリセット：down -v で “最初から” に戻す💣➡️🧯​

「もう全部やり直したい！」「チュートリアル的に初期状態に戻す！」ならこれです🤣

docker compose down -v --remove-orphans
docker compose up -d --build

“絶対に消したくない”データがある場合の防波堤🧱🔒​

Composeの external で定義された ネットワーク/ボリュームは down でも削除されません。(Docker Documentation) つまり「守りたいデータ」は external に逃がすと強いです🛡️

イメージ（概念）👇

volumes:
  db-data:
    external: true
    name: myapp-db-data

※ただし運用が少し増える（事前に volume を作る等）ので、開発中は“消してOKなDB”にしておく方がラクなことも多いです😇

成果物：ワンコマンド化🎛️✨（これが本体）​

「迷ったらこれを叩けば復旧する」を作っておくと、精神が安定します🧘‍♂️🌿 例：package.json に scripts を足す（Node勢あるある）👇

{
  "scripts": {
    "dev:up": "docker compose up -d --build",
    "dev:down": "docker compose down",
    "dev:reset": "docker compose down -v --remove-orphans && docker compose up -d --build"
  }
}
  • npm run dev:reset ＝ 初期化からやり直しボタン🎮💥
  • これを README にも書くと、未来の自分が助かります📝✨

ハンズオン（5分）：わざと壊して、リセットで復活する🎭🧯​

  1. DBに適当にデータを入れる（seed済みでもOK）🌱
  2. わざと構成を変えてDBが合わない状態を作る（migration失敗のつもり）🫠
  3. npm run dev:reset を実行🎛️💥
  4. 初期化が走って、復活してるのを確認🎉

ポイント：壊す練習を先にしておくと、本番の事故が怖くなくなります😎🧯

よくある事故と対策あるある😇🧨​

😱「downしたのにDBが初期化されない！」​

→ それは正常です！ docker compose down だけだと volumeが残るので、初期化は基本走りません（前章の“罠”の正体）🪤 → down -v か 該当volumeだけ削除で解決💡(Docker Documentation)

😱「別のプロジェクトのデータ消したかも…」​

→ これが一番怖い🥶 対策は3つセットで鉄壁です👇

AIの使いどころ🤖💡（安全運転）​

AIにはこう聞くと強いです👇（秘密は貼らない前提🔒）

  • 「この compose.yml だと down -v で消えるものを箇条書きで説明して」
  • 「この volume 一覧から、DBっぽいのだけ選んで理由つけて」
  • 「誤爆防止のチェックリストを3行で作って」

“判断”は人間、整理はAI が最強ムーブです😎🤝🤖

まとめ🏁✨​

  • down は基本データ残る、down -v は データも消す（named volumeも対象）💥(Docker Documentation)
  • 誤爆防止は「プロジェクト名固定」「ラベルで絞って確認」🧯
  • 最終的に ワンコマンド reset を標準装備すると、開発が一気にラクになります🎛️🎉

次の章（第14章）は「バックアップの2系統：ダンプ型 vs ファイル丸ごと型🧠」なので、 この章で作った “リセット癖” が、そのまま “復元癖” に繋がって最強になりますよ〜🧯✨