1) Dockerの“構成”を一枚で掴む

コンテナの概念は分かってる前提で、運用で登場する要素はだいたいこれだけ。

• Image（イメージ）：アプリ＋実行環境の“設計図”
• Container（コンテナ）：イメージを実行した“プロセス”
• Volume（ボリューム）：コンテナ外に永続化する“データ置き場”（DBなど）
• Bind mount（バインドマウント）：ホストの特定フォルダをそのままコンテナに見せる（開発で多い）
• Network（ネットワーク）：コンテナ同士の通信路（composeだと勝手に作られる）
• Compose（docker compose）：複数コンテナ構成をYAMLで管理する道具

2) 典型構成：Web + DB（Compose）

ざっくりこうなる。

• web コンテナ：Flask / Node / Nginx / etc
• db コンテナ：Postgres / MySQL / etc
• volume：dbデータ永続化
• （必要なら）nginx：リバプロ、TLS終端

この時、メンテが楽な構成はだいたいこういう原則：

• DBのデータは 必ず volume
• アプリの設定は 環境変数（.env）
• 機密は secrets（余裕があれば）
• ログは「まず stdout/stderr → docker logs」で集約（凝るのは後）

3) データの取り出し・出し入れ（現場で困る所）

A. コンテナ内のファイルを“ちょっと”取り出す

応急処置としては docker cp が最短。

• コンテナ → ホスト：docker cp <container>:/path/in/container ./localdir
• ホスト → コンテナ：docker cp ./localfile <container>:/path/in/container

B. “永続データ”の正攻法

DBやユーザアップロードは、コンテナ内に閉じ込めない。

• DB：volume（例 pgdata:）
• アップロード：bind mount（例 ./uploads:/app/uploads）か volume

理由：コンテナ作り直してもデータが残るから。

C. DBバックアップ（超重要）

Postgresなら典型はこれ（概念だけ）：

• pg_dump で論理バックアップ（SQL/カスタム形式）
• pg_restore で戻す

MySQLなら mysqldump。

4) メンテの基本ルーチン（これだけで事故が減る）

状態確認

docker ps
docker ps -a
docker logs -f <container>
docker stats

構成確認（Compose前提）

docker compose config
docker compose up -d
docker compose down

更新（イメージ更新 → 再作成）

docker compose pull
docker compose up -d

5) 事故りがちなポイント（ここだけ覚えれば勝率上がる）

① 「コンテナ消したらデータ消えた」

→ それは コンテナ内にデータを置いてた。DBはvolumeへ。

② 「compose down したらDB初期化された」

→ down -v してしまった、または volume 設定が無い/間違い。

③ 「ログがどこにあるかわからない」

→ まず docker logs。

ファイルに書く設計にすると、ログローテなど別の地獄が始まる。

④ 「ディスクが死ぬほど増える」

→ 不要イメージ・ビルドキャッシュ・停止コンテナが溜まってる。

docker system df
docker system prune
docker system prune --volumes

6) あなたが次に覚えるべき“運用の型”

ここまでを踏まえると、運用が安定する“型”はこれ。

1. アプリはstateless（捨てても復旧できる）
2. 状態（DB/アップロード/設定）は外出し
3. バックアップは DBダンプ + アップロード領域の同期
4. 更新は pull → up -d（再作成）
5. 監視は logs / healthcheck / restart policy

7) ここから先、あなたの環境に合わせて最短で刺す（情報があれば）

今の理解を一気に実運用に落とすには、次のどれかが分かると「あなたの現場用の運用手順（コマンド一式）」を作れる。

• 使ってるのは docker compose？それとも docker run 直？
• 何を動かしてる？（例：Flask + Postgres + Traefik / CVAT / etc）
• 永続化したいデータは何？（DB、アップロード、設定ファイル、学習データ…）

8) 「他者が作ったものが中にあったら？」：3パターン

「他者が作ったものが“コンテナの中”にある」は大きく3パターン。扱い方が違う。

パターン1：それは“アプリ本体”（＝イメージに含まれる不変物）か？

例：/usr/bin/...、/app の実行コード、ライブラリ、OS系ファイル。

• これは中にあってOK（むしろあるべき）
• 運用でやることは 編集しない・タグ固定/できればdigest固定・更新は入れ替え

パターン2：それは“状態データ”（＝本来は外に出すべき）か？

例：DBデータ、アップロード、学習データ、設定の書き換え結果、生成物、永続ログ。

この場合は 外出しに移行する（手順は次章）。

パターン3：誰かが“コンテナ内で手作業で編集した”やつ（＝スノーフレーク）か？

これが一番厄介。次の入れ替えで消えるから。

まず 何が変更されたかを出す：

docker diff <ctr>

9) 状態データを外出しへ移行する手順（引っ越し）

「既に中にデータがある状態」から volume に引っ越す典型手順（これで9割いける）。

1) どこがデータか特定

まずマウント状況を見る（既に外出し済みか確認）。

docker container inspect <ctr> --format '{{range .Mounts}}{{println .Type .Destination "->" .Source}}{{end}}'

どこが太ってるか見る（だいたいデータはデカい）。

docker exec -it <ctr> sh -lc 'du -sh /* 2>/dev/null | sort -h | tail'

2) コンテナ停止（DB系は特に）

docker stop <ctr>

3) volume作成

docker volume create mydata

4) 中のデータを一旦ホストへ退避

docker cp <ctr>:/path/in/container ./dump

5) volumeへ投入（一時コンテナでコピー）

docker run --rm -v mydata:/data -v "$PWD/dump":/dump alpine sh -lc 'cp -a /dump/. /data/'

6) compose.yml / docker run にマウントを追加して再起動

compose例：mydata:/path/in/container

10) 手作業改変（スノーフレーク）対処：diff→回収→再現

一番厄介なケース。放置すると「誰も再現できない」「更新できない」が発生する。

まず変更差分の洗い出し

docker diff <ctr>

変更されたファイルをホストへ回収

docker cp <ctr>:/changed/file ./backup/

その後の正解はどっちか

• 設定ファイル類 → bind mount で差し替える（例：./config:/etc/app）
• アプリ側に変更が必要 → Dockerfileで再現して 自分の派生イメージにする

11) 結論（短く）＆貼ると具体化できる情報

もし今まさに困ってる対象があるなら、これだけ分かると「どこが外出し対象か」「引っ越し手順」を具体化できる：

• docker ps の対象コンテナ名
• docker container inspect <ctr> --format '{{range .Mounts}}{{println .Type .Destination "->" .Source}}{{end}}' の結果
• （可能なら）docker diff <ctr> の結果

貼れない場合は「どのソフトか（例：CVAT / Traefik / Postgres / 独自Flaskなど）」だけでも、典型の外出し先パスは当てにいける。