Docker イメージの一括削除・prune コマンドの使い方

By /

Docker イメージの一括削除・prune コマンドの使い方：詳細解説

Docker はコンテナ技術のデファクトスタンダードとして広く利用されています。開発、テスト、本番環境を問わず、様々なアプリケーションが Docker イメージとして構築され、コンテナとして実行されています。しかし、Docker を使い続けていると、ビルドやプルによってイメージがどんどん蓄積され、ディスク容量を圧迫したり、管理が煩雑になったりすることがよくあります。

不要になったイメージを定期的に削除し、ディスク容量を確保し、イメージリストを整理することは、効率的な Docker 環境を維持するために不可欠な作業です。この記事では、Docker イメージを削除するための様々な方法、特に複数のイメージを一括で削除する方法、そして未使用のイメージを効率的にクリーンアップする docker image prune コマンドについて、その詳細な使い方から注意点までを網羅的に解説します。

目次

  1. はじめに：なぜ Docker イメージを削除する必要があるのか
    • ディスク容量の圧迫
    • イメージリストの整理と管理
    • セキュリティと鮮度
  2. Docker イメージの基本的な理解
    • イメージとは？コンテナとの関係
    • イメージ ID とタグ
    • イメージのレイヤー構造
    • 「ぶら下がりイメージ (Dangling Images)」と「未使用イメージ (Unused Images)」
  3. 個別の Docker イメージを削除する (docker image rm / docker rmi)
    • 基本的な削除方法 (ID または リポジトリ名:タグ)
    • 使用中のイメージの削除
    • -f (--force) オプションの使用と危険性
  4. 複数の Docker イメージを一括で削除する
    • 複数のイメージを直接指定して削除する
    • コマンド置換 ($()) を使った一括削除
      • 特定の名前パターンを持つイメージの削除
      • 特定のタグを持つイメージの削除
      • 特定の条件でフィルタリングしたイメージの一括削除
      • docker image ls -q の活用
    • xargs コマンドとの組み合わせ
    • シェルスクリプトを使ったより高度な一括削除
  5. docker image prune コマンドによる未使用イメージのクリーンアップ
    • docker image prune とは？
    • デフォルトの動作：ぶら下がりイメージの削除
    • 確認プロンプトと -f (--force) オプション
    • -a (--all) オプション：全ての未使用イメージを削除
    • --filter オプションを使った高度なフィルタリング
      • until フィルタ：特定の期間より古いイメージを対象にする
      • label フィルタ：特定のラベルを持つ/持たないイメージを対象にする
      • dangling フィルタ：ぶら下がりイメージまたはそれ以外のイメージを対象にする
    • docker image prune 実行時の注意点
  6. docker system prune コマンド：システム全体をクリーンアップする
    • docker system prune の概要と対象
    • docker image prune との違い
    • -a (--all) オプションの効果（イメージへの影響）
    • --volumes オプション：ボリュームの削除（注意）
    • --filter オプション
    • docker system prune 実行時の注意点
  7. 実践的なシナリオと例
    • 開発環境での手軽なクリーンアップ
    • CI/CD環境での自動的なクリーンアップ
    • ディスク容量が不足した場合の緊急対応
    • 特定のプロジェクトに関連するイメージのみをクリーンアップ
  8. イメージ削除に関する注意点とベストプラクティス
    • 削除前に必ず確認する習慣をつける
    • 重要なイメージには適切なタグやラベルを付ける
    • 本番環境での削除作業
    • 定期的なクリーンアップのスケジュール化
    • --force オプションの安易な使用を避ける
  9. まとめ：適切な方法で Docker イメージを管理しよう

1. はじめに：なぜ Docker イメージを削除する必要があるのか

Docker を利用していると、様々な理由からイメージが蓄積されていきます。例えば、Dockerfile の変更に伴うイメージのビルド、Docker Hub やプライベートレジストリからのイメージのプル、開発中に試行錯誤で作成された中間イメージなどです。これらのイメージは、時間の経過とともに不要になるものが増えていきます。不要なイメージを放置することには、いくつかのデメリットがあります。

ディスク容量の圧迫: Docker イメージは、アプリケーション本体、OS のベースイメージ、ライブラリなど、実行に必要な全ての要素を含んでいます。特に複数のバージョンや派生イメージが存在する場合、これらの合計サイズは膨大になりがちです。不要なイメージが蓄積されると、サーバーや開発マシンのディスク容量を圧迫し、他の作業に影響を与える可能性があります。

イメージリストの整理と管理: docker image ls コマンドを実行すると、ローカルに存在する全てのイメージが一覧表示されます。不要なイメージが多いと、このリストが長くなり、現在利用しているイメージや必要なイメージを見つけにくくなります。これは、イメージ管理の効率を低下させます。

セキュリティと鮮度: 古いイメージには、セキュリティ上の脆弱性を含んでいる可能性があります。また、ベースイメージが更新されていない場合、新しい機能やパフォーマンス改善が反映されていません。不要になった古いイメージを削除することで、誤って古いイメージを使用してしまうリスクを減らし、最新の安全なイメージを使用することを促すことができます。

これらの理由から、Docker イメージを適切に管理し、不要になったものを定期的に削除することは、Docker を効率的かつ安全に利用するために非常に重要です。

2. Docker イメージの基本的な理解

イメージ削除の方法を理解する前に、Docker イメージの基本的な構造とライフサイクルについて簡単に触れておきます。

イメージとは？コンテナとの関係:
Docker イメージは、アプリケーションとその実行に必要な環境（コード、ランタイム、システムツール、システムライブラリなど）をパッケージ化した、読み取り専用のテンプレートです。このイメージを元に実行されるのがコンテナです。イメージは静的な実体であり、コンテナはイメージを実行した動的な実体です。

イメージ ID とタグ:
全ての Docker イメージは一意のイメージ ID を持ちます。これは SHA256 ハッシュ値で表現されます（通常は先頭の数文字が表示されます）。イメージには通常、リポジトリ名とタグが関連付けられています（例: ubuntu:latest, myapp:v1.0.0）。タグは特定のイメージリビジョンを識別するために使われ、デフォルトでは latest タグが使用されます。同じリポジトリ名であっても、タグが異なれば別のイメージとして扱われます（技術的には、異なるイメージ ID を持ちます）。また、タグが付いていないイメージ（<none>:<none> と表示されることが多い）は「ぶら下がりイメージ」と呼ばれる特殊な状態のイメージです。

イメージのレイヤー構造:
Docker イメージは複数の読み取り専用レイヤーの重ね合わせで構成されています。Dockerfile の各命令（FROM, RUN, COPY など）は、通常、新しいレイヤーを作成します。これにより、イメージの共有や再利用が可能になり、ディスク容量の節約やビルド時間の短縮に貢献します。例えば、複数のイメージが同じベースイメージ（例: Ubuntu の特定のバージョン）を使用している場合、そのベースイメージのレイヤーは一度だけディスクに保存され、複数のイメージで共有されます。イメージを削除する際、そのイメージ固有のレイヤーは削除されますが、他のイメージと共有されているレイヤーは、そのレイヤーを参照しているイメージが全て削除されるまでディスクに残ります。

「ぶら下がりイメージ (Dangling Images)」と「未使用イメージ (Unused Images):
イメージ削除を考える上で重要なのが、これらの区別です。

  • ぶら下がりイメージ (Dangling Images): これは、どのコンテナからも参照されておらず、かつ、どのタグとも関連付けられていないイメージです。典型的な例は、新しいイメージをビルドした際に、以前に同じタグが付いていた古いイメージからタグが剥がされた場合です。タグがなくなった古いイメージはぶら下がりイメージとなります。docker image ls コマンドで <none>:<none> と表示されるのがこれです。
  • 未使用イメージ (Unused Images): これは、どのコンテナからも参照されていませんが、少なくとも1つ以上のタグが付いているイメージです。例えば、手動でプルしたが一度もコンテナを実行しなかったイメージや、古いバージョンのイメージなどがこれに該当します。

docker image prune コマンドは、デフォルトではぶら下がりイメージのみを削除します。-a オプションを付けると、全ての未使用イメージ（ぶら下がりイメージと、タグは付いているが使用されていないイメージの両方）を削除対象とします。この違いを理解することは、prune コマンドを適切に使用するために重要です。

3. 個別の Docker イメージを削除する (docker image rm / docker rmi)

特定の不要なイメージが明確な場合は、個別に削除するのが最も簡単な方法です。イメージを削除するには、docker image rm またはそのエイリアスである docker rmi コマンドを使用します。

基本的な使い方は以下の通りです。

“`bash
docker image rm <イメージIDまたはリポジトリ名:タグ>

または

docker rmi <イメージIDまたはリポジトリ名:タグ>
“`

削除したいイメージの <イメージID> または <リポジトリ名:タグ> を指定します。<リポジトリ名> のみ指定した場合、デフォルトで :latest タグが付いたイメージが対象となります。

例:
まず、現在のイメージリストを確認します。

bash
docker image ls

出力例:

REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu latest d6f748d53105 2 weeks ago 77.8MB
nginx latest a2f391fcf71d 3 weeks ago 141MB
my-app v1.0.0 abcdef123456 4 weeks ago 250MB
<none> <none> deadbeefc0de 5 weeks ago 200MB

上記のリストから my-app:v1.0.0 イメージを削除する場合：

bash
docker rmi my-app:v1.0.0

イメージID を指定して削除する場合（例えば、abcdef123456 を指定）：

bash
docker rmi abcdef123456

イメージID は、先頭の一意な部分のみを指定すれば認識されます。例えば、abcdef123456 であれば、abcd や abcdef でも削除できます（他のイメージIDと衝突しない範囲で）。

使用中のイメージの削除:
実行中のコンテナが参照しているイメージは、通常、削除できません。

bash
docker rmi ubuntu:latest

もし ubuntu:latest を使用しているコンテナが実行中であれば、以下のようなエラーが表示されます。

Error response from daemon: conflict: unable to delete ubuntu:latest (must force) - image is being used by running container 1a2b3c4d5e6f

このエラーは、イメージがコンテナによって使用されているため削除できないことを示しています。削除するには、まずそのイメージを使用している全てのコンテナを停止し、削除する必要があります。

-f (--force) オプションの使用と危険性:
docker rmi コマンドには -f または --force オプションがあります。これを使用すると、そのイメージを参照しているコンテナが実行中でも、強制的にイメージを削除しようとします。

bash
docker rmi -f ubuntu:latest

このコマンドを実行すると、イメージは削除されます。しかし、これは非常に危険な操作であり、特別な理由がない限り使用すべきではありません。実行中のコンテナが参照元を失うことになり、コンテナが不安定になったり、予期しない問題を引き起こしたりする可能性があります。

通常は、以下の手順で削除を行うべきです。

  1. docker ps -a でイメージを使用しているコンテナを確認する。
  2. docker stop <コンテナIDまたはコンテナ名> でコンテナを停止する。
  3. docker rm <コンテナIDまたはコンテナ名> でコンテナを削除する。
  4. docker rmi <イメージIDまたはリポジトリ名:タグ> でイメージを削除する。

-f オプションは、本当に緊急かつ状況を完全に理解している場合にのみ、細心の注意を払って使用してください。例えば、開発環境で一時的なコンテナとイメージをまとめてクリーンアップしたい場合などに限定的に使用されることがあります。

4. 複数の Docker イメージを一括で削除する

不要なイメージが多数ある場合、個別に削除するのは非効率です。複数のイメージを一度に削除する方法を学びましょう。

複数のイメージを直接指定して削除する:
複数のイメージID やリポジトリ名:タグをスペース区切りで指定することで、一度に複数のイメージを削除できます。

bash
docker rmi <イメージ1> <イメージ2> <イメージ3> ...

例:

bash
docker rmi my-app:v1.0.0 my-app:v1.0.1 alpine:3.14

削除したいイメージが少数であればこの方法で十分ですが、多数の場合や特定の条件で選択したい場合は、別の方法が必要になります。

コマンド置換 ($()) を使った一括削除:
Linux/Unix シェルでは、コマンドの実行結果を別のコマンドの引数として渡すためにコマンド置換 ($()) を使用できます。docker image ls コマンドと組み合わせることで、特定の条件でフィルタリングしたイメージを一括削除できます。

docker image ls コマンドは、デフォルトでイメージの詳細情報（REPOSITORY, TAG, IMAGE ID, CREATED, SIZE）を表示します。削除に必要なのは IMAGE ID です。docker image ls には、イメージID のみを表示するための -q または --quiet オプションがあります。

bash
docker image ls -q

このコマンドは、ローカルに存在する全てのイメージの ID のみをリスト形式で出力します。

d6f748d53105
a2f391fcf71d
abcdef123456
deadbeefc0de

この出力を docker rmi コマンドの引数として渡すことで、全てのイメージを一括削除できます。

bash
docker rmi $(docker image ls -q)

注意: このコマンドは、ローカルにある全てのイメージを削除しようとします。使用中のイメージは削除されませんが、それ以外の全てのイメージ（タグ付き未使用、ぶら下がり）が対象となります。実行前に本当に全てのイメージを削除して良いか確認してください。

特定の条件でフィルタリングしたイメージの一括削除:
docker image ls コマンドの --filter オプションを使用すると、様々な条件でイメージをフィルタリングできます。このフィルタリング機能と -q オプション、そしてコマンド置換を組み合わせることで、より柔軟な一括削除が可能になります。

--filter オプションは key=value の形式で指定します。代表的なフィルタキーは以下の通りです。

  • before=<image>: 指定したイメージより前に作成されたイメージ
  • after=<image>: 指定したイメージより後に作成されたイメージ
  • since=<image>: 指定したイメージより後に作成されたイメージ (after と同じ)
  • label=<label>: 指定したラベルを持つイメージ (例: label=env=dev)
  • reference=<pattern>: 指定したパターンに一致するリポジトリ名またはタグを持つイメージ (ワイルドカード * が使えます)
  • dangling=true|false: ぶら下がりイメージ (true) またはそれ以外のイメージ (false)

例：

  1. <none>:<none> と表示されるぶら下がりイメージを全て削除:
    ぶら下がりイメージは dangling=true フィルタで選択できます。

    bash
    docker rmi $(docker image ls -q --filter "dangling=true")
    これは docker image prune のデフォルト動作と同じですが、コマンド置換を使って明示的に行う例です。

  2. 特定の名前パターンを持つイメージを全て削除:
    リポジトリ名が my-app で始まる全てのイメージを削除したい場合、reference フィルタを使用します。

    bash
    docker rmi $(docker image ls -q --filter "reference=my-app*")

  3. 特定の期間より古いイメージを削除:
    例えば、1週間 (7d) 以上更新されていないイメージを削除したい場合。until フィルタは prune コマンドで主に使用されますが、ls コマンドには before や since フィルタがあります。ここでは「作成日時」ではなく「更新日時」でのフィルタリングは ls コマンドでは直接的なフィルタがありません（prune には until があります）。代わりに、特定のイメージ ID を基準にする方法があります。より柔軟に日時でフィルタリングしたい場合は、後述の prune コマンドを使うか、ls の出力と他のコマンドを組み合わせる必要があります。

    ls の出力と他のコマンドを組み合わせる例：特定のタグ（例: dev）が付いているが、1週間以上前に作成されたイメージを削除したい場合。ls の出力には作成日時が含まれますが、これをコマンドでパースする必要があります。これは少し複雑になります。

    “`bash

    作成日時でフィルタリングし、イメージIDを取得

    例えば、awkでCREATEDカラムを見て日付を比較するなど…

    これは複雑なので、より簡単な方法として prune --filter "until=..." を使う方が一般的です。

    例外的に ls と awk を組み合わせるなら:

    docker image ls –format ‘{{.ID}} {{.CreatedAt}}’ | awk ‘$2 < “2023-10-20T00:00:00Z” { print $1 }’ | xargs docker rmi

    ↑ この例は複雑で日付フォーマットの知識が必要です。一般的には prune を推奨します。

    “`

xargs コマンドとの組み合わせ:
docker image ls -q の出力は改行区切りのリストです。これを docker rmi に渡す際に xargs コマンドを使うと、より柔軟な処理が可能になります。xargs は標準入力から読み込んだ各行をコマンドの引数として実行します。

bash
docker image ls -q | xargs docker rmi

これも docker rmi $(docker image ls -q) と同じく、全てのイメージを削除しようとします。

特定の条件でフィルタリングしたリストを xargs に渡す場合:

bash
docker image ls -q --filter "reference=old-app/*" | xargs docker rmi

この方法は、引数の数が多い場合にも対応できます（xargs は必要に応じて複数回コマンドを実行します）。

シェルスクリプトを使ったより高度な一括削除:
上記のコマンド置換や xargs の方法はコマンドラインで手軽に実行できますが、より複雑なロジックやエラー処理が必要な場合は、シェルスクリプトを作成するのが良いでしょう。

例: 特定のタグ（例: test や dev）が付いており、かつ特定の期間（例: 30日）以上前に作成されたイメージを削除するスクリプト。

“`bash

!/bin/bash

削除対象とするイメージのタグパターン (例: test, dev)

TAG_PATTERNS=(“test” “dev”)

作成からの経過日数 (例: 30日)

DAYS_OLD=30

削除対象のイメージIDを格納する配列

IMAGES_TO_DELETE=()

echo “Checking for images with tags ${TAG_PATTERNS[@]} older than ${DAYS_OLD} days…”

現在日時から指定日数を引いたタイムスタンプを計算 (Unixタイムスタンプ)

TARGET_TIMESTAMP=$(date -d “${DAYS_OLD} days ago” +%s)

全イメージ情報を取得し、フィルタリング

docker image ls –format ‘{{.ID}} {{.Repository}}:{{.Tag}} {{.CreatedAt}}’ | while read -r IMAGE_ID REPO_TAG CREATED_AT; do
# タグなしイメージはスキップ (prune で処理することが多い)
if [[ “$REPO_TAG” == “:” ]]; then
continue
fi

# 指定したタグパターンのいずれかに一致するか確認
MATCHED_TAG=false
for PATTERN in "${TAG_PATTERNS[@]}"; do
    if [[ "$REPO_TAG" == *":"$PATTERN ]]; then
        MATCHED_TAG=true
        break
    fi
    # 例: リポジトリ名にパターンを含む場合など、より複雑なパターンマッチングも可能
    # if [[ "$REPO_TAG" == *"$PATTERN"* ]]; then
    #     MATCHED_TAG=true
    #     break
    # fi
done

if [ "$MATCHED_TAG" = true ]; then
    # 作成日時をUnixタイムスタンプに変換
    # DockerのCreatedAtフォーマットは 'YYYY-MM-DD HH:MM:SS [+/-]ZZZZ' や RFC3339
    # dateコマンドでのパースは環境依存する可能性があるため注意が必要
    # 例: '2023-10-27 09:00:00 +0000' 形式の場合
    CREATED_TIMESTAMP=$(date -d "$CREATED_AT" +%s 2>/dev/null)

    if [ -z "$CREATED_TIMESTAMP" ]; then
        echo "Warning: Could not parse timestamp '$CREATED_AT' for image $IMAGE_ID. Skipping."
        continue
    fi

    # 指定日数より古いか確認
    if (( CREATED_TIMESTAMP < TARGET_TIMESTAMP )); then
        echo "Found image: $REPO_TAG ($IMAGE_ID) created on $CREATED_AT"
        IMAGES_TO_DELETE+=("$IMAGE_ID")
    fi
fi

done

削除対象のイメージがなければ終了

if [ ${#IMAGES_TO_DELETE[@]} -eq 0 ]; then
echo “No images found for deletion.”
exit 0
fi

echo “”
echo “The following images will be deleted:”
printf “%s\n” “${IMAGES_TO_DELETE[@]}”
echo “”

削除実行の確認

read -p “Proceed with deletion? (y/N): ” -n 1 -r
echo
if [[ $REPLY =~ ^[Yy]$ ]]; then
echo “Deleting images…”
# xargs を使ってまとめて削除 (引数リストが長くなりすぎないように)
printf “%s\n” “${IMAGES_TO_DELETE[@]}” | xargs docker rmi
echo “Deletion complete.”
else
echo “Deletion cancelled.”
fi
“`

このスクリプトは、特定のタグパターンを持ち、かつ指定日数より古いイメージをリストアップし、ユーザーの確認後に削除を実行します。docker image ls の出力パースや日付比較は環境や Docker バージョンによって細かい調整が必要な場合があります。このように、シェルスクリプトを使えば、より複雑な条件に基づいた柔軟な一括削除ルールを実装できます。

5. docker image prune コマンドによる未使用イメージのクリーンアップ

これまで見てきた方法（docker rmi とフィルタリング、xargs など）は、削除したいイメージを明示的に指定またはリストアップしてから削除するものでした。これに対し、docker image prune コマンドは、Docker が「不要である」と判断したイメージを自動的にクリーンアップするための専用コマンドです。

docker image prune コマンドは、特に大量のイメージが頻繁に生成・破棄される開発やCI/CD環境で非常に有用です。

docker image prune とは？
docker image prune は、ローカルの Docker ストレージから、どのコンテナからも参照されていないイメージを削除するためのコマンドです。

デフォルトの動作：ぶら下がりイメージの削除
引数なしで docker image prune を実行した場合、デフォルトではぶら下がりイメージ (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 キーを押すと削除が実行されます。

確認プロンプトと -f (--force) オプション
上記の確認プロンプトをスキップして自動的に削除を実行したい場合は、-f または --force オプションを付けます。

“`bash
docker image prune -f

または

docker image prune –force
“`

-f オプションはスクリプトや自動化されたクリーンアップタスクでよく使用されます。ただし、削除対象の確認が省略されるため、意図しないイメージが削除されないよう、対象となるイメージの種類（デフォルトではぶら下がりイメージ）をよく理解しておく必要があります。

-a (--all) オプション：全ての未使用イメージを削除
docker image prune に -a または --all オプションを付けると、削除対象がぶら下がりイメージだけでなく、どのコンテナからも参照されていない全てのイメージに拡張されます。これには、タグは付いているものの、現在実行中または停止中のどのコンテナからも使用されていないイメージが含まれます。

“`bash
docker image prune -a

または

docker image prune –all
“`

これもデフォルトでは確認プロンプトが表示されます。自動化したい場合は -f オプションを組み合わせます。

bash
docker image prune -a -f

このコマンドは強力ですが、意図せず必要なイメージ（例えば、将来使うかもしれない古いバージョンのイメージなど）まで削除してしまう可能性があるので、使用には注意が必要です。特に、タグが付いているが現在使用されていないイメージは、開発や運用で重要な役割を果たしている場合があります。-a オプションを使用する際は、本当にこれらのイメージが不要であることを確認してください。

--filter オプションを使った高度なフィルタリング
docker image prune コマンドも --filter オプションをサポートしており、削除対象をさらに細かく制御できます。prune コマンドで利用可能なフィルタキーは ls コマンドとは少し異なります。

代表的な prune 用のフィルタキー:

  • until=<timestamp> または until=<duration>: 指定したタイムスタンプまたは期間よりも前に作成されたイメージを対象とします。
    • <timestamp> 形式例: 2023-10-27T10:00:00Z, 2023-10-27 (指定時間がない場合はその日の開始時), Unixタイムスタンプ (1698380400)。
    • <duration> 形式例: 24h (24時間前), 7d (7日前), 1h30m (1時間30分前)。Go言語の duration 文字列形式で指定します。
  • label=<key> または label=<key>=<value>: 指定したラベルを持つイメージを対象とします。
  • label!=<key> または label!=<key>=<value>: 指定したラベルを持たないイメージを対象とします。
  • dangling=true|false: ぶら下がりイメージ (true) またはそれ以外のイメージ (false) を対象とします。dangling=true はデフォルトの動作です。dangling=false は -a オプションと組み合わせて、「タグ付きの未使用イメージ」を対象にする場合などに使用できます。

フィルタリングの例：

  1. 24時間以上前に作成されたぶら下がりイメージを削除:
    デフォルト動作ですが、until フィルタと明示的に組み合わせる例です。

    “`bash
    docker image prune –filter “until=24h”

    または

    docker image prune –filter “until=1d”
    “`

  2. 特定のタイムスタンプより前に作成された全ての未使用イメージを削除:
    -a オプションと until フィルタを組み合わせます。

    bash
    docker image prune -a --filter "until=2023-10-01T00:00:00Z"

  3. ラベル env=dev が付いていない全ての未使用イメージを削除:
    特定の環境（例: dev）のイメージは残しておきたいが、それ以外の未使用イメージは削除したい場合などに使えます。

    bash
    docker image prune -a --filter "label!=env=dev"

  4. ラベル stage が付いている全ての未使用イメージを削除:

    bash
    docker image prune -a --filter "label=stage"

  5. タグは付いているが使用されておらず、かつ1週間以上前に作成されたイメージを削除:
    これは -a オプション（全ての未使用イメージ）と dangling=false フィルタ（タグ付きイメージのみを対象）と until フィルタを組み合わせることで実現できます。

    bash
    docker image prune -a --filter "dangling=false" --filter "until=7d"
    複数のフィルタは AND 条件として評価されます。

docker image prune 実行時の注意点
* prune コマンドは、実行中のコンテナが参照しているイメージは削除しません。
* 停止中のコンテナが参照しているイメージは、デフォルト（-a なし）では削除されませんが、-a オプションを付けると削除対象になります。イメージが削除された後も、そのイメージを使用していた停止中のコンテナはそのまま残りますが、再起動しようとすると失敗します（参照元のイメージが存在しないため）。
* 削除されるのはイメージ本体（レイヤー）です。イメージを元に作成されたコンテナ（実行中、停止中問わず）や、そのコンテナに関連付けられたボリュームなどは削除されません（ただし、システム全体をクリーンアップする docker system prune はこれらを対象に含めることができます）。
* 共有されているレイヤーは、そのレイヤーを参照している全てのイメージが削除されるまでディスクに残ります。prune コマンドは、不要になったレイヤーのみを効果的にクリーンアップします。

6. docker system prune コマンド：システム全体をクリーンアップする

docker system prune コマンドは、Docker 環境全体にわたって不要なリソースをまとめてクリーンアップするための、より広範囲なコマンドです。

docker system prune の概要と対象:
引数なしで docker system prune を実行した場合、デフォルトで以下の未使用リソースが削除対象となります。

  • 停止中のコンテナ (stopped containers)
  • 使用されていないネットワーク (unused networks)
  • ぶら下がりイメージ (dangling images)
  • ビルドキャッシュ (build cache)

bash
docker system prune

このコマンドもデフォルトでは確認プロンプトが表示され、削除されるリソースの種類と合計解放容量の概算が表示されます。

“`
WARNING! This will remove:
– all stopped containers
– all networks not used by at least one container
– all dangling images
– all build cache

Are you sure you want to continue? [y/N]
“`

-f または --force オプションを付けると、確認プロンプトなしで実行されます。

bash
docker system prune -f

docker image prune との違い:
docker image prune はイメージのみを対象とするのに対し、docker system prune はコンテナ、ネットワーク、イメージ、ビルドキャッシュなど、より多くのリソースタイプを対象とします。docker system prune には、デフォルトで docker image prune のデフォルト動作（ぶら下がりイメージの削除）が含まれています。

-a (--all) オプションの効果（イメージへの影響）:
docker system prune に -a または --all オプションを付けると、削除対象が拡張されます。

  • 停止中のコンテナ (stopped containers) は引き続き対象。
  • 使用されていないネットワーク (unused networks) も引き続き対象。
  • ぶら下がりイメージ (dangling images) に加えて、どのコンテナからも参照されていない全てのイメージ (unused images) が対象となります。（これは docker image prune -a と同じイメージ削除動作です）。
  • ビルドキャッシュ (build cache) も引き続き対象。

bash
docker system prune -a

確認プロンプトでは、削除対象に「all unused images」が含まれることが示されます。

bash
docker system prune -a -f # 確認プロンプトなしで実行

docker system prune -a は、イメージに関しては docker image prune -a と同じ動作をするため、タグ付きの未使用イメージも削除されることに注意が必要です。

--volumes オプション：ボリュームの削除（注意）:
docker system prune は、デフォルトではボリュームを削除しません。Docker ボリュームはコンテナのライフサイクルとは独立して管理されることが多く、永続的なデータを保持するために使用されるためです。

しかし、--volumes オプションを付けて docker system prune を実行すると、どのコンテナからも参照されていないローカルボリュームも削除対象に含まれます。

“`bash
docker system prune –volumes

または

docker system prune -v
“`

このコマンドも確認プロンプトが表示されます。

“`
WARNING! This will remove:
– all stopped containers
– all networks not used by at least one container
– all dangling images
– all build cache
– all unused volumes

Are you sure you want to continue? [y/N]
“`

docker system prune --volumes は、非常に危険な操作となる可能性があります。 未使用のボリュームには、データベースのデータや設定ファイルなど、復旧が困難な重要なデータが格納されている場合があります。本当に不要なボリュームだけを削除したい場合は、docker volume ls と docker volume rm を組み合わせて手動で削除対象を選択するか、docker volume prune コマンド（未使用のボリュームのみを対象とする専用コマンド）を使用する方が安全です。

docker system prune --volumes オプションは、例えば開発環境で全ての Docker 関連リソースを完全にリセットしたい場合など、特殊な状況でのみ慎重に使用してください。

--filter オプション:
docker system prune コマンドも --filter オプションをサポートしており、削除対象をフィルタリングできます。system prune で利用可能なフィルタキーは until と label です。

  • until=<timestamp> または until=<duration>: 指定したタイムスタンプまたは期間よりも前に作成/更新されたリソースを対象とします。これは、コンテナ、イメージ、ネットワーク、ボリュームなど、対象となる全てのリソースタイプに適用されます。
  • label=<key> または label=<key>=<value>: 指定したラベルを持つリソースを対象とします。
  • label!=<key> または label!=<key>=<value>: 指定したラベルを持たないリソースを対象とします。

例:

  1. 全ての未使用リソースのうち、7日以上更新されていないものを削除:

    bash
    docker system prune -a --filter "until=7d"
    これには、7日以上前に停止したコンテナ、7日以上前に作成された未使用イメージ（タグ付き、タグなし含む）、7日以上前に作成された未使用ネットワークなどが含まれます。

  2. ラベル env=dev が付いていない全ての未使用リソースを削除:

    bash
    docker system prune -a --filter "label!=env=dev"
    これにより、開発環境 (env=dev) に関連付けられたリソースは保持しつつ、それ以外の不要なリソースをクリーンアップできます。

docker system prune 実行時の注意点:
* docker system prune は広範囲なリソースを対象とするため、実行前に削除対象をよく理解することが重要です。
* 特に --volumes オプションの使用には細心の注意が必要です。意図しないデータ消失につながる可能性があります。
* 本番環境で実行する場合は、影響範囲を十分に評価し、バックアップなどの対策を講じる必要があります。
* 定期的なクリーンアップには有用ですが、どのようなリソースが削除されるかを常に意識しておきましょう。

7. 実践的なシナリオと例

ここでは、実際の状況に応じたイメージ削除・クリーンアップの活用例を紹介します。

開発環境での手軽なクリーンアップ:
開発中は頻繁にイメージをビルドしたり、様々なイメージを試したりします。これにより、多くのぶら下がりイメージや未使用イメージが発生しやすいです。ディスク容量が気になり始めたら、手軽にクリーンアップできます。

“`bash

ぶら下がりイメージを削除 (タグなしで使われていないもの)

docker image prune

使用されていない全てのイメージを削除 (タグ付きでも使われていないものも含む)

docker image prune -a

さらに、停止中のコンテナや未使用ネットワークなどもまとめて削除

docker system prune

開発環境で全てのコンテナ、ネットワーク、イメージ、ビルドキャッシュをまとめて削除（ボリューム以外）

docker system prune -a
``
開発環境であれば、ある程度気軽にdocker system prune -a` を実行して、一時的なリソースを一掃することが多いです。

CI/CD環境での自動的なクリーンアップ:
CI/CD パイプラインでは、コミットごとに新しいイメージがビルドされることがよくあります。これにより、大量のイメージが蓄積されます。ビルドサーバーのディスク容量を維持するために、定期的に古いイメージを自動削除する設定が必要です。

例えば、1週間 (7日) 以上前のイメージを削除する場合:

“`bash

1週間以上前に作成された全ての未使用イメージを削除

docker image prune -a –filter “until=7d” -f

または、システム全体で1週間以上更新されていないリソースを削除 (コンテナ、ネットワーク、イメージ、ビルドキャッシュ)

docker system prune -a –filter “until=7d” -f
``-fオプションを付けて、確認プロンプトなしで実行するのが自動化のポイントです。どの期間を対象とするか (until` の値) は、プロジェクトのリリースサイクルやディスク容量の使用状況に合わせて調整します。

ディスク容量が不足した場合の緊急対応:
ディスク容量が逼迫してしまった場合、最も容量を占めている可能性が高いイメージやコンテナを迅速に削除する必要があります。

まず、docker system df コマンドで Docker が使用しているディスク容量の内訳を確認します。

bash
docker system df

出力例:

TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 12 5 2.5GB 1.8GB (72%)
Containers 10 3 1.2GB 800MB (66%)
Local Volumes 5 2 500MB 300MB (60%)
Build Cache 50 0 3.0GB 3.0GB (100%)
この出力を見ると、Image や Build Cache が多くの容量を占めていることが分かります。「RECLAIMABLE」の列は、prune コマンドなどで解放可能な容量の概算を示しています。この例では、Images と Build Cache の Reclaimable が高いので、これらをターゲットにします。

まず Build Cache を削除します。

bash
docker builder prune -f
ビルドキャッシュは通常、完全に再構築しない限り不要になることが多いです。

次に、イメージをクリーンアップします。緊急時であれば、使われていないイメージは全て削除することを検討します。

bash
docker image prune -a -f

さらに、停止中のコンテナも削除します（必要に応じて）。

“`bash
docker container prune -f

docker ps -a を見て個別に削除するか、system prune を使う方が一般的

“`

最終手段として、docker system prune -a -f を実行します。ただし、--volumes オプションはデフォルトでは含まれないことに注意してください。ボリュームの削除が必要な場合は、慎重に検討し、必要に応じて docker volume prune を使用します。

特定のプロジェクトに関連するイメージのみをクリーンアップ:
複数のプロジェクトに関わっている場合、特定のプロジェクトで使用しなくなったイメージだけを削除したいことがあります。プロジェクトのイメージに特定のラベル（例: project=my-project）を付けている場合、--filter オプションでこれを活用できます。

例えば、ラベル project=old-project が付いている未使用イメージを全て削除する場合:

bash
docker image prune -a --filter "label=project=old-project"

ラベルを付けていない場合は、イメージ名やタグのパターンでフィルタリングすることを検討します（ただし、命名規則が統一されている必要があります）。

“`bash

リポジトリ名が old-project/ で始まる全ての未使用イメージを削除

docker image prune -a –filter “reference=old-project/*”
“`

もし特定のイメージ名やタグ、ラベルがない場合は、手動で docker image ls の出力を確認し、削除したいイメージの ID を特定して docker rmi で削除する必要があります。

8. イメージ削除に関する注意点とベストプラクティス

Docker イメージの削除は、ディスク容量の確保や管理の効率化に役立ちますが、誤った操作は問題を引き起こす可能性があります。安全かつ効果的にイメージを管理するための注意点とベストプラクティスを以下にまとめます。

削除前に必ず確認する習慣をつける:
特に docker rmi -f や docker image prune -a、docker system prune を実行する際は、削除対象となるイメージやリソースが本当に不要なものであるかを十分に確認してください。デフォルトでプロンプトが表示されるのはそのためです。自動化されたクリーンアップタスクを設定する場合も、どの条件で何を削除するのかを明確に定義し、定期的に確認することをお勧めします。

重要なイメージには適切なタグやラベルを付ける:
誤って重要なイメージを削除してしまうリスクを減らすために、本番環境で使用するイメージや、後で参照する可能性のあるイメージには、明確で一意なタグを付けるようにしましょう。また、プロジェクト名、環境（dev, staging, prod）、作成者、バージョン管理システムのリビジョン情報などをラベルとして付与することも非常に有効です。これらのタグやラベルは、ls や prune コマンドのフィルタリングで、削除対象から特定のイメージを除外するために利用できます。

本番環境での削除作業:
本番環境でのイメージ削除は、開発環境やCI/CD環境と比べてより慎重に行う必要があります。実行中のサービスに影響を与えないことはもちろん、万が一の場合にロールバックできるよう、古いバージョンのイメージを一時的に残しておくなどの戦略が必要になる場合があります。docker system prune --volumes のような、データ消失のリスクがあるコマンドは、本番環境では原則として使用しない、あるいは極めて限定的な状況で細心の注意を払って行うべきです。本番環境では、手動で個別に削除するか、特定のリソースを対象とした安全なクリーンアップスクリプトを準備する方が良いでしょう。

定期的なクリーンアップのスケジュール化:
手動でのクリーンアップは忘れがちです。特にCI/CDサーバーや開発マシンなど、イメージが頻繁に生成される環境では、定期的にクリーンアップを実行する仕組みを導入することを検討してください。cron ジョブや CI/CD パイプラインの一部として docker image prune や docker system prune を組み込むのが一般的です。この際、-f オプションは必須となりますが、削除条件（until や label フィルタなど）を適切に設定し、必要なイメージが削除されないように注意しましょう。

--force オプションの安易な使用を避ける:
docker rmi -f や docker image prune -f、docker system prune -f の -f オプションは、確認プロンプトをスキップして強制実行するため非常に便利ですが、その分リスクも伴います。特に docker rmi -f による使用中イメージの強制削除は、コンテナの不安定化を招く可能性があるため、避けるべきです。prune 系コマンドの -f は自動化には必要ですが、削除対象をフィルタリングで厳密に制御するなど、リスクを低減する対策を講じてから使用してください。

削除されるイメージが参照しているレイヤーについて:
前述の通り、Docker イメージはレイヤー構造を持ち、レイヤーは複数のイメージ間で共有されます。イメージを削除しても、そのイメージが参照していたレイヤーが他のイメージからも参照されている場合、そのレイヤーはディスクから削除されずに残ります。完全にディスク容量を解放するためには、そのレイヤーを参照する全てのイメージが削除される必要があります。docker image prune や docker system prune コマンドは、不要になったレイヤーを自動的に検出してクリーンアップするため、レイヤー構造を意識せずとも効率的なクリーンアップが可能です。

9. まとめ：適切な方法で Docker イメージを管理しよう

Docker イメージは、アプリケーションの実行環境をポータブルにする強力なツールですが、適切に管理しないとディスク容量の消費や管理の煩雑化を招きます。この記事では、不要になった Docker イメージを削除するための様々なコマンドとその詳細な使い方を解説しました。

  • 特定のイメージを個別に削除するには docker rmi <イメージIDまたはリポジトリ名:タグ> を使用します。実行中コンテナが使用しているイメージは削除できません（-f オプションは危険です）。
  • 複数のイメージを一括で削除するには、docker rmi に複数の引数を渡す方法や、docker image ls -q とコマンド置換 ($()) や xargs を組み合わせて、フィルタリングしたイメージIDのリストを渡す方法があります。より複雑な条件で削除したい場合は、シェルスクリプトを作成することも有効です。
  • 未使用のイメージ（ぶら下がりイメージ、タグ付き未使用イメージ）を自動的にクリーンアップするには、docker image prune コマンドが最も適しています。
    • 引数なし (docker image prune): ぶら下がりイメージのみを削除。
    • -a オプション (docker image prune -a): どのコンテナからも参照されていない全てのイメージを削除。
    • --filter オプション: until, label, dangling などのフィルタを使って削除対象を細かく制御できます。
  • Docker システム全体（コンテナ、ネットワーク、イメージ、ビルドキャッシュ）の未使用リソースをまとめてクリーンアップするには、docker system prune コマンドを使用します。
    • デフォルト (docker system prune): 停止中コンテナ、未使用ネットワーク、ぶら下がりイメージ、ビルドキャッシュを削除。
    • -a オプション (docker system prune -a): さらに全ての未使用イメージも対象に含めます。
    • --volumes オプション (docker system prune --volumes): 未使用ボリュームも削除対象に含めます。データ消失のリスクがあるため、使用には細心の注意が必要です。
  • どのコマンドを使用する場合も、削除対象を事前に確認し、特に自動化する際はフィルタリングを適切に設定することが重要です。重要なイメージにはタグやラベルを付けて保護する、定期的なクリーンアップをスケジュール化するといったベストプラクティスを実践することで、Docker 環境を常にクリーンで効率的な状態に保つことができます。

これらのコマンドとテクニックを使いこなすことで、Docker イメージの管理は格段に楽になり、ディスク容量の確保、イメージリストの整理、そしてより安全な環境の維持に繋がります。ぜひご自身の Docker 環境で試してみてください。

コメントする

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

上部へスクロール