Skip to main content

第28章：チーム/複数PCを見据える：データの“持ち運び”設計🚚

この章のゴールはシンプルです👇 **「新しいPCに移っても、迷わず同じ状態を再現できる」**ようにします✅ （＝“バックアップがある”じゃなくて、“復元できる設計”にするやつ！😆）

0) まず結論：持ち運びは「3つの荷物」に分ける📦📦📦​

持ち運ぶものはだいたいこの3種類です👇

  1. **定義（再現レシピ）**🍳 Composeファイル / Dockerfile / init / migrations / seed / README など
  2. **データ（中身）**🧠 DB、アップロードファイル、検索インデックス、など
  3. **環境まるごと（最終手段）**🧰 Docker Desktopの“丸ごと移行”みたいなやつ（第27章寄り）

この章は 1 + 2 を強くするのが主役です💪✨ 「環境まるごと」はラクだけど、チーム開発だと再現性が弱くなりやすいので“非常口”扱いが吉です🚪🆘（Docker Desktopのバックアップ/リストア手順は公式にもあります）(Docker Documentation)

1) “新PCで詰む”最大原因：Composeの名前がズレる😇💥​

✅ ズレると何が起きる？​

Composeはデフォで フォルダ名をプロジェクト名にします。 すると volume名やcontainer名にプレフィックスが付くので、PCや人によって名前が変わりがちです🤯 （例：myproj_db-data になったり、sample_db-data になったり…）

これは公式でも「プロジェクト名はディレクトリ名がデフォ」と明記されています。(Docker Documentation)

2) 解決策：名前を“固定”して持ち運べるようにする🧷✨​

2-1) プロジェクト名を固定する（おすすめ）📛​

プロジェクト名は -p / COMPOSE_PROJECT_NAME / Composeファイルの name: などで上書きできます。(Docker Documentation)

**いちばん事故りにくいのは「Composeファイルに name: を書く」**です👇

## compose.yaml
name: myapp

services:
  db:
    image: postgres:17
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data: {}

2-2) volume自体の“実名”も固定する（さらに強い）🔩​

Composeの volumes: で name: を指定すると、実際のvolume名を固定できます。 .env から差し替えもできます。(Docker Documentation)

## compose.yaml
name: myapp

services:
  db:
    image: postgres:17
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:
    name: ${DATABASE_VOLUME:-myapp_db_data}

これで👇

  • フォルダ名が変わってもOK🙆‍♂️
  • チーム全員で同じvolume名にできる🙆‍♀️
  • 復元先の“入れ物”が一致して迷子にならない🧭✨

3) そもそも「volume」は持ち運び向き？🤔➡️✅​

結論：持ち運びの“箱”としては優秀です📦 理由：bind mountはホストのディレクトリ構造やOSに依存しがちだけど、volumeはDocker管理で安定しやすいからです。(Docker Documentation)

そしてDocker公式は volumeのバックアップ/リストア（tar）手順も案内しています。(Docker Documentation)

4) “持ち運びパック”を作る：最低限これだけ揃えよう🎒✨​

おすすめの構成👇（これがあると新PCで勝てる🏆）

  • compose.yaml（name固定、volume名固定）📌
  • .env.example（秘密は入れない）🧾
  • init/（初期化SQLなど）🌱
  • migrations/（履歴で管理）📜
  • scripts/backup.ps1（Windowsで回る）⚙️
  • scripts/restore.ps1（Windowsで回る）🧯
  • docs/restore-checklist.md（チェックリスト）✅

5) 実践：volumeをtarで“持ち運べるファイル”にする🧳🗜️​

重要：DBをバックアップするなら、基本は「DBを止める/書き込みを止める」ほうが安全です🧯 ここでは分かりやすく docker compose stop を使います（本番は章14〜18の方針に寄せるとさらに堅い👍）

5-1) バックアップ（PowerShell）💾​

## scripts/backup.ps1
$ErrorActionPreference = "Stop"

$vol = $env:DATABASE_VOLUME
if ([string]::IsNullOrWhiteSpace($vol)) { $vol = "myapp_db_data" }

$stamp = Get-Date -Format "yyyyMMdd-HHmmss"
New-Item -ItemType Directory -Force -Path ".\backup" | Out-Null

## 例：DBを止めてから取る（安全寄り）
docker compose stop db

docker run --rm `
  -v ${vol}:/volume:ro `
  -v "${PWD}\backup:/backup" `
  alpine:3.20 `
  sh -c "cd /volume && tar -czf /backup/${stamp}-${vol}.tar.gz ."

docker compose start db

Write-Host "✅ Backup created: backup\${stamp}-${vol}.tar.gz"

このやり方は「一時コンテナでvolumeをマウントしてtarで固める」方式で、公式のvolumeバックアップ/移行の考え方に沿っています。(Docker Documentation)

5-2) リストア（PowerShell）🧯​

## scripts/restore.ps1
$ErrorActionPreference = "Stop"

$archive = $args[0]
if ([string]::IsNullOrWhiteSpace($archive)) {
  throw "Usage: .\scripts\restore.ps1 backup\yyyyMMdd-HHmmss-myapp_db_data.tar.gz"
}
if (!(Test-Path $archive)) { throw "Archive not found: $archive" }

$vol = $env:DATABASE_VOLUME
if ([string]::IsNullOrWhiteSpace($vol)) { $vol = "myapp_db_data" }

## まず箱（volume）を作る
docker volume create $vol | Out-Null

## DBを止めてから戻す（安全寄り）
docker compose stop db

docker run --rm `
  -v ${vol}:/volume `
  -v "${PWD}:/work" `
  alpine:3.20 `
  sh -c "rm -rf /volume/* && tar -xzf /work/$archive -C /volume"

docker compose start db

Write-Host "✅ Restore done into volume: $vol"

6) 新PCで復元する手順（チーム/複数PCの“勝ち筋”）🥳✅​

ステップA：定義を持ってくる📦​

  1. Gitでクローン（同じブランチ）🌿
  2. .env.example をコピーして .env 作成（秘密は別管理）🔑
  3. docker compose pull or docker compose build 🧱

ステップB：データを戻す💾​

  1. backup/*.tar.gz を新PCへ持ってくる（共有ドライブ/クラウドでもOK）☁️
  2. .\scripts\restore.ps1 backup\xxxxx.tar.gz を実行🧯

ステップC：起動して確認🔥​

  1. docker compose up -d 🚀
  2. アプリの疎通（API叩く/画面開く）🌐
  3. DBの中身チェック（件数/ユーザー/seed）🔎

7) 成果物：新PCで復元できるチェックリスト✅📝​

これを docs/restore-checklist.md に貼って完成🎉

  • Composeの name: が固定されてる📛

  • volumes: xxx: name: でvolume実名も固定されてる🔩(Docker Documentation)

  • .env.example があり、秘密は入ってない🔒

  • scripts/backup.ps1 が動く💾

  • scripts/restore.ps1 が動く🧯

  • 復元後に docker compose up -d で起動できる🚀

  • 復元テストの“確認項目”がある（3つでOK）🔎

    • 画面表示OK
    • 主要API 1本OK
    • DBの件数が想定どおりOK

8) ありがち事故パターン集（先に潰す）🪤😇​

事故①：新PCで起動したけど“データが空”😱​

原因：別のvolume名を見てるパターンが多いです。 対策：name: 固定 + volume実名固定（上の2-2）が最強です🔩✨(Docker Documentation)

事故②：WindowsでファイルIOが遅くてつらい🐢​

対策：ソースを WSL2のファイルシステム側に置くと改善しやすいです。VS Codeの案内にもあります。(Visual Studio Code)

事故③：チームメンバーごとに微妙に動きが違う🤏💥​

対策：イメージのタグを固定（例：postgres:17 みたいに）🧷 さらに堅くするなら digest 固定もあるけど、まずはタグ固定でOK👍

9) AI（Copilot/Codex等）を使うと爆速になるポイント🤖⚡​

  • ✅ backup.ps1 / restore.ps1 の雛形を作らせる
  • ✅ チェックリストを「抜け漏れ探し」させる
  • ✅ “復元後の確認項目”を3つに絞らせる

ただし⚠️ バックアップファイルや .env の中身をそのまま貼るのは危険なので、値を伏せた形で投げるのが安全です🔒

10) ミニ演習（15分）⏱️🎮​

  1. Composeに name: を入れる📛
  2. volumeに name: を入れて実名固定🔩
  3. scripts/backup.ps1 と scripts/restore.ps1 を置く⚙️
  4. いったん backup を取る💾
  5. docker compose down → restore → up を回して復元確認🧯🚀

これが回れば、もう“複数PC移行こわい問題”はかなり卒業です🎓✨

必要なら、この章の内容に合わせて「あなたの教材の第29章（AIガードレール🛡️🤖）」へ自然につながる形で、**“AIに貼ってOKな情報/ダメな情報テンプレ”**も一緒に作れますよ😉