ディスクが増える原因の特定（docker system df / ログ / ボリューム）

ディスクが増える原因の特定（docker system df / ログ / ボリューム）
読了時間: 約10分 難易度: 中級

この記事で解決できること

  • Docker環境でディスク使用量が増えたとき、どこが増えているか特定できます
  • docker system df で「イメージ/コンテナ/ボリューム」のどれが原因か当たりを付けられます
  • 削除で事故る前に、まず"安全に確認する手順"が分かります

結論（最短）

Dockerのディスク増加は、まずこれで切り分けるのが最短です。

  1. df -h で埋まっている領域を確認
  2. docker system df で Docker がどれだけ使っているか確認
  3. docker system df -v で内訳の当たりを付ける
  4. ログ肥大（コンテナログ）とボリューム肥大のどちらかを疑う

※ この記事は「特定」までに寄せます。削除は事故りやすいので慎重に進めます。

前提（対象環境）

  • OS：Ubuntu
  • Dockerが導入済み
  • 権限：Docker操作のため docker が使えるユーザー、または sudo が使える想定

1. まず本当にディスクが埋まっているか確認（df）

結論: df -hでマウントポイントを特定してからDockerが原因かどうかを判断するのが最初の一手。

Dockerが原因かどうかの前に、どこが埋まっているかを確認します。

$ df -h

よくある例

  • / が満杯（Dockerのデータがルート配下にあることが多い）
  • /var が別パーティションで満杯（/var/lib/docker が効いている可能性）

2. Dockerがどれくらい使っているかを見る

結論: docker system dfでImages/Containers/Volumes/Build Cacheのどれが容量を食うかをまず把握する。

まずは全体の当たりを付けます。

$ docker system df

注目する項目

  • Images：イメージが溜まっていないか
  • Containers：停止コンテナが溜まっていないか
  • Local Volumes：ボリュームが肥大していないか
  • Build Cache：ビルドキャッシュが溜まっていないか

"どれが大きいか" が分かるだけでも、次の調査が一気に楽になります。

3. どのデータが増えているかの当たりを付ける

結論: /var/lib/dockerをdu -h -d 1で確認し増えているサブディレクトリを特定するのがDocker起因切り分けの定石。

Dockerのデータは典型的にはここにあります（環境により異なる場合があります）。

  • Docker本体データ：/var/lib/docker
  • コンテナログ：/var/lib/docker/containers/<container-id>/*.log

まずは /var/lib/docker のサイズを確認します。

$ sudo du -h -d 1 /var/lib/docker | sort -h

ここで /var/lib/docker が大きいなら、Docker起因の可能性が高いです。

4. コンテナログ（jsonログ）が肥大していないか確認

結論: containers配下のサイズとjsonログの巨大ファイルをfindで確認しログ肥大かどうかを判断する。

Dockerはデフォルトでコンテナの標準出力/標準エラーをログとして溜めます。ログが出続けると、ここが膨らみます。

4-1. containers 配下のサイズを見る

$ sudo du -h -d 2 /var/lib/docker/containers | sort -h | tail -n 20

4-2. 大きいログファイルを探す（上位20件）

$ sudo find /var/lib/docker/containers -type f -name "*.log" -printf "%s %p\n" | sort -n | tail -n 20

ここで巨大な *-json.log が見つかったら、ログ肥大が原因候補です。

5. どのコンテナが原因か特定する

結論: ログパスのコンテナIDをdocker ps -aとdocker inspectで名前に変換しコンテナを特定する。

ログパスに含まれるコンテナID（長い文字列）から、コンテナ名を引けます。

5-1. コンテナ一覧を表示（IDと名前）

$ docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Status}}\t{{.Image}}"

5-2. あるコンテナIDの詳細を見る

$ docker inspect <container-id> --format '{{.Name}}'

※ .Name は先頭に / が付くことがあります。

6. ボリュームが肥大しているか確認

結論: docker volume lsとdocker ps --format Mountsでどのコンテナがどのボリュームを使っているかを把握する。

DBやWordPressのアップロード、キャッシュなどはボリュームに溜まりがちです。

6-1. ボリュームの一覧

$ docker volume ls

6-2. どのボリュームを誰が使っているか

$ docker ps -a --format "table {{.Names}}\t{{.Mounts}}"

ここで「どのコンテナがどのボリュームを掴んでいるか」の方向性が見えます。

7. 事故らないための注意点（重要）

結論: docker system pruneは一発事故の元になるためボリュームとログの原因を特定してから最小限の削除にとどめる。

ログ肥大は根本原因の調査が必要

ログを出している原因が残っていると再発します。

応急処置の考え方

もし原因がログ肥大だった場合の次の打ち手は、だいたいこのどれかです。

  • ログローテーション設定（Dockerのlogging driver / log-opts で上限）
  • アプリ側のログ量の見直し（エラー連発やデバッグログ）
  • 監視/収集（必要なログは別経路に流す）

削除での対処は "一時しのぎ" になりがちなので、原因を止める方が長期的に安定します。

確認（直ったかチェック）

結論: 調査や応急対応の後はdf -hとdocker system dfで空きが改善されているか確認する。

調査や応急対応の後は、まずここで改善を確認します。

$ df -h
$ docker system df

次に読む