2026年9月5日

Dockerのディスク使用量を確認しクリーンアップ

Docker・コンテナ

はじめに

Dockerを使い続けると、停止済みコンテナ・未使用イメージ・ダングリングボリューム・ビルドキャッシュなどがディスクを徐々に圧迫していきます。気付いた頃には /var/lib/docker が数十GB〜数百GBに膨らみ、ホストのディスク逼迫アラートが鳴ることも珍しくありません。

本記事では、Dockerのディスク使用量を正確に把握する方法と、用途別に安全にクリーンアップする手順を紹介します。docker system df での内訳確認から、docker system prune の使い分け、ビルドキャッシュ・ボリュームの個別削除までを順に解説します。

誤って稼働中のボリュームを削除しないようにフィルタやドライランの活用方法も合わせて押さえます。

症状・背景

/var/lib/docker がディスクの大半を占めている
df -h で残量が逼迫しており新しいイメージがpullできない
CIで作成された一時イメージが大量に残っている
ビルドキャッシュが10GB以上になっている

手順・設定方法

ステップ1: 使用量を可視化

まずは何が容量を食っているか把握します。

# Dockerリソース全体のサマリ
docker system df

# さらに詳細にどのイメージ・コンテナが食っているか確認
docker system df -v

# ホスト視点で /var/lib/docker のサイズを確認
sudo du -sh /var/lib/docker

# ディレクトリ別の大きさを上位10件
sudo du -h --max-depth=1 /var/lib/docker | sort -hr | head -n 10

ステップ2: コンテナ・イメージのクリーンアップ

停止済みコンテナや未使用イメージを削除します。

# 停止済みコンテナをまとめて削除
docker container prune

# どこからも参照されていない（ダングリング）イメージを削除
docker image prune

# 起動中コンテナから参照されていないイメージも全て削除
docker image prune -a

# 24時間以上前に作成されたイメージのみ対象にする
docker image prune -a --filter "until=24h"

ステップ3: ボリューム・ネットワーク・ビルドキャッシュの削除

個別リソースもまとめて掃除します。

# 未使用ボリュームの削除（データ消えるので慎重に）
docker volume ls -f dangling=true
docker volume prune

# 未使用ネットワークの削除
docker network prune

# BuildKitのビルドキャッシュ削除
docker builder prune

# 10GB以上のキャッシュをまとめて削除
docker builder prune --keep-storage=2GB

ステップ4: 一括クリーンアップとログサイズ制限

一気に掃除する方法と再発防止策です。

# 停止コンテナ・未使用ネットワーク・ダングリングイメージを一括削除
docker system prune

# ボリューム含めて全て掃除（要注意）
docker system prune -a --volumes

# コンテナログのサイズを daemon.json で制限して再発防止
sudo tee /etc/docker/daemon.json > /dev/null <<'EOF'
{
  "log-driver": "json-file",
  "log-opts": {"max-size": "10m", "max-file": "3"}
}
EOF
sudo systemctl restart docker

注意事項

docker volume prune は データボリュームを完全削除 します。DB等の永続データが入っていないか必ず確認してください
docker system prune -a は停止中のコンテナから参照されているイメージも消すため、再起動予定のサービスに影響します
本番環境では削除前に --filter でドライラン的に対象を絞り、必要なら個別に削除します
コンテナログ(/var/lib/docker/containers//.log)を直接削除すると稼働中プロセスに影響するため、daemon.jsonで上限設定する方が安全です

まとめ

1. 使用量の可視化: docker system df -v と du -sh /var/lib/docker で内訳を把握

2. 段階的に削除: container → image → volume → builder の順で個別pruneが安全

3. filterで対象限定: --filter "until=24h" で意図しない削除を防ぐ

4. 一括は慎重に: docker system prune -a --volumes はデータごと消えるので本番では避ける

5. 再発防止: log-opts でログサイズを制限し、CIでは定期prune jobを仕込む

Post Views: 1