メインコンテンツまでスキップ

第20章：ミニまとめ：個人開発の“データ運用ルール”を作る📜✨

この章は「え、DB消えた😭」「どこまで消していいの？😵」を卒業して、自分の開発に合った“データの扱いルール”を1枚にまとめる回だよ〜！💪😆

1) 今日のゴール🎯✨​

  • ✅ 消してOK / 消したら死ぬを仕分けできる🧠
  • ✅ **戻し方（復旧手順）**が決まってる📦
  • ✅ 初期データ（seed）方針が決まってる🌱
  • ✅ 危険コマンドにビビらなくなる🧯😄

2) まずはデータを4種類に分けよう📦🧺​

「全部大事そう」に見えるのが事故の元😇 まずはざっくり4分類にしちゃう！

  1. **ソース（再生成しにくい）**🧑‍💻

    • 例：コード、README、設計メモ

  2. **設定（再生成できるけど手間）**🎛️

    • 例：.env、接続情報、ポート割り当て

  3. **実データ（失うと困る）**🛡️

    • 例：DBの中身、アップロードファイル

  4. **キャッシュ（消してOK）**🧹

    • 例：ビルド成果物、キャッシュ、ログなど

「ボリューム」は主に 3（実データ） を守るための器だよ〜📦✨ ボリュームはDockerが管理する永続データ置き場で、bind mountよりバックアップ/移行もしやすいよ、という位置づけ。(Docker Documentation)

3) 事故を避ける“超重要ルール”🧨（ここだけは覚えて！）​

✅ “down” と “down -v” は別世界😱​

  • docker compose down → 基本はコンテナとネットワーク中心（ボリュームは基本残る） ただし anonymous volume は「削除はされないけど、次のupで自動で戻らないことがある」ので、永続したいデータは named volume や明示パスにしよう、という注意があるよ。(Docker Documentation)

  • docker compose down -v（=--volumes） → Composeファイルの volumes: で宣言された named volume も消す😇 つまり「DB初期化」のつもりでやると、普通にDBが飛ぶ💥(Docker Documentation)

✅ “external: true” のボリュームは守られやすい🛡️​

Composeで external 扱いのボリュームは、compose down で消されないよ。(Docker Documentation) さらにComposeの volumes には external: true があり、ライフサイクルをCompose外で管理できる（存在しないとエラー）って定義もあるよ。(Docker Documentation)

✅ prune は“掃除”だけど、データ破壊にもなり得る🧹🧨​

  • docker volume prune は「未使用ボリューム削除」 しかも デフォルトは anonymous volume だけ（-a で未使用namedも対象）って仕様だよ。(Docker Documentation)
  • docker system prune はボリュームをデフォルトでは消さないけど、--volumes を付けると対象になるよ😱(Docker Documentation)

4) ハンズオン：Todo API 用「データ運用ルール」を1枚で作ろう📝✨​

Step A：今のデータの置き場所を“見える化”👀​

まずは現状確認（これだけで安心感が爆上がり）😄

## 起動中サービス確認
docker compose ps

## ボリューム一覧
docker volume ls

## どのコンテナがどのボリュームを使ってるか（ざっくり）
docker inspect <container_name> --format '{{json .Mounts}}'

Step B：「消してOK/NG」を決める（最短の考え方）⚖️​

Todo API（Node/TS）＋DB（Compose）の定番だと、こんな感じになりがち👇

  • ✅ 消してOK（いつでも作り直せる）🧹

    • node_modules（戦略次第）
    • dist/ などビルド成果物
    • logs

  • ⚠️ 消してOKだけど、復旧手順は必要🧯

    • 開発用DB（seedで戻せるならOK）

  • ❌ 消したら泣く（守る）😭

    • DBの永続ボリューム（特に“手作業で入れたデータ”）
    • アップロードファイル（画像など）

5) 1枚にまとめるテンプレ（そのままコピペOK）📜🧼​

ファイル名例：docs/data-policy.md

## データ運用ルール（個人開発 / Todo API）

## 1. データ分類（消してOK/NG）
- ソースコード：Gitで管理（消さない）
- 設定：.env（Gitには入れない / バックアップ対象）
- 実データ：
  - DB：named volume（例：todo-db-data）【消したら死ぬ】
  - アップロード：named volume（例：todo-uploads）【消したら死ぬ】
- キャッシュ：
  - node_modules：方針A（後述）
  - ビルド成果物：消してOK
  - ログ：消してOK（必要なら別途保存）

## 2. ボリューム一覧（このPJで守るもの）
- todo-db-data：DB永続（守る）
- todo-uploads：アップロード永続（守る）

## 3. 初期化（DBをまっさらにしたい時）
- 手順：
  1) バックアップを取る（必要なら）
  2) DBだけ初期化する（安全な方法を選ぶ）
  3) seed を流す（任意）

## 4. バックアップ＆復旧（最短）
- バックアップの置き場所：./backups/
- バックアップ頻度：週1（＋大きい変更の前）
- 復旧テスト：月1で1回はやる（ミニ演習）

## 5. 危険コマンド（実行前に深呼吸）
- docker compose down -v（ボリューム消える）
- docker system prune --volumes（未使用ボリューム消える）
- docker volume prune -a（未使用namedも消える）

## 6. node_modules 方針（どれか1つに固定）
- 方針A：コンテナ内に保持（volumeで保持）
- 方針B：毎回インストール（遅いがシンプル）
- 方針C：ホスト側（Windows/WSLの相性で注意）

6) “戻し方”の型を2つ持つと最強💪😆​

型①：ボリュームを丸ごとバックアップ（tar）📦💾​

「とにかく丸ごと保険」って感じ。Docker公式の例でも --volumes-from でマウントして tar が紹介されてるよ。(Docker Documentation)

例（考え方）：

  • 一時コンテナを起動
  • ボリュームを /dbdata にマウント
  • カレントを /backup にマウント
  • tarで固める

※プロジェクト構成に合わせて、あなたの volume 名に置き換えて使う感じね😊

型②：DBの論理バックアップ（pg_dump / mysqldump）🗃️✨​

「DBとして正しい形で保存」できるのが強み👍 （復旧テストもしやすい！）

例（PostgreSQL想定）：

## backups/ に吐き出す（-T はリダイレクト事故防止に便利）
mkdir -p backups
docker compose exec -T db pg_dump -U postgres -d todo > backups/todo.sql

復旧：

docker compose exec -T db psql -U postgres -d todo < backups/todo.sql

※DBコンテナ名（ここでは db）やユーザー/DB名は compose に合わせてね😊

7) “消す系”を安全運用にする3点セット🧯✅​

① 重要ボリュームは external に寄せる（できれば）🛡️​

Composeの volumes: は、複数サービスで使い回せる named volume を定義できるよ。(Docker Documentation) その中で external: true を使うと「これは外部管理です」って扱いにできる。(Docker Documentation) さらに external のネットワーク/ボリュームは compose down で消えない、という説明もある。(Docker Documentation)

② backups/ を作って “置き場固定” 📁​

  • backups/ は .gitignore で管理
  • 「ここに入ってればOK」って状態にする😄

③ “復旧テスト” を月1でやる（5分でいい）⏱️​

バックアップは「取る」より「戻せる」が大事🔥 たまに戻して「動く！」を確認すると、安心感が段違い✨

8) AI活用（この章の勝ちパターン🤖✨）​

🧠 ルール文章を読みやすくしてもらう​

  • 「この data-policy.md を、初心者でも迷わないチェックリスト形式に整形して」
  • 「危険コマンドの説明を、短くて刺さる注意書きにして😇」

🧪 復旧テスト手順を作ってもらう​

  • 「todo.sql を使って復旧テストする手順を、ミスしにくい順番で書いて」

🔍 自分の構成に合わせて最適化​

  • 「私の compose.yml はこう。守るべきボリュームと、初期化手順のおすすめを提案して」

9) ミニ理解度チェック✅🎓​

  1. docker compose down -v が危ない理由は？😱
  2. docker system prune に --volumes を付けると何が変わる？🧹
  3. “復旧テスト” が大事なのはなぜ？🧪

（答え）

  1. named volume も消えるから💥(Docker Documentation)
  2. ボリュームもprune対象になるから😇(Docker Documentation)
  3. “戻せないバックアップ”が一番悲しいから😭✨

10) おまけ：Docker Desktop丸ごとバックアップ視点🧳🖥️​

「PC移行」「Docker Desktop壊れた」みたいな話になると、Docker Desktop自体のバックアップ/復旧手順も公式にまとまってるよ。(Docker Documentation) ただし ボリュームの中身は別途バックアップが必要、という注意もあるので、基本はこの章のルール（ボリューム運用＋バックアップ）を作っておくのが強い💪(Docker Documentation)

次の章（ネットワーク編）に行く前に、data-policy.md が1枚できてたら勝ち！🏆🎉 もしよければ、あなたの compose.yml の volumes周りだけ貼ってくれたら、**「守るべきもの」と「安全な初期化手順」**をその場で最適化して提案するよ〜😄👍