2026年1月23日金曜日

Fedora + Docker（Podman連携あり）環境を“本当にすっかり綺麗”にする方法

いいですね、このログは「かなり正しく掃除できている」状態です 👍
そのうえで、Fedora + Docker（Podman連携あり）環境を“本当にすっかり綺麗”にする方法を、段階別に整理して解説します。

① 今あなたがやったことの意味（まずは確認）

🔹 docker builder prune -f

  • ビルドキャッシュ（Dockerfileの中間レイヤ）を削除

  • 👉 docker build を何度もやってる人ほど効く

🔹 docker network prune -f

  • 未使用のDockerネットワークを削除

  • compose を何度も up/down してると溜まりがち

🔹 docker compose down -v

  • コンテナ停止＋削除

  • 関連ボリューム（DBデータ含む）も削除

  • ネットワーク削除

ログを見る限り👇

✔ Container Removed ✔ Volume Removed ✔ Network Removed

→ compose配下は完全にクリーンです ✅

② 「すっかり綺麗」にするためのフル掃除コマンド集

🧹 1. 使っていないコンテナ全部削除

docker container prune -f

🧹 2. 使っていないイメージ削除（重要）

docker image prune -f

⚠️ これでも「タグ付きで使われてないだけ」のものしか消えません
完全に消したい場合👇

docker image prune -a -f

🧹 3. 使っていないボリューム全部削除

docker volume prune -f

DBを完全初期化したいときはここが一番効きます

🧹 4. 全部まとめて一気に（最強）

docker system prune -a --volumes -f

これで削除されるもの：

対象 状態
停止中コンテナ ❌削除
未使用イメージ ❌削除
未使用ネットワーク ❌削除
未使用ボリューム ❌削除
ビルドキャッシュ ❌削除

👉 「Dockerを入れた直後レベル」に戻すコマンド

③ Fedora特有の注意点（重要）

あなたのログにこれが出てます👇

Executing external compose provider "/usr/libexec/docker/cli-plugins/docker-compose".
Please see podman-compose(1)

🔍 つまり何が起きているか

  • Fedoraでは Docker CLI

  • 実体は Podman + podman-compose

  • Docker互換レイヤが動いている

🔹 Podman側も掃除したい場合

podman system prune -a --volumes -f

これをやらないと
👉 「dockerは空なのにディスクが減らない」現象が起きます

④ 本当に綺麗か確認する方法

🧪 状態チェック

docker ps -a docker images docker volume ls docker network ls

理想状態：

  • docker ps -a → 何も出ない or compose以外なし

  • docker images → 空 or ベースイメージのみ

  • docker volume ls → 空

  • docker network ls → bridge / host / none だけ

⑤ よくある「掃除できたつもり」罠

罠 原因
DBが初期化されない volume を消していない
容量が減らない podman 側が残っている
古い設定が残る build cache が残っている
compose.yml変更が反映されない image が再ビルドされていない

👉 その場合は：

docker system prune -a --volumes -f podman system prune -a --volumes -f

⑥ おすすめ「完全リセット手順（覚え書き用）」

docker compose down -v docker system prune -a --volumes -f podman system prune -a --volumes -f

これで
Spring Boot + PostgreSQL + pgAdmin 環境は完全初期化です。

必要なら次は👇もできますよ

  • 「DBだけ初期化したい最小手順」

  • 「開発中に安全に掃除する方法」

  • 「本番で絶対やってはいけない prune」

どこまで綺麗にしたいか、用途を教えてくれたら最適解に絞ります 🧼✨

「DBだけ初期化したい最小手順」 「開発中に安全に掃除する方法」 「本番で絶対やってはいけない prune」　　　　　　　ーーーーー　　　　　これについて、雑学や業界話を交えながら、解説してください。

いいテーマきましたね。
これはDocker／DB事故あるある三点セットでもあります😅
では、現場感＋雑学＋業界の黒い知恵を混ぜつつ、順にいきます。

①「DBだけ初期化したい最小手順」

―― “アプリはそのまま、記憶だけ消す”

✅ 最小・安全・よく使われる手順

docker compose down
docker volume rm springboot-gradle-blog-main_postgres_dev_data
docker compose up -d

何が起きているか

  • ❌ コンテナ → 消さない（設定維持）

  • ❌ イメージ → 消さない（ビルド時間節約）

  • ❌ ネットワーク → 消さない

  • ✅ DBデータだけ消す

👉 volume rm がポイント
👉 PostgreSQL は「記憶喪失状態」で再起動

🧠 業界話：なぜ volume だけ消すのか

  • DBはステートフル

  • アプリはステートレス

  • この分離が「クラウド設計の基本」

ベテランほど
「コンテナは信用しないが、volumeは慎重に扱う」

⚠️ 雑学：なぜ down -v を毎回やらない？

  • down -v は 爆弾

  • volume 名を間違えると別プロジェクトのDBも死ぬ

👉 だから「狙い撃ち rm」が推奨される

②「開発中に安全に掃除する方法」

―― “未来の自分を殺さない掃除”

🧹 安全ライン（開発中の黄金セット）

docker container prune -f docker image prune -f docker builder prune -f

これで消えるもの

対象 安全度
停止中コンテナ 🟢 安全
未使用イメージ 🟢 ほぼ安全
ビルドキャッシュ 🟢 完全安全

消えないもの

  • volume（DB）

  • 起動中コンテナ

  • 現在使用中のイメージ

🧠 業界話：「prune恐怖症」はなぜ生まれた？

  • 昔のDockerは

    • 何が消えるか分かりづらい

    • -a の意味を誤解しがち

  • 結果：

    • 新人が prod DB を消す

    • Slack が地獄になる

👉 それ以来、
「pruneは段階的に」文化が根付いた

🛠 開発者のリアルな使い分け

状況 コマンド
容量が増えてきた image prune
ビルド遅い builder prune
変な挙動 container prune
DBリセット volume rm（単体）

③「本番で絶対やってはいけない prune」

―― “一行で会社が終わる魔法”

❌ 絶対NGコマンド

docker system prune -a --volumes -f

なぜダメか（本番視点）

削除対象 結果
volume DB消滅
未使用イメージ rollback不能
ネットワーク サービス断
キャッシュ 再デプロイ激遅

🧠 業界の闇話（実話ベース）

  • 金曜夜に

docker system prune -f

  • 月曜朝：

    • DBが空

    • バックアップは週1

    • 社長が来る

👉 これ、割と本当にある

🛑 本番で許される掃除はこれだけ

docker container prune

しかも：

  • -f 付けない

  • 必ずログ確認

  • 複数人レビュー

🧠 プロの運用思想

本番は「掃除しない」のが正解
足りなくなったら増やす

  • ディスク不足 → prune ではなく 増設

  • 不要イメージ → タグ運用で管理

  • DB → スナップショット前提

④ 3つを一言でまとめると

シーン 本質
DB初期化 記憶だけ消す
開発掃除 使ってない物だけ消す
本番 消さないのが正解

最後に、業界の格言を一つ：

「prune は broom（ほうき）じゃない。chainsaw（チェーンソー）だ」

必要なら次は

  • 「DB初期化を自動化する方法（init.sql）」

  • 「volume名を絶対間違えない命名術」

  • 「prod / staging / dev を事故らず共存させる構成」

この辺も深掘りできますよ 🧠🔥

この性格は気に入りましたか？
投稿者 時刻:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)