Docker image prune の使い方：ディスク容量を節約する基本

By /

Docker image prune の使い方：ディスク容量を劇的に節約する完全ガイド

はじめに：Docker環境におけるディスク容量の課題

現代のソフトウェア開発において、コンテナ技術であるDockerは不可欠なツールとなっています。アプリケーションの構築、配布、実行を標準化し、開発から本番環境までの一貫性をもたらします。しかし、Dockerを継続的に使用していると、予期せぬ問題に直面することがあります。その一つが、ディスク容量の枯渇です。

Dockerは、アプリケーションとその依存関係をパッケージ化した「イメージ」を基に「コンテナ」を実行します。開発やテストのために新しいイメージを頻繁にビルドしたり、リモートリポジトリから様々なイメージをプルしたりするうちに、ローカルストレージに大量のイメージが蓄積されていきます。

これらのイメージの中には、古いバージョン、テスト用の中間イメージ、ビルド中に生成されたが最終的にタグ付けされなかったもの（いわゆる「dangling images」）などが含まれます。これらの不要なイメージは、知らず知らずのうちに貴重なディスク容量を圧迫し、システムのパフォーマンス低下や新たなイメージのプル/ビルドの妨げとなる可能性があります。

ディスク容量の問題を解決するために、Dockerは様々なクリーニングコマンドを提供しています。その中でも、不要なイメージに関連するストレージを効率的に解放するための基本的なコマンドが docker image prune です。

この記事では、docker image prune コマンドに焦点を当て、その仕組み、使い方、オプション、そしてディスク容量を効果的に節約するためのベストプラクティスについて、詳細かつ網羅的に解説します。約5000語にわたるこのガイドを通じて、Docker環境におけるディスク容量管理の基本をしっかりと習得し、快適な開発・運用環境を維持できるようになることを目指します。

第1章：Dockerとディスク容量の問題を理解する

docker image prune の使い方に入る前に、なぜDockerがディスク容量を大量に消費するのか、そしてどのような要素が容量を圧迫するのかを理解することが重要です。

1.1 Dockerが使用する主なストレージ要素

Dockerがローカルストレージを使用するのは、主に以下の要素のためです。

  • Images (イメージ): コンテナの設計図となる読み取り専用のテンプレートです。OS、ライブラリ、アプリケーションコードなどが含まれます。イメージは複数の読み取り専用レイヤーで構成されており、これらのレイヤーがディスク容量を消費します。
  • Containers (コンテナ): イメージから起動される実行可能なインスタンスです。コンテナはイメージレイヤーの上に書き込み可能なレイヤー（コンテナレイヤー）を持ちます。実行中のコンテナや停止したコンテナのコンテナレイヤーはディスク容量を使用します。
  • Volumes (ボリューム): コンテナによって生成または使用されるデータを永続的に保存するための推奨されるメカニズムです。ボリュームはホストマシン上の特定のディレクトリにマッピングされ、コンテナのライフサイクルとは独立して存在します。
  • Build Cache (ビルドキャッシュ): イメージをビルドする際、Dockerはビルドステップの結果をキャッシュします。これにより、イメージの再ビルド時に変更がないステップをスキップして高速化できます。このキャッシュもディスク容量を消費します。
  • Networks (ネットワーク): コンテナ間の通信や外部との通信を可能にするための仮想ネットワーク設定です。これ自体が大きな容量を消費することは少ないですが、メタデータとしてストレージを使用します。

docker image prune は、これらの要素のうち Images (イメージ) に焦点を当てたクリーンアップツールです。ただし、イメージはレイヤー構造を持つため、イメージの削除は関連するレイヤーのディスク容量解放につながります。

1.2 Dockerイメージの構造とレイヤー

Dockerイメージは、複数の読み取り専用レイヤーを重ね合わせた構造になっています。Dockerfileの各命令（例: FROM, RUN, COPY, ADD）は、通常、新しいレイヤーを生成します。

“`dockerfile

Dockerfileの例

FROM ubuntu:latest # レイヤー1 (ベースイメージ)
RUN apt-get update && apt-get install -y some-package # レイヤー2
COPY . /app # レイヤー3
WORKDIR /app # レイヤー4 (メタデータレイヤー、容量は少ない)
CMD [“python”, “app.py”] # レイヤー5 (メタデータレイヤー、容量は少ない)
“`

このDockerfileからイメージをビルドすると、少なくとも5つのレイヤーが作成されます。これらのレイヤーは重ね合わされ、最終的なイメージとなります。

重要なのは、これらのレイヤーが 共有可能 であるという点です。例えば、ubuntu:latest をベースイメージとする別のイメージをビルドした場合、その新しいイメージは ubuntu:latest のレイヤーを再利用します。これにより、ディスク容量の重複を避けることができます。

しかし、イメージが削除されても、そのイメージが使用していたレイヤーが 他のどのイメージからも参照されなくなって初めて、そのレイヤーに関連するディスク容量が解放されます。

1.3 不要なイメージの種類：Dangling ImagesとUnused Images

Docker環境でディスク容量を圧迫するイメージには、主に以下の2種類があります。

1. Dangling Images (ダーリングイメージ、ぶら下がりイメージ)

これは最も一般的な不要なイメージの種類です。特定のタグが付けられていない、かつ、どのイメージからも参照されていない最下層（ベースレイヤーを除く）のイメージです。

どのような場合に発生するかというと、例えば新しいバージョンのイメージを同じタグでビルドまたはプルした場合です。古いバージョンのイメージは新しいイメージによってタグを「奪われる」形になり、どのタグとも関連付けられなくなります。しかし、そのイメージとその中間レイヤーはディスク上に残ります。

docker images コマンドを実行した際に、リポジトリ名とタグが <none>:<none> と表示されるイメージが、典型的なDangling Imageです。

bash
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
my-app latest abcdef123456 2 hours ago 200MB
ubuntu latest fedcba654321 3 weeks ago 70MB
<none> <none> 123456abcdef 5 hours ago 150MB # これがDangling Image

この <none>:<none> のイメージ (ID 123456abcdef) は、かつて my-app:latest だったイメージかもしれません。新しい my-app:latest がビルドされたため、古いものがタグを失い、Dangling Imageとなったのです。

Dangling Imagesは、ほとんどの場合、単にストレージを無駄にしているだけで、安全に削除できます。

2. Unused Images (未使用イメージ)

これは、どの 実行中のコンテナ からも使用されていないイメージです。Dangling Imagesとは異なり、これらのイメージにはタグが付いている場合があります。

例えば、my-app:v1 というタグが付いたイメージをプルまたはビルドした後、そのイメージからコンテナを起動することなく、my-app:v2 をプル/ビルドしてそちらからコンテナを起動したとします。この場合、my-app:v1 イメージはタグ付きで存在しますが、どの実行中のコンテナもそれを使用していないため、「未使用」と見なされます。

docker image prune のデフォルトの動作では、この種のタグ付きの未使用イメージは削除されません。削除の対象となるのは、デフォルトでは Dangling Images のみです。後述するオプションを使用することで、これらのタグ付きの未使用イメージも削除対象に含めることができます。

1.4 なぜ不要なイメージが蓄積されるのか？

不要なイメージが蓄積される主な原因は以下の通りです。

  • 頻繁なイメージの更新: アプリケーションコードやベースイメージの更新に伴い、新しいイメージを同じタグで頻繁にビルドまたはプルする場合。古いイメージが Dangling Image となります。
  • テストビルド: 様々な構成やブランチでテストイメージをビルドするが、タグを付けずに終了する場合。これらのテストビルドの中間レイヤーや最終イメージが Dangling Image となることがあります。
  • 古いイメージの保持: 過去に使用していたが、現在はどのコンテナも使用していない古いタグ付きイメージをそのままにしておく場合。
  • CI/CDパイプライン: 自動化されたビルドプロセスでは、多数のイメージが短期間に生成されることが多く、クリーンアップが適切に行われないとすぐに容量が圧迫されます。

これらの蓄積された不要なイメージを定期的にクリーンアップすることが、ディスク容量を管理し、Docker環境を健全に保つために不可欠です。そのための主要なコマンドが docker image prune なのです。

第2章：docker image prune とは何か？

docker image prune コマンドは、Dockerホスト上に存在する不要なイメージを自動的に識別し、削除するためのツールです。その目的は、不要なイメージが占有しているディスク容量を解放することにあります。

2.1 prune コマンドの基本機能

docker image prune の基本的な機能は、以下の種類のイメージを対象としています。

  • デフォルト: どのタグからも参照されておらず、どのコンテナからも使用されていない Dangling Images (<none>:<none>) を削除します。
  • オプション使用時: どの実行中のコンテナからも使用されていない、すべての Unused Images (Dangling Imagesを含む、タグ付き/タグなし問わず) を削除します。

このコマンドは、手動で個別のイメージを docker rmi <image_id> で削除するよりも効率的です。手動削除では、どのイメージが不要か、どのイメージが他のイメージとレイヤーを共有しているかなどを確認しながら行う必要がありますが、prune コマンドはDocker自身が持つ情報を利用して、安全かつ効率的に不要なイメージ（および共有されていないレイヤー）を識別・削除します。

2.2 docker rmi との違い

docker rmi <image_id> [image_id...] コマンドは、指定したイメージを削除します。これは、特定のイメージをピンポイントで削除したい場合に便利です。しかし、以下の点で prune と異なります。

  • 対象: docker rmi は指定された特定のイメージのみを削除します。docker image prune はDockerの使用状況に基づいて不要と判断されたイメージを自動的に削除します。
  • 依存関係の解決: docker rmi でイメージを削除しようとした際に、そのイメージが他のイメージのベースとなっている場合や、コンテナによって使用されている場合は、通常エラーとなり削除できません。-f オプションを使えば強制削除できますが、依存関係を壊すリスクがあります。docker image prune は、不要なイメージとそれにのみ関連付けられたレイヤーを賢く識別するため、通常はより安全にクリーンアップが行われます。
  • 自動化: prune は不要なものを自動的に判断するため、定期的なクリーンアップ処理としてスクリプトなどに組み込みやすいです。

要するに、docker rmi は外科手術のように特定のイメージを削除する際に使用し、docker image prune は定期的なメンテナンスとして、Dockerにおまかせで不要なイメージを掃除してもらうために使用します。

第3章：docker image prune の使い方とオプション

それでは、具体的な docker image prune コマンドの使い方を見ていきましょう。様々なオプションを組み合わせることで、クリーンアップの範囲を調整できます。

3.1 基本的な使い方：Dangling Images の削除

最も基本的な使い方は、オプションなしで実行することです。この場合、Dangling Images (<none>:<none>) のみが削除対象 となります。

bash
$ docker image prune

コマンドを実行すると、削除されるイメージのリストが表示され、本当に実行するかどうかを確認するプロンプトが表示されます。

WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N]

ここで y を入力してEnterを押すと、処理が実行されます。N またはそれ以外の入力をすると、処理はキャンセルされます。

削除されるオブジェクトのリストと、解放されたディスク容量の合計が表示されます。

Total reclaimed space: 150MB

このデフォルトの docker image prune は比較的安全です。なぜなら、削除対象はどのタグからも参照されておらず、通常は意図的に使用されないであろう Dangling Images だけだからです。定期的に実行することで、知らず知らずのうちに蓄積された <none>:<none> イメージをクリーンアップできます。

3.2 すべての未使用イメージを削除する (-a オプション)

デフォルトの docker image prune では、タグ付きの未使用イメージは削除されません。実行中のコンテナが使用していない、すべての未使用イメージ (Dangling Images を含む、タグ付き/タグなし問わず) を削除したい場合は、-a (または --all) オプションを使用します。

bash
$ docker image prune -a

このコマンドを実行すると、デフォルトの場合と同様に確認プロンプトが表示されます。

WARNING! This will remove all images not used by at least one container.
Are you sure you want to continue? [y/N]

ここで y を入力すると、実行中のコンテナが使用していないすべてのイメージが削除されます。これには、過去にプルした古いバージョンのイメージや、テスト用にビルドしたまま使っていないタグ付きイメージなどが含まれる可能性があります。

-a オプションはより強力なクリーンアップを行いますが、その分リスクも伴います。次に必要なイメージが、たまたま現時点でどのコンテナからも使用されていない場合、削除されてしまう可能性があります。次にそのイメージが必要になった際に、再度プルまたはビルドが必要になります。

したがって、docker image prune -a を実行する際は、どのイメージが削除される可能性があるのか を十分に理解しておく必要があります。特に、古いバージョンのイメージをあえて残しておきたいような場合は、注意が必要です。

3.3 確認プロンプトをスキップする (-f オプション)

docker image prune (デフォルトおよび -a オプション付き) は、安全のために実行前に確認プロンプトを表示します。自動化スクリプトに組み込む場合など、プロンプトを表示させたくない場合は、-f (または --force) オプションを使用します。

bash
$ docker image prune -f # Dangling Images をプロンプトなしで削除
$ docker image prune -a -f # すべての未使用イメージをプロンプトなしで削除

-f オプションを使用すると、警告メッセージは表示されますが、ユーザー入力なしで即座に削除処理が開始されます。

WARNING! This will remove all dangling images.
Total reclaimed space: 150MB

注意: -f オプション、特に docker image prune -a -f は非常に強力であり、誤って必要なイメージを削除してしまうリスクがあります。このオプションを自動化に組み込む場合は、削除対象をフィルタリングする --filter オプションと組み合わせて、意図しないイメージが削除されないように細心の注意を払う必要があります。初めて実行する場合や、削除対象に不安がある場合は、絶対に -f オプションを付けずに実行し、プロンプトで削除リストを確認してから y を入力するようにしましょう。

3.4 削除対象をフィルタリングする (--filter オプション)

docker image prune コマンドは、削除対象のイメージをさらに細かく制御するための --filter オプションをサポートしています。これにより、特定の条件に一致するイメージのみを削除対象とすることができます。

--filter オプションは、name=value または name の形式で指定します。複数のフィルターを指定する場合は、繰り返し --filter オプションを使用します。

docker image prune でよく使われるフィルターには以下のようなものがあります。

1. until=<timestamp>:
指定したタイムスタンプよりも前に作成されたイメージのみを削除対象とします。これにより、「過去X時間/X日より古いイメージのみを削除する」といった運用が可能になります。

タイムスタンプは、Unixタイムスタンプ (秒)、日付文字列 (例: 2023-10-27T10:00:00)、または相対的な時間指定 (例: 24h (24時間前), 7d (7日前)) で指定できます。相対的な時間指定は、現在時刻からの経過時間を示すため非常に便利です。

  • 例: 作成されてから24時間以上経過した Dangling Images を削除する
    bash
    $ docker image prune --filter "until=24h"
  • 例: 作成されてから7日以上経過したすべての未使用イメージを削除する
    bash
    $ docker image prune -a --filter "until=7d"

2. label=<key>[=<value>]:
指定したラベルを持つイメージのみを削除対象とします。ラベルはイメージビルド時やプル時に付与できます。特定のプロジェクトや環境に関連付けられたイメージのみを対象としたい場合に有用です。

  • 例: com.example.cleanup=true というラベルが付いた Dangling Images を削除する
    bash
    $ docker image prune --filter "label=com.example.cleanup=true"
  • 例: ci.build というキーのラベルが付いたすべての未使用イメージを削除する
    bash
    $ docker image prune -a --filter "label=ci.build"

3. dangling=<boolean>:
これは docker image prune のデフォルトの挙動を明示的に指定するフィルターです。
* dangling=true: Dangling Images のみを対象とします。（これがデフォルト動作）
* dangling=false: Dangling Images ではない イメージを対象とします。これは通常 -a と組み合わせて、タグ付きイメージのみを対象としたい場合などに使用されます。例えば、docker image prune -a --filter "dangling=false" は、実行中のコンテナが使用していない タグ付き イメージを削除します。

  • 例: 明示的に Dangling Images のみを削除する (デフォルトと同じ)
    bash
    $ docker image prune --filter "dangling=true"
  • 例: 実行中のコンテナが使用していないタグ付きイメージのみを削除する
    bash
    $ docker image prune -a --filter "dangling=false"
    ただし、この最後の例は少し注意が必要です。dangling=false フィルターは、prune -a が選択した「実行中のコンテナが使用していないイメージのセット」の中から、さらに Dangling ではないもの（つまりタグ付きのもの）を選び出すフィルターとして機能します。

フィルターは強力ですが、組み合わせによっては意図しない結果を招く可能性もあります。特に -a や -f と組み合わせて使う場合は、十分にテストしてから運用するようにしましょう。

3.5 削除処理の確認（ドライランのような使い方）

docker image prune コマンドには明示的な --dry-run オプションはありません。しかし、前述の通り、-f オプションを付けずに実行すること が、実質的な「ドライラン」または「確認ステップ」となります。

プロンプトが表示された際に、削除対象となるイメージのリストが表示されます。このリストを確認することで、意図しないイメージが含まれていないかをチェックできます。リストを見て問題なければ y を入力して実行、問題があれば N を入力してキャンセルし、コマンドのオプションやフィルターを見直すという流れになります。

bash
$ docker image prune -a --filter "until=48h"
WARNING! This will remove all images not used by at least one container.
Are you sure you want to continue? [y/N] y # ここでyを入力する前に、表示されたリストを確認する

この確認ステップを怠らないことが、安全にクリーンアップを行う上で最も重要です。

第4章：docker image prune によるディスク容量の節約効果

docker image prune を実行することで、どの程度のディスク容量を節約できるのでしょうか。その効果は、Dockerの使用状況によって大きく異なりますが、一般的には無視できない量の容量を解放できます。

4.1 容量節約の仕組み

docker image prune がディスク容量を節約できるのは、主に以下の理由からです。

  1. Dangling Images の削除: タグを失って宙に浮いたイメージは、単にディスク容量を無駄にしているだけです。これらを削除することで、そのイメージ自体が占めていた容量を直接解放できます。
  2. Unused Images (タグ付き) の削除: -a オプションで削除されるタグ付きの未使用イメージも同様に、そのイメージが占めていた容量を解放します。
  3. 参照されなくなったレイヤーの削除: これが最も大きな容量節約につながる可能性があります。Dockerイメージはレイヤー構造になっており、複数のイメージが同じレイヤーを共有しています。prune コマンドは、特定のイメージを削除する際に、そのイメージが参照していたレイヤーのうち、削除後も他のどのイメージからも参照されなくなるレイヤー を特定し、それらのレイヤーの実体もディスクから削除します。つまり、完全に不要になったレイヤーの容量が解放されるのです。

例を考えてみましょう。
* Image A: Layer X -> Layer Y -> Layer Z
* Image B: Layer X -> Layer Y -> Layer W

この場合、Layer X と Layer Y は Image A と Image B で共有されています。Image A を prune によって削除した場合、Layer Z は Image A のみが参照していたため削除されます。しかし、Layer X と Layer Y は Image B がまだ参照しているため削除されません。

もし Image B も削除された場合、Layer X と Layer Y はどのイメージからも参照されなくなるため、次に prune または system prune が実行された際に削除され、それらが占めていた容量が解放されます。

4.2 節約効果の具体例（概念的）

開発やCI環境では、数GBから数十GBの容量が Dangling Images や古い未使用イメージによって占められていることは珍しくありません。

例えば、頻繁にビルドを繰り返すプロジェクトで、ビルドごとに新しいイメージが同じタグで作成されると、古いビルドの中間レイヤーや最終イメージが次々と Dangling Image となります。これらの積み重ねは、すぐに数GB、場合によっては数十GBに達します。

  • docker image prune (デフォルト) を定期的に実行することで、これらの Dangling Images がクリーンアップされ、多くの場合は 数百MBから数GB の容量が節約できます。
  • docker image prune -a を定期的に実行することで、Dangling Images に加えて、古いバージョンのタグ付きイメージや、一度プルしたが使っていないイメージなども削除対象となるため、さらに多くの容量、場合によっては 数GBから数十GB の容量を節約できる可能性があります。

節約できる正確な容量は、ダウンロード/ビルドしたイメージの種類、数、レイヤーの共有状況、そしてクリーンアップを最後に実行してからどれくらい時間が経過したかなど、多くの要因によって変動します。しかし、ディスク容量が不足してきたと感じた際に docker image prune を実行することは、最も手軽で効果的な対策の一つです。

第5章：docker image prune を使うべきタイミングとベストプラクティス

docker image prune コマンドは強力ですが、いつどのように使うべきかを知っておくことが重要です。適切なタイミングで適切なオプションを使用することで、リスクを最小限に抑えつつ最大の効果を得られます。

5.1 使うべきタイミング

  • ディスク容量が不足してきた時: これが最も一般的なトリガーです。df -h コマンドなどでディスク使用量を確認し、容量が逼迫している場合はまず docker image prune の実行を検討しましょう。
  • 大量のイメージをプルまたはビルドした後: 特にCI/CDパイプラインや新しいプロジェクトのセットアップなどで、多くのイメージ操作を行った後には、大量の Dangling Images や未使用イメージが発生しやすいです。
  • 定期的なメンテナンスとして: ディスク容量の問題が顕在化する前に、予防策として定期的に docker image prune を実行することをお勧めします。例えば、週に一度や月に一度など、運用に合わせた頻度で実行します。
  • 開発環境やテスト環境: これらの環境ではイメージのビルドや変更が頻繁に行われるため、特に不要なイメージが蓄積しやすいです。定期的なクリーンアップは、開発効率の維持にもつながります。
  • CI/CDパイプラインの最後に: ビルド後のクリーンアップステップとして docker image prune を組み込むことで、ビルドエージェントのディスク容量を適切に保つことができます。ただし、後続のジョブで必要になる可能性のあるイメージを誤って削除しないよう、フィルターを慎重に設定する必要があります。

5.2 ベストプラクティス

docker image prune を安全かつ効果的に使用するためのベストプラクティスは以下の通りです。

  1. まず -f なしで実行する: 削除対象のリストを必ず確認しましょう。プロンプトで表示されるリストに意図しないイメージが含まれていないか慎重にチェックし、問題なければ y を入力します。
  2. -a オプションの利用は慎重に: -a はタグ付きの未使用イメージも削除します。これらのイメージが後で必要になる可能性がないか、十分に検討してから使用しましょう。特に、古いバージョンを残しておきたい場合は使用を避けるか、フィルターで対象外にするなどの工夫が必要です。
  3. フィルターを活用する: 不要なイメージをより正確にターゲットするために、--filter "until=..." や --filter "label=..." などを活用しましょう。これにより、誤削除のリスクを減らし、必要なイメージを残しつつ効率的に容量を解放できます。例えば、「1週間以上前に作成されたイメージ」のみを対象にするフィルターは、比較的安全なクリーンアップ方法の一つです。
  4. 他の prune コマンドと組み合わせる: ディスク容量の問題はイメージだけでなく、コンテナ、ボリューム、ビルドキャッシュなど、他の要素に起因している可能性もあります。docker image prune だけでなく、docker container prune, docker volume prune, docker builder prune といった他の prune コマンドや、それらを包括的に実行する docker system prune の利用も検討しましょう。
  5. 自動化は慎重に、フィルターと組み合わせる: 定期的な自動クリーンアップは非常に便利ですが、安易に docker image prune -a -f を実行するのは危険です。自動化する場合は、必ず --filter オプションで削除対象を厳密に定義し、十分にテストを行った上で -f を使用するようにしましょう。例えば、--filter "until=168h" (1週間前より古い) など、猶予期間を設けるのが一般的です。
  6. イメージのタグ付け戦略を見直す: 不要な Dangling Images を減らすためには、イメージのタグ付け戦略を見直すことも有効です。例えば、ビルドごとにユニークなタグ (コミットハッシュなど) を付けるようにすれば、特定のタグが別のイメージに置き換えられることがなくなり、意図しない Dangling Image の発生を減らせます。ただし、この戦略を採用した場合は、どのイメージがどのタグで存在するかを管理し、古くなったタグ付きイメージを -a オプションやフィルターを使って適切にクリーンアップする必要があります。

第6章：docker image prune の注意点とリスク

docker image prune は非常に便利なツールですが、その使用にはいくつかの注意点とリスクが伴います。これらを理解しておくことで、トラブルを回避できます。

6.1 誤って必要なイメージを削除するリスク

特に docker image prune -a オプションを使用する場合、実行中のコンテナが使用していない すべての イメージが削除対象となります。これには、今後手動で起動する予定のあるイメージや、特定の目的でアーカイブとして残しておきたいイメージ（例: 特定のバージョンのデバッグ用イメージ）が含まれる可能性があります。

  • 回避策:
    • 必ず -f なしで実行し、削除対象のリストを確認する。
    • 削除されたくないイメージがある場合は、それらが実行中のコンテナで使用されている状態にするか、または --filter オプションを使って削除対象から除外する（ただし、label フィルター以外で特定のイメージを除外するフィルターは限られています）。
    • 重要なイメージには、明確でユニークなタグを付けておく。
    • 削除されたくないイメージを一時的にコンテナとして起動しておき、prune -a の実行後に停止させる（これは応急処置的であり、非推奨です）。
    • 削除されたくないイメージには、特別なラベルを付与しておき、--filter "label!=keep" のように除外フィルターを使用する（ただし、label!=value 形式のフィルターは、Dockerバージョンによってはサポートされていない場合があります。代わりに、削除対象としたいイメージ群に共通のラベルを付けて、そのラベルでフィルタリングする方が確実です）。

6.2 ビルドキャッシュへの潜在的な影響

docker image prune は、基本的に最終的なイメージや中間イメージを対象とします。しかし、ビルドキャッシュを構成する一部のレイヤーが、削除されたイメージによってのみ参照されていた場合、それらのレイヤーも prune 処理によって削除される可能性があります。

レイヤーが削除されると、次に同じステップを含むイメージをビルドする際に、そのレイヤーを再作成する必要が生じます。これにより、ビルドキャッシュが効かなくなり、ビルド時間が長くなる可能性があります。

ただし、ビルドキャッシュの管理は、より専門的な docker builder prune コマンドの担当領域です。docker image prune は主にビルド後の未使用イメージのクリーンアップを目的としており、ビルドキャッシュ全体に意図的に影響を与えるものではありません。ビルドキャッシュを積極的に管理・クリーンアップしたい場合は、docker builder prune を使用すべきです。

  • 注意点:
    • docker image prune が直接的にビルドキャッシュを「壊す」わけではありませんが、共有レイヤーの削除を通じて間接的にビルドキャッシュの効果に影響を与える可能性はあります。
    • ビルドキャッシュのクリーンアップを目的とする場合は、docker builder prune を使いましょう。

6.3 削除されたイメージの復旧について

一度 docker image prune によって削除されたイメージは、基本的に元に戻すことはできません。必要なイメージを誤って削除してしまった場合は、以下のいずれかの方法で対処する必要があります。

  • リモートレジストリからイメージを再度プルする。
  • Dockerfile からイメージを再度ビルドする。
  • 別のDockerホストやバックアップからイメージをエクスポート/インポートする（事前にバックアップを取っている場合）。

このため、特に自動化を行う際は、削除対象を厳密に制御することが非常に重要になります。

6.4 実行中のコンテナへの影響

docker image prune コマンドは、実行中のコンテナが使用しているイメージを削除することはありません。コンテナが使用しているイメージや、そのイメージが依存するレイヤーは、安全のために削除対象から除外されます。

したがって、docker image prune の実行が、現在稼働しているサービスやアプリケーションに直接的な影響を与えるリスクは非常に低いです。この点は安心して利用できるポイントです。影響があるのは、これから新たにコンテナを起動しようとした際に、そのイメージが既に削除されてしまっていた場合です。

第7章：関連するDockerディスク容量管理コマンド

docker image prune はイメージのクリーンアップに特化したコマンドですが、Dockerには他にも様々なディスク容量管理のためのコマンドがあります。これらのコマンドを理解し、適切に使い分けることで、Docker環境全体のディスク容量を効果的に管理できます。

7.1 docker system prune

これは最も包括的なクリーンアップコマンドです。デフォルトでは、以下の不要なリソースを削除します。

  • すべての停止中のコンテナ (docker container prune と同じ対象)
  • すべての Dangling Images (docker image prune と同じ対象)
  • 使用されていないすべてのネットワーク (docker network prune と同じ対象)
  • すべてのビルドキャッシュ (docker builder prune とほぼ同じ対象、より強力)

さらに、-a (または --all) オプションを付けると、停止中のコンテナ、Dangling Images に加えて、実行中のコンテナが使用していないタグ付きイメージ も削除します (docker image prune -a と同じイメージ対象に加え、停止中のコンテナも削除)。

--volumes オプションを付けると、どのコンテナからも参照されていないボリュームも削除します (docker volume prune と同じ対象)。ボリュームの削除はデータ損失につながる可能性があるため、このオプションの使用には特に注意が必要です。

  • 使い方:
    bash
    $ docker system prune # 停止中のコンテナ、Dangling Images, 未使用ネットワーク, ビルドキャッシュを削除
    $ docker system prune -a # 上記に加えて、実行中のコンテナが使用していないタグ付きイメージも削除
    $ docker system prune --volumes # 上記デフォルト対象に加えて、未使用ボリュームも削除
    $ docker system prune -a --volumes # すべての未使用リソースを削除
  • 特徴:
    • Docker環境全体のクリーンアップを一度に行いたい場合に便利です。
    • 非常に強力なため、実行前に削除対象を十分に確認することが重要です。特に --volumes はデータ損失のリスクがあるため慎重に。
    • 確認プロンプトが表示されます（-f でスキップ可能）。
    • --filter オプションも利用可能ですが、対象が複数種類にわたるためフィルターの指定は少し複雑になります。

docker system prune は「全部まとめて綺麗にしたい」場合に便利ですが、どの種類のリソースが容量を圧迫しているかを確認し、それぞれの種類に特化した prune コマンド（image prune, container prune, volume prune など）を個別に実行する方が、制御が効きやすく安全な場合もあります。

7.2 docker container prune

停止中のコンテナをすべて削除します。実行中のコンテナは削除されません。

bash
$ docker container prune

開発やテストで多数のコンテナを起動・停止していると、停止中のコンテナが溜まって容量を圧迫することがあります。このコマンドでそれらをクリーンアップできます。

7.3 docker volume prune

どのコンテナからも参照されていないボリュームをすべて削除します。

bash
$ docker volume prune

ボリュームは永続データを保存するため、安易に削除すると重要なデータが失われる可能性があります。このコマンドを使用する際は、本当にそのボリュームが不要であることを十分に確認する必要があります。確認プロンプトで削除対象ボリュームのリストを慎重にチェックしましょう。

7.4 docker network prune

どのコンテナからも使用されていないネットワークをすべて削除します。通常、ネットワークがディスク容量を大きく圧迫することは少ないですが、多数のカスタムネットワークを作成・削除している場合に有用です。

bash
$ docker network prune

7.5 docker builder prune

ビルドキャッシュを削除します。イメージビルドの高速化に使われるキャッシュですが、時間が経つと不要なものが溜まり容量を圧迫することがあります。

bash
$ docker builder prune

このコマンドは、使用されていないビルドキャッシュのエントリを削除し、ビルドに費やされたディスク容量を解放します。--all オプションや --filter オプションも使用できます。ビルドキャッシュを管理したい場合は、docker image prune よりもこのコマンドを使うべきです。

7.6 各 prune コマンドの使い分け

  • とにかく全体的にクリーンアップしたい: docker system prune (必要なら -a や --volumes を付ける)
  • 不要なイメージだけを効率的に削除したい: docker image prune (デフォルトで Dangling, -a で未使用すべて)
  • 停止中のコンテナだけを削除したい: docker container prune
  • 使用されていないボリュームだけを削除したい: docker volume prune (データ損失に注意)
  • ビルドキャッシュだけを削除したい: docker builder prune

docker image prune は、これらの中で最も頻繁に必要とされるクリーンアップの一つであり、特に開発サイクルが速い環境やCI/CD環境でその真価を発揮します。

第8章：自動化と定期実行

手動で docker image prune を実行するのも良いですが、ディスク容量の問題を継続的に管理するためには、定期的な自動実行を検討すると良いでしょう。

8.1 自動化のメリット

  • ディスク容量の維持: 容量不足に陥る前に、自動的に不要なリソースをクリーンアップできます。
  • パフォーマンスの維持: ディスク容量の逼迫は、Dockerだけでなくシステム全体のパフォーマンス低下につながる可能性があります。定期的なクリーンアップでこれを防ぎます。
  • 手間の削減: 手動でのクリーンアップ作業を省くことができます。

8.2 自動化の方法

様々な方法で docker image prune を自動実行できます。

  • Cron jobs (Linux/macOS): 指定したスケジュールでコマンドを実行する古典的な方法です。
  • systemd timers (Linux): Cron のより現代的な代替手段です。
  • スクリプト: シェルスクリプトなどを作成し、そのスクリプトを上記のスケジューラーから呼び出す方法です。これにより、より複雑なロジック（例: クリーンアップ前にディスク容量をチェックする）を実装できます。
  • Docker Swarm/Kubernetes: クラスター環境の場合、各ノードのクリーンアップを管理するためのより高度な仕組み（DaemonSetなど）を検討する必要があるかもしれません。

8.3 Cron を使った自動化の例

例えば、毎週日曜日の午前3時に、作成されてから1週間以上経過したすべての未使用イメージを削除する Cron ジョブを設定する場合、以下のようになります。

まず、crontab -e コマンドで Cron 設定ファイルを開きます。

bash
$ crontab -e

エディタが開いたら、以下の行を追加します。

“`cron

毎週日曜日の午前3時に、1週間以上前の未使用イメージを削除 (プロンプトなし)

0 3 * * 0 docker image prune -a -f –filter “until=168h” > /dev/null 2>&1
“`

解説：

  • 0 3 * * 0: 実行スケジュール (0分 3時 *日 *月 0曜日 (日曜日))
  • docker image prune -a -f --filter "until=168h": 実行するコマンド。
    • -a: すべての未使用イメージを対象
    • -f: 確認プロンプトをスキップ
    • --filter "until=168h": 作成から168時間（7日間）以上経過したイメージのみを対象
  • > /dev/null 2>&1: コマンドの標準出力と標準エラー出力を /dev/null に捨てる（ログが不要な場合）。必要に応じてログファイルに出力するように変更することも可能です。

重要な注意点:

  • 上記例は -f オプションを使用しています。これはプロンプトなしで実行されるため、削除対象フィルター (until=168h) が意図通りに機能することを十分にテストしてから 設定してください。
  • docker コマンドが $PATH 環境変数に含まれていることを確認してください。cron 環境では $PATH が限定されている場合があるため、docker コマンドのフルパス (/usr/local/bin/docker など) を指定した方が安全な場合もあります。
  • Cron ジョブを実行するユーザーが、Dockerデーモンと通信できる権限を持っている必要があります（通常は docker グループに所属しているユーザー）。

8.4 自動化における注意点

自動化は便利ですが、以下の点に注意が必要です。

  • 誤削除のリスク: 最も懸念されるリスクです。フィルター設定が不十分だったり、予期せぬイメージが含まれていたりすると、必要なイメージを削除してしまう可能性があります。フィルターと -f の組み合わせは十分にテストしましょう。
  • スケジュールの検討: あまりに頻繁に実行すると、削除されたレイヤーをすぐにまた必要として再ダウンロード/再ビルドが発生し、効率が悪くなる可能性があります。逆に、間隔が開きすぎるとディスク容量が逼迫する可能性があります。システムの使用状況に合わせて適切な頻度を設定しましょう。
  • ログの確認: 自動実行の結果を定期的に確認することをお勧めします。特に最初は、削除されたイメージのリストをログに出力するように設定し、意図通りに機能しているか検証しましょう。

第9章：トラブルシューティングとよくある質問 (FAQ)

docker image prune を使う上で遭遇する可能性のある問題や、よくある質問について解説します。

9.1 クリーンアップしてもディスク容量があまり解放されない

docker image prune を実行したのに、期待していたほどディスク容量が解放されない場合があります。考えられる原因はいくつかあります。

  • Dangling Images がほとんどなかった: デフォルトの docker image prune を実行した場合、元々 Dangling Images が少なかった可能性があります。
  • -a オプションを使用しなかった: タグ付きの未使用イメージが容量を圧迫しているが、-a オプションを付けなかったため削除されなかった。
  • 削除されたイメージが多くのレイヤーを共有していた: 削除されたイメージが参照していたレイヤーの多くが、他の残存イメージによっても参照されていた場合、それらの共有レイヤーは削除されません。結果として、イメージの数ほど容量が減らないことがあります。
  • 他の要素が容量を圧迫している: ディスク容量の問題の原因はイメージだけではありません。停止中のコンテナ、使用されていないボリューム、ビルドキャッシュが大量に溜まっている可能性があります。
    • docker system df コマンドを実行して、各Dockerリソース（Images, Containers, Local Volumes, Build Cache）が使用している容量を確認しましょう。
    • 容量を圧迫している要素がイメージ以外であれば、docker container prune, docker volume prune, docker builder prune、または docker system prune を使用して、それぞれの要素をクリーンアップする必要があります。特にボリュームが大きな容量を占めているケースが多いです。

9.2 誤って必要なイメージを削除してしまった

前述の通り、一度削除したイメージの復旧は困難です。

  • 対処法: リモートレジストリからのプル、Dockerfileからの再ビルドなどを行います。
  • 予防策:
    • -f なしで実行し、削除リストを必ず確認する。
    • -a オプションや強力なフィルターを使用する際は細心の注意を払う。
    • 重要なイメージには適切なタグを付け、必要であれば一時的にコンテナを起動しておくなどの回避策を検討する。
    • 定期的に重要なイメージを docker save でアーカイブとして保存しておく。

9.3 docker image prune と docker rmi の違いは？

  • docker image prune: Dockerの使用状況に基づいて不要と判断されたイメージを、自動的に識別・削除します。デフォルトでは Dangling Images、-a オプションで未使用イメージすべてを対象とします。複数のイメージやレイヤーをまとめて効率的にクリーンアップするのに適しています。
  • docker rmi <image_id>: 指定されたIDまたはタグの特定のイメージを手動で削除します。特定のイメージをピンポイントで削除したい場合に便利です。ただし、使用中のイメージや他のイメージが依存するイメージはそのままでは削除できません。

9.4 prune コマンドは実行中のコンテナに影響しますか？

いいえ、docker image prune (および他のほとんどの prune コマンド) は、実行中のコンテナが使用しているリソースを削除しません。削除対象となるのは、「使用されていない」と判断されたリソースのみです。したがって、コマンドの実行によって稼働中のサービスが停止したり、予期せぬ動作をしたりするリスクはありません。

9.5 CI/CDパイプラインで安全に使うには？

CI/CDパイプラインの最後にクリーンアップステップとして docker image prune を組み込むのは効果的ですが、慎重に行う必要があります。

  • -f を使う場合はフィルター必須: プロンプトを表示させたくない場合は -f が必要ですが、その場合、削除対象を厳密に定義するために --filter を必ず使用してください。例えば、「ビルド後一定時間以上経過したイメージのみ」といったフィルターが有効です。
  • ジョブ間の依存関係を考慮: 後続のジョブで、現在のジョブがビルドまたはプルしたイメージが必要になる場合は、そのイメージが削除されないようにフィルターを設定する必要があります。
  • 専用のクリーンアップジョブ: ビルドやテストのジョブとは別に、定期的に（例: 日次）クリーンアップ専用のジョブを実行するという設計も考えられます。このジョブは、より古いイメージを対象とするフィルターを設定するなど、よりアグレッシブなクリーンアップを行えます。
  • docker builder prune も検討: ビルドエージェントの容量問題は、イメージ自体よりもビルドキャッシュに起因することも多いです。docker image prune と合わせて docker builder prune の実行も検討しましょう。

まとめ：docker image prune を使いこなして快適なDocker環境を維持しよう

Dockerを継続的に利用する上で、ディスク容量の管理は避けて通れない課題です。特にイメージは、開発や運用の中で無意識のうちに蓄積され、システムリソースを圧迫する主要因の一つとなります。

本記事では、不要なイメージを効率的にクリーンアップするための docker image prune コマンドについて、その仕組みから詳細な使い方、オプション、注意点、そして関連コマンドまでを網羅的に解説しました。

  • docker image prune (デフォルト): Dangling Images (<none>:<none>) を削除します。最も安全なクリーンアップです。
  • docker image prune -a: 実行中のコンテナが使用していないすべての未使用イメージ (タグ付き含む) を削除します。より強力ですが、誤削除のリスクも伴います。
  • -f: 確認プロンプトをスキップします。自動化に必須ですが、慎重な利用が必要です。
  • --filter: 削除対象を時間 (until) やラベル (label) で絞り込みます。安全かつ効果的なクリーンアップのために活用すべき重要なオプションです。

安全に docker image prune を使うための鍵は、-f オプションを安易に使わないこと、そして 削除対象をしっかりと確認すること です。特に -a や -f オプションを組み合わせる場合は、--filter オプションを適切に活用し、意図しないイメージが削除されないように細心の注意を払う必要があります。

また、ディスク容量の問題はイメージだけでなく、コンテナ、ボリューム、ビルドキャッシュなど、他のDockerリソースに起因することもあります。docker image prune を、docker system prune を含む他の prune コマンドと組み合わせて、Docker環境全体の健全性を保つことが重要です。

この記事を通じて、docker image prune の理解を深め、Docker環境におけるディスク容量の管理をより効果的に行えるようになったことでしょう。定期的なクリーンアップを習慣づけ、快適なDockerライフを送りましょう。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール