Docker コマンド早見表:build/run/exec/logs/prune を 1 枚で網羅
Docker を使い始めると、さまざまなコマンドに出会いますが、実際の開発現場で頻繁に使うのは限られています。特に build、run、exec、logs、prune の 5 つは、コンテナの作成から運用、トラブルシューティング、クリーンアップまで、ほぼ毎日のように実行するコマンドです。
この記事では、これら 5 つの主要コマンドに絞って、基本的な使い方からよく使うオプション、実践的な活用例までを 1 枚の早見表としてまとめました。初心者の方でもすぐに使えるよう、各コマンドの目的やエラー対処法も含めて解説していきます。
Docker 主要 5 コマンド早見表
| コマンド | 用途 | 基本構文 | よく使うオプション | 使用例 |
|---|---|---|---|---|
docker build | イメージ作成 | docker build -t 名前:タグ パス | -t 名前指定-f Dockerfile 指定--no-cache 再構築 | docker build -t myapp:1.0 . |
docker run | コンテナ起動 | docker run イメージ名 | -d バックグラウンド-p ポート-v マウント | docker run -d -p 8080:80 --name web nginx |
docker exec | コンテナ内操作 | docker exec コンテナ名 コマンド | -it 対話モード-u ユーザー指定-w 作業ディレクトリ | docker exec -it my-container /bin/bash |
docker logs | ログ確認 | docker logs コンテナ名 | -f リアルタイム--tail 行数指定--since 期間指定 | docker logs -f --tail 100 my-container |
docker system prune | リソース一括削除 | docker system prune | -a 全削除-f 確認スキップ--volumes ボリューム含む | docker system prune -a |
コマンド別の主要オプション早見表
docker build のオプション
| オプション | 説明 | 使用例 |
|---|---|---|
-t, --tag | イメージ名とタグを指定 | -t myapp:latest |
-f, --file | Dockerfile のパスを指定 | -f docker/Dockerfile.prod |
--no-cache | キャッシュを使わずビルド | --no-cache |
--build-arg | ビルド時の引数を渡す | --build-arg ENV=production |
--target | 特定ステージのみビルド | --target builder |
docker run のオプション
| オプション | 説明 | 使用例 |
|---|---|---|
-d, --detach | バックグラウンドで実行 | -d |
-p, --publish | ポートマッピング | -p 8080:80 |
--name | コンテナに名前を付ける | --name my-container |
-v, --volume | ボリュームマウント | -v $(pwd):/app |
-e, --env | 環境変数を設定 | -e NODE_ENV=production |
--rm | 停止時に自動削除 | --rm |
-it | 対話モードで実行 | -it |
docker exec のオプション
| オプション | 説明 | 使用例 |
|---|---|---|
-it | 対話モードで実行 | -it |
-u, --user | 実行ユーザーを指定 | -u root |
-w, --workdir | 作業ディレクトリを指定 | -w /app |
-e, --env | 環境変数を設定 | -e DEBUG=true |
docker logs のオプション
| オプション | 説明 | 使用例 |
|---|---|---|
-f, --follow | リアルタイムで追跡 | -f |
--tail | 最後の N 行だけ表示 | --tail 100 |
--since | 指定時刻以降のログを表示 | --since 10m |
--until | 指定時刻までのログを表示 | --until 2024-01-01T12:00:00 |
-t, --timestamps | タイムスタンプを表示 | -t |
docker prune のオプション
| オプション | 説明 | 使用例 |
|---|---|---|
-a, --all | 未使用イメージを全て削除 | -a |
-f, --force | 確認プロンプトをスキップ | -f |
--volumes | 未使用ボリュームも削除 | --volumes |
よく使うコマンドパターン
bash# 1. イメージをビルド
docker build -t myapp:latest .
# 2. コンテナを起動(開発環境)
docker run -d -p 3000:3000 -v $(pwd):/app --name dev myapp:latest
# 3. コンテナ内に入る
docker exec -it dev /bin/bash
# 4. ログをリアルタイムで確認
docker logs -f --tail 100 dev
# 5. 不要なリソースを削除
docker system prune -a
# 6. ディスク使用状況を確認
docker system df
背景
Docker コマンドの全体像
Docker には多数のコマンドが用意されていますが、日常的な開発では以下の流れで使うコマンドが決まっています。
以下の図は、Docker の基本的なワークフローと、各段階で使用する主要コマンドの関係を示しています。
mermaidflowchart TD
dockerfile["Dockerfile<br/>作成"] --> build["docker build<br/>イメージ作成"]
build --> run["docker run<br/>コンテナ起動"]
run --> exec["docker exec<br/>コンテナ内操作"]
run --> logs["docker logs<br/>ログ確認"]
exec --> debug["デバッグ<br/>作業"]
logs --> debug
debug --> stop["コンテナ停止"]
stop --> prune["docker prune<br/>不要リソース削除"]
prune --> build
図の要点を整理すると、以下のようになります。
- build: Dockerfile からイメージを作成する最初のステップ
- run: イメージからコンテナを起動して実行環境を構築
- exec / logs: 起動中のコンテナの状態確認やデバッグ
- prune: 不要になったリソースを削除して環境をクリーンに保つ
なぜこの 5 つのコマンドが重要なのか
開発現場では、これらのコマンドを何度も繰り返し実行します。例えば、新しい機能を追加する際は build でイメージを再構築し、run で起動、logs でエラーを確認、exec でコンテナ内に入って調査、最後に prune で古いイメージを削除する、という流れが典型的です。
つまり、この 5 つのコマンドを使いこなせれば、Docker を使った開発のほとんどのシーンに対応できるのです。
課題
Docker コマンドで初心者が直面する問題
Docker を学び始めた方や、使い慣れていない方は、以下のような課題に直面することが多いです。
以下の図は、Docker 初心者が抱える主な課題と、それがどのような問題につながるかを示しています。
mermaidflowchart LR
many["コマンドが<br/>多すぎる"] --> confused["何を使えば<br/>良いか混乱"]
option["オプションが<br/>複雑"] --> mistake["設定ミスで<br/>動かない"]
error["エラーメッセージが<br/>わかりにくい"] --> stuck["原因不明で<br/>作業停止"]
confused --> slow["開発速度の<br/>低下"]
mistake --> slow
stuck --> slow
図で示した課題を具体的に説明します。
コマンドとオプションの多さ
Docker には 40 以上のコマンドがあり、さらに各コマンドには数十のオプションが存在します。公式ドキュメントを読んでも、どれが必須でどれがオプションなのか、初見では判断が難しいです。
エラーメッセージの理解
Docker のエラーメッセージは英語で表示され、しかも複数の原因が考えられることが多いため、初心者には原因の特定が困難です。例えば「Cannot connect to the Docker daemon」というエラーは、Docker が起動していない、権限がない、ソケットパスが間違っているなど、複数の原因が考えられます。
リソース管理の難しさ
コンテナやイメージを作り続けていると、いつの間にかディスク容量を大量に消費してしまいます。どのコマンドで削除すれば良いのか、何を削除して良いのか、判断に迷うことが多いでしょう。
解決策
5 つの主要コマンドに集中する戦略
上記の課題を解決するには、頻繁に使う主要コマンドに絞って学習するのが効果的です。すべてのコマンドを覚える必要はありません。まずは以下の 5 つのコマンドを確実に使いこなせるようになりましょう。
| # | コマンド | 目的 | 使用頻度 |
|---|---|---|---|
| 1 | docker build | イメージ作成 | ★★★ |
| 2 | docker run | コンテナ起動 | ★★★ |
| 3 | docker exec | コンテナ内操作 | ★★★ |
| 4 | docker logs | ログ確認 | ★★★ |
| 5 | docker prune | リソース削除 | ★★☆ |
それぞれのコマンドには明確な役割があり、開発フローの中で必ず使う場面が訪れます。これらを段階的に学ぶことで、Docker の基本的な運用がスムーズにできるようになります。
よく使うオプションを厳選する
各コマンドには多数のオプションがありますが、実際に頻繁に使うのは 3〜5 個程度です。この記事では、実践的に使えるオプションだけを厳選して紹介します。
エラーパターンと解決方法を知る
よくあるエラーとその解決方法を知っておくことで、トラブル発生時に素早く対応できます。各コマンドの説明では、代表的なエラーコードと対処法も合わせて記載します。
具体例
ここからは、5 つの主要コマンドについて、基本的な使い方からよく使うオプション、実践的な活用例までを順に解説していきます。
docker build:イメージ作成コマンド
docker build は、Dockerfile を基にして Docker イメージを作成するコマンドです。アプリケーションの実行環境を定義した Dockerfile から、実際に起動可能なイメージファイルを生成します。
基本構文
最もシンプルな build コマンドは以下の形式です。
bashdocker build -t イメージ名:タグ パス
-t(--tag): イメージに名前とタグを付けるパス: Dockerfile が存在するディレクトリのパス(通常は.でカレントディレクトリ)
よく使うオプション一覧
実際の開発では、以下のオプションを組み合わせて使用することが多いです。
| # | オプション | 説明 | 使用例 |
|---|---|---|---|
| 1 | -t, --tag | イメージ名とタグを指定 | -t myapp:latest |
| 2 | -f, --file | Dockerfile のパスを指定 | -f docker/Dockerfile.prod |
| 3 | --no-cache | キャッシュを使わずビルド | --no-cache |
| 4 | --build-arg | ビルド時の引数を渡す | --build-arg ENV=production |
| 5 | --target | マルチステージビルドの特定ステージのみビルド | --target builder |
実践例 1:基本的なイメージ作成
以下は、Node.js アプリケーションのイメージを作成する例です。
bash# カレントディレクトリの Dockerfile からイメージを作成
docker build -t myapp:1.0 .
このコマンドは、カレントディレクトリにある Dockerfile を読み込み、myapp という名前で 1.0 というタグを付けたイメージを作成します。
実践例 2:異なる Dockerfile を指定
本番環境用と開発環境用で Dockerfile を分けている場合は、-f オプションで明示的に指定できます。
bash# 本番環境用の Dockerfile を使用してビルド
docker build -f Dockerfile.production -t myapp:prod .
実践例 3:キャッシュを使わずビルド
Dockerfile を修正したのに古いキャッシュが残っていて、変更が反映されないことがあります。そんな時は --no-cache オプションを使いましょう。
bash# キャッシュを無視して完全に再ビルド
docker build --no-cache -t myapp:latest .
実践例 4:ビルド引数を渡す
環境変数や設定値をビルド時に動的に渡したい場合は、--build-arg を使用します。
まず、Dockerfile 側で ARG 命令を定義します。
dockerfile# Dockerfile
ARG NODE_ENV=development
ENV NODE_ENV=${NODE_ENV}
RUN echo "Building for ${NODE_ENV}"
次に、ビルド時に引数を渡します。
bash# 本番環境用の設定でビルド
docker build --build-arg NODE_ENV=production -t myapp:prod .
よくあるエラーと解決方法
エラー 1:ERROR [internal] load metadata for docker.io/library/node:18
エラーコード: ERROR [internal] load metadata
エラーメッセージ:
luaERROR [internal] load metadata for docker.io/library/node:18
発生条件:
- ネットワーク接続の問題
- Docker Hub へのアクセスが制限されている
解決方法:
- インターネット接続を確認する
- プロキシ設定を確認する
- Docker Desktop を再起動する
エラー 2:COPY failed: file not found
エラーコード: COPY failed
エラーメッセージ:
csharpCOPY failed: file not found in build context or excluded by .dockerignore
発生条件:
- COPY 命令で指定したファイルが存在しない
.dockerignoreで除外されている
解決方法:
- ファイルパスが正しいか確認する(相対パスに注意)
.dockerignoreの設定を確認する- ビルドコンテキスト(
docker buildのパス引数)が正しいか確認する
docker run:コンテナ起動コマンド
docker run は、作成したイメージからコンテナを起動するコマンドです。このコマンド 1 つで、コンテナの作成と起動を同時に行えます。
基本構文
最もシンプルな run コマンドの形式は以下の通りです。
bashdocker run イメージ名:タグ
ただし、実際にはオプションを組み合わせて使うことがほとんどです。
よく使うオプション一覧
docker run は非常に多くのオプションがありますが、以下のオプションを覚えておけば大半のケースに対応できます。
| # | オプション | 説明 | 使用例 |
|---|---|---|---|
| 1 | -d, --detach | バックグラウンドで実行 | -d |
| 2 | -p, --publish | ポートマッピング(ホスト:コンテナ) | -p 8080:80 |
| 3 | --name | コンテナに名前を付ける | --name my-container |
| 4 | -v, --volume | ボリュームマウント(ホスト:コンテナ) | -v $(pwd):/app |
| 5 | -e, --env | 環境変数を設定 | -e NODE_ENV=production |
| 6 | --rm | 停止時に自動削除 | --rm |
| 7 | -it | 対話モードで実行(i=インタラクティブ、t=疑似端末) | -it |
実践例 1:Web サーバーをバックグラウンドで起動
Nginx サーバーをバックグラウンドで起動し、ホストの 8080 ポートでアクセスできるようにする例です。
bash# バックグラウンドでコンテナを起動し、ポートをマッピング
docker run -d -p 8080:80 --name web-server nginx:latest
このコマンドを実行すると、http://localhost:8080 でブラウザからアクセスできるようになります。
実践例 2:ローカルファイルをマウントして開発
開発中は、ローカルのソースコードをコンテナ内にマウントして、変更がすぐに反映されるようにすると便利です。
bash# カレントディレクトリをコンテナの /app にマウント
docker run -d \
-p 3000:3000 \
-v $(pwd):/app \
--name dev-server \
myapp:latest
この例では、ホストのカレントディレクトリがコンテナの /app にマウントされるため、ファイルを編集すればコンテナ内にも即座に反映されます。
実践例 3:環境変数を設定して起動
データベース接続情報などの機密情報や環境設定を、環境変数として渡す例です。
bash# 複数の環境変数を設定してコンテナを起動
docker run -d \
--name db-server \
-e MYSQL_ROOT_PASSWORD=secret \
-e MYSQL_DATABASE=myapp \
-p 3306:3306 \
mysql:8.0
実践例 4:一時的な作業用コンテナを起動
テストやデバッグのために一時的にコンテナを使いたい場合、--rm オプションを付けると停止時に自動削除されるので便利です。
bash# 対話モードで起動し、終了時に自動削除
docker run -it --rm ubuntu:22.04 /bin/bash
このコマンドは、Ubuntu のコンテナ内でシェルを起動し、exit で終了するとコンテナも自動的に削除されます。
実践例 5:複数オプションを組み合わせた実用例
実際の開発では、以下のように複数のオプションを組み合わせて使用することが多いです。
bash# Next.js アプリケーションを開発モードで起動
docker run -d \
--name nextjs-dev \
-p 3000:3000 \
-v $(pwd):/app \
-v /app/node_modules \
-e NODE_ENV=development \
myapp:dev \
yarn dev
このコマンドの各オプションの意味:
-d: バックグラウンドで実行--name nextjs-dev: コンテナ名を指定-p 3000:3000: ポート 3000 をマッピング-v $(pwd):/app: ソースコードをマウント-v /app/node_modules: node_modules は分離(ホストの影響を受けないようにする)-e NODE_ENV=development: 開発環境として設定yarn dev: コンテナ起動後に実行するコマンド
よくあるエラーと解決方法
エラー 1:port is already allocated
エラーコード: Bind for 0.0.0.0:8080 failed: port is already allocated
エラーメッセージ:
vbnetError response from daemon: driver failed programming external connectivity on endpoint my-container:
Bind for 0.0.0.0:8080 failed: port is already allocated
発生条件:
- 指定したポートが既に使用されている
- 別のコンテナやアプリケーションが同じポートを使用中
解決方法:
-
使用中のポートを確認する
bash# macOS/Linux lsof -i :8080 # Windows netstat -ano | findstr :8080 -
別のポート番号を使用する
bash
docker run -p 8081:80 myapp:latest -
既存のコンテナを停止する
bashdocker ps # 実行中のコンテナを確認 docker stop <コンテナID>
エラー 2:No such file or directory(ボリュームマウント時)
エラーコード: invalid mount config
エラーメッセージ:
bashdocker: Error response from daemon: invalid mount config for type "bind":
bind source path does not exist: /path/to/directory
発生条件:
-vで指定したホスト側のパスが存在しない- 相対パスの指定ミス
解決方法:
- ホスト側のディレクトリが存在するか確認する
- 絶対パスで指定する(
$(pwd)を使用) - 事前にディレクトリを作成する
bashmkdir -p /path/to/directory docker run -v /path/to/directory:/app myapp:latest
docker exec:コンテナ内操作コマンド
docker exec は、既に起動しているコンテナの中でコマンドを実行するためのコマンドです。デバッグやログ確認、設定ファイルの編集など、コンテナ内に入って作業したい時に使用します。
基本構文
基本的な exec コマンドの形式は以下の通りです。
bashdocker exec [オプション] コンテナ名 コマンド
よく使うオプション一覧
docker exec で頻繁に使うオプションは以下の通りです。
| # | オプション | 説明 | 使用例 |
|---|---|---|---|
| 1 | -it | 対話モードで実行(シェル起動時に使用) | -it |
| 2 | -u, --user | 実行ユーザーを指定 | -u root |
| 3 | -w, --workdir | 作業ディレクトリを指定 | -w /app |
| 4 | -e, --env | 環境変数を設定 | -e DEBUG=true |
実践例 1:コンテナ内でシェルを起動
最もよく使うパターンは、コンテナ内でシェル(bash や sh)を起動して対話的に操作する方法です。
bash# bash シェルでコンテナ内に入る
docker exec -it my-container /bin/bash
もし bash が入っていないコンテナ(Alpine Linux など)の場合は、sh を使用します。
bash# sh シェルでコンテナ内に入る(Alpine などで使用)
docker exec -it my-container /bin/sh
実践例 2:コンテナ内でコマンドを 1 回だけ実行
コンテナ内に入らずに、特定のコマンドだけを実行したい場合は、-it オプションなしで直接コマンドを指定します。
bash# Node.js のバージョンを確認
docker exec my-container node --version
# アプリケーションのログファイルを確認
docker exec my-container cat /var/log/app.log
実践例 3:root ユーザーでコンテナ内に入る
通常ユーザーで起動したコンテナで、システム設定を変更したい場合は root ユーザーで入る必要があります。
bash# root ユーザーでシェルを起動
docker exec -it -u root my-container /bin/bash
これにより、apt install などの管理者権限が必要な操作が可能になります。
実践例 4:特定のディレクトリで作業開始
作業ディレクトリを指定してコマンドを実行したい場合は、-w オプションを使用します。
bash# /app ディレクトリで yarn コマンドを実行
docker exec -it -w /app my-container yarn install
実践例 5:データベースコンテナへの接続
MySQL や PostgreSQL などのデータベースコンテナに接続して、クエリを実行する例です。
bash# MySQL に接続
docker exec -it db-server mysql -u root -p
# PostgreSQL に接続
docker exec -it postgres-server psql -U postgres
パスワードプロンプトが表示されるので、設定したパスワードを入力します。
実践例 6:デバッグ作業の典型的な流れ
実際の開発では、以下のような流れでコンテナ内をデバッグすることが多いです。
bash# 1. コンテナ内に入る
docker exec -it my-container /bin/bash
# 以下、コンテナ内での操作
# 2. プロセスを確認
ps aux
# 3. ログファイルを確認
tail -f /var/log/app.log
# 4. ネットワーク接続を確認
curl http://localhost:3000
# 5. 環境変数を確認
env | grep NODE
# 6. ファイルの内容を確認
cat /app/config/settings.json
# 7. 作業が終わったら exit で抜ける
exit
よくあるエラーと解決方法
エラー 1:Error: No such container
エラーコード: Error: No such container
エラーメッセージ:
javascriptError: No such container: my-container
発生条件:
- 指定したコンテナ名が存在しない
- コンテナが停止している
解決方法:
-
実行中のコンテナ一覧を確認する
bash
docker ps -
停止中も含めて全コンテナを確認する
bash
docker ps -a -
コンテナが停止している場合は起動する
bashdocker start my-container docker exec -it my-container /bin/bash
エラー 2:executable file not found in $PATH
エラーコード: OCI runtime exec failed
エラーメッセージ:
bashOCI runtime exec failed: exec failed: container_linux.go:380:
starting container process caused: exec: "/bin/bash":
executable file not found in $PATH: unknown
発生条件:
- 指定したコマンド(bash など)がコンテナ内に存在しない
- Alpine Linux など最小限のイメージを使用している
解決方法:
-
/bin/shを使用する(ほとんどのコンテナに存在)bashdocker exec -it my-container /bin/sh -
コンテナ内に bash をインストールする
bash# Alpine の場合 docker exec -it my-container apk add bash # Ubuntu/Debian の場合 docker exec -it -u root my-container apt-get update && apt-get install -y bash
docker logs:ログ確認コマンド
docker logs は、コンテナの標準出力(stdout)と標準エラー出力(stderr)を表示するコマンドです。アプリケーションのエラー調査やデバッグに欠かせません。
基本構文
最もシンプルな logs コマンドは以下の形式です。
bashdocker logs コンテナ名
よく使うオプション一覧
実際の運用では、以下のオプションを組み合わせて効率的にログを確認します。
| # | オプション | 説明 | 使用例 |
|---|---|---|---|
| 1 | -f, --follow | ログをリアルタイムで追跡(tail -f 相当) | -f |
| 2 | --tail | 最後の N 行だけ表示 | --tail 100 |
| 3 | --since | 指定時刻以降のログを表示 | --since 10m |
| 4 | --until | 指定時刻までのログを表示 | --until 2024-01-01T12:00:00 |
| 5 | -t, --timestamps | タイムスタンプを表示 | -t |
実践例 1:基本的なログ確認
コンテナの全ログを確認する最もシンプルな方法です。
bash# コンテナの全ログを表示
docker logs my-container
ただし、長時間稼働しているコンテナの場合、大量のログが出力されるため、次の例のように絞り込むのが実用的です。
実践例 2:ログをリアルタイムで監視
アプリケーションの動作をリアルタイムで確認したい場合、-f オプションを使用します。
bash# ログをリアルタイムで追跡(Ctrl+C で終了)
docker logs -f my-container
これは Linux の tail -f コマンドと同じような動作で、新しいログが出力されるたびに自動的に表示されます。
実践例 3:最新のログだけを確認
直近のログだけを見たい場合は、--tail オプションで行数を指定します。
bash# 最新の 100 行だけを表示
docker logs --tail 100 my-container
# 最新の 50 行を表示し、その後リアルタイム追跡
docker logs --tail 50 -f my-container
実践例 4:特定期間のログを抽出
エラーが発生した時間帯のログだけを確認したい場合、--since と --until を使用します。
bash# 10 分前からのログを表示
docker logs --since 10m my-container
# 1 時間前からのログを表示
docker logs --since 1h my-container
# 特定の日時からのログを表示
docker logs --since 2024-01-15T10:00:00 my-container
# 特定期間のログを表示
docker logs --since 2024-01-15T10:00:00 --until 2024-01-15T11:00:00 my-container
時間指定の形式は以下のように多様です。
10m: 10 分前1h: 1 時間前24h: 24 時間前2024-01-15T10:00:00: 絶対時刻(ISO 8601 形式)
実践例 5:タイムスタンプ付きで表示
ログにタイムスタンプを付けて表示すると、エラーが発生した時刻を特定しやすくなります。
bash# タイムスタンプ付きでログを表示
docker logs -t my-container
# タイムスタンプ付き + 最新 100 行 + リアルタイム追跡
docker logs -t --tail 100 -f my-container
実践例 6:複数コンテナのログを同時監視
複数のコンテナのログを同時に監視したい場合は、以下のようにターミナルを分割するか、別々のウィンドウで実行します。
bash# ターミナル 1: API サーバーのログ
docker logs -f api-server
# ターミナル 2: データベースのログ
docker logs -f db-server
# ターミナル 3: フロントエンドのログ
docker logs -f frontend-server
または、すべてのログをファイルに保存してから確認する方法もあります。
bash# ログをファイルに保存
docker logs my-container > app.log 2>&1
# 保存したログを確認
less app.log
実践例 7:エラーログだけを抽出
ログの中からエラーメッセージだけを抽出したい場合は、grep コマンドと組み合わせます。
bash# ERROR を含む行だけを表示
docker logs my-container | grep ERROR
# 大文字小文字を区別せずに error を検索
docker logs my-container | grep -i error
# エラーログをリアルタイムで監視
docker logs -f my-container | grep -i error
よくあるエラーと解決方法
エラー 1:ログが表示されない
エラーコード: なし(ログが空)
発生条件:
- アプリケーションがログを標準出力に出力していない
- ログがファイルに書き込まれている
解決方法:
-
アプリケーションの設定を確認し、標準出力にログを出力するように変更する
-
ログファイルの場所を確認し、
docker execで直接確認するbashdocker exec my-container cat /var/log/app.log -
アプリケーションが起動しているか確認する
bashdocker ps docker exec -it my-container ps aux
エラー 2:Error: No such container
エラーコード: Error: No such container
エラーメッセージ:
javascriptError: No such container: my-container
発生条件:
- コンテナ名が間違っている
- コンテナが削除された
解決方法:
-
実行中のコンテナを確認する
bash
docker ps -
停止中のコンテナも確認する
bash
docker ps -a -
正しいコンテナ名または ID を使用する
bash
docker logs <正しいコンテナ名または ID>
docker prune:リソース削除コマンド
docker prune は、使用していない Docker リソース(コンテナ、イメージ、ネットワーク、ボリューム)を一括削除するコマンドです。開発を続けていると、古いイメージやコンテナが溜まってディスク容量を圧迫するため、定期的なクリーンアップが必要になります。
prune 系コマンドの種類
Docker には、削除対象ごとに複数の prune コマンドが用意されています。
| # | コマンド | 削除対象 | 使用頻度 |
|---|---|---|---|
| 1 | docker system prune | 停止コンテナ + 未使用イメージ + 未使用ネットワーク | ★★★ |
| 2 | docker image prune | 未使用イメージのみ | ★★☆ |
| 3 | docker container prune | 停止コンテナのみ | ★★☆ |
| 4 | docker volume prune | 未使用ボリュームのみ | ★☆☆ |
| 5 | docker network prune | 未使用ネットワークのみ | ★☆☆ |
最もよく使うのは docker system prune で、これだけで大半のクリーンアップ作業が完了します。
docker system prune の基本構文
docker system prune は、複数種類のリソースを一度に削除できる便利なコマンドです。
bashdocker system prune [オプション]
よく使うオプション一覧
| # | オプション | 説明 | 使用例 |
|---|---|---|---|
| 1 | -a, --all | 未使用イメージを全て削除(タグなしだけでなく、使用されていないイメージすべて) | -a |
| 2 | -f, --force | 確認プロンプトをスキップ | -f |
| 3 | --volumes | 未使用ボリュームも削除 | --volumes |
実践例 1:基本的なクリーンアップ
最もシンプルな使い方は、オプションなしで実行する方法です。
bash# 停止中のコンテナ、未使用ネットワーク、タグなしイメージを削除
docker system prune
実行すると、以下のような確認メッセージが表示されます。
sqlWARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- all dangling build cache
Are you sure you want to continue? [y/N]
y を入力すると削除が開始され、削除されたリソースの合計サイズが表示されます。
実践例 2:未使用イメージも含めて完全削除
-a オプションを付けると、どのコンテナからも使用されていないイメージも全て削除されます。
bash# 未使用イメージを含めて削除
docker system prune -a
このコマンドを実行すると、以下のリソースが削除されます。
- 停止中のコンテナすべて
- どのコンテナからも使用されていないイメージすべて
- 未使用ネットワーク
- 未使用ビルドキャッシュ
実践例 3:確認なしで自動削除
CI/CD パイプラインやスクリプトで自動実行したい場合は、-f オプションで確認をスキップできます。
bash# 確認プロンプトなしで削除
docker system prune -a -f
実践例 4:ボリュームも含めて削除
ボリュームに保存されたデータも含めて完全にクリーンアップしたい場合は、--volumes オプションを追加します。
bash# ボリュームも含めて完全削除(注意:データが失われます)
docker system prune -a --volumes
注意: このコマンドは、データベースのデータなど重要な情報も削除される可能性があるため、実行前に必ずバックアップを取ってください。
実践例 5:定期的なクリーンアップスクリプト
開発環境で定期的にクリーンアップを実行するシェルスクリプトの例です。
bash#!/bin/bash
# cleanup-docker.sh
echo "Docker リソースのクリーンアップを開始します..."
# 現在の使用状況を表示
echo "=== クリーンアップ前のディスク使用状況 ==="
docker system df
# クリーンアップ実行
echo ""
echo "=== クリーンアップ実行 ==="
docker system prune -a -f
# クリーンアップ後の使用状況を表示
echo ""
echo "=== クリーンアップ後のディスク使用状況 ==="
docker system df
echo ""
echo "クリーンアップが完了しました。"
このスクリプトを保存して実行可能にします。
bash# スクリプトに実行権限を付与
chmod +x cleanup-docker.sh
# スクリプトを実行
./cleanup-docker.sh
個別リソースの削除コマンド
必要に応じて、個別のリソースだけを削除することもできます。
イメージだけを削除
bash# タグなしイメージのみ削除
docker image prune
# 未使用イメージを全て削除
docker image prune -a
コンテナだけを削除
bash# 停止中のコンテナのみ削除
docker container prune
ボリュームだけを削除
bash# 未使用ボリュームのみ削除
docker volume prune
ネットワークだけを削除
bash# 未使用ネットワークのみ削除
docker network prune
ディスク使用状況の確認
削除前後でどれだけディスク容量が削減されたか確認するには、docker system df コマンドが便利です。
bash# Docker のディスク使用状況を表示
docker system df
# 詳細情報を表示
docker system df -v
出力例:
scssTYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 15 5 2.5GB 1.8GB (72%)
Containers 8 2 150MB 100MB (66%)
Local Volumes 3 1 500MB 300MB (60%)
Build Cache 20 0 1.2GB 1.2GB (100%)
この例では、合計で約 3.4GB(1.8GB + 100MB + 300MB + 1.2GB)の容量を削減できることがわかります。
よくあるエラーと解決方法
エラー 1:削除できないボリュームがある
エラーコード: Error response from daemon
エラーメッセージ:
vbnetError response from daemon: unable to remove volume:
volume is in use - [コンテナID]
発生条件:
- ボリュームが実行中のコンテナで使用されている
解決方法:
-
使用中のコンテナを確認する
bash
docker ps -
該当コンテナを停止する
bash
docker stop <コンテナ名> -
再度 prune を実行する
bash
docker volume prune
エラー 2:イメージが削除できない
エラーコード: Error response from daemon
エラーメッセージ:
vbnetError response from daemon: conflict: unable to delete [イメージID]
(must be forced) - image is being used by stopped container [コンテナID]
発生条件:
- イメージが停止中のコンテナで使用されている
解決方法:
-
停止中のコンテナを削除する
bash
docker container prune -
その後、イメージを削除する
bash
docker image prune -a
または、docker system prune を使用すれば、コンテナとイメージを一括で削除できます。
まとめ
この記事では、Docker の日常的な開発で最も頻繁に使う 5 つのコマンド(build、run、exec、logs、prune)について、基本から実践的な使い方まで解説しました。
各コマンドの役割まとめ
| コマンド | 役割 | 主な使用場面 |
|---|---|---|
docker build | イメージ作成 | Dockerfile からアプリケーション実行環境を構築する時 |
docker run | コンテナ起動 | イメージから実際にコンテナを起動して動かす時 |
docker exec | コンテナ内操作 | 起動中のコンテナ内でコマンドを実行したり、シェルに入る時 |
docker logs | ログ確認 | アプリケーションのエラー調査やデバッグをする時 |
docker prune | リソース削除 | 不要なコンテナやイメージを削除してディスク容量を確保する時 |
学習のポイント
これら 5 つのコマンドは、以下のような順序で使われることが多いです。
- build で開発環境のイメージを作成
- run でコンテナを起動してアプリケーションを実行
- logs でエラーや動作状況を確認
- exec でコンテナ内に入ってデバッグや設定変更
- prune で古いイメージやコンテナを削除してクリーンな状態を保つ
この流れを何度も繰り返すことで、Docker の基本操作が身についていきます。
次のステップ
この 5 つのコマンドを使いこなせるようになったら、以下のステップに進むと良いでしょう。
- Docker Compose: 複数のコンテナを連携させて管理する
- ネットワーク設定: コンテナ間通信やポート設定の詳細を学ぶ
- ボリューム管理: データの永続化と共有の方法を学ぶ
- マルチステージビルド: 本番用の軽量イメージを作成する技術を学ぶ
まずは、この記事で紹介した 5 つのコマンドを実際のプロジェクトで使ってみてください。実践を重ねることで、Docker の操作が自然に身につくはずです。
関連リンク
articleDocker を用いた統一ローカル環境:新人オンボーディングを 1 日 → 1 時間へ
articleDocker で Dev Container を構築:VS Code/Codespaces で即戦力環境を配布
articleDocker マルチステージビルド設計大全:テスト分離・依存最小化・キャッシュ戦略
articleDocker コマンド早見表:build/run/exec/logs/prune を 1 枚で網羅
articleWindows WSL2 に Docker を最適導入:I/O 最適化・メモリ配分・互換性チェック
articleDocker vs Podman vs nerdctl 徹底比較:CLI 互換性・rootless・企業導入の勘所
articleJest の並列実行はなぜ速い?実行キューとワーカーの舞台裏を読み解く
articleNestJS 2025 年の全体像:Express・Fastify・Serverless の使い分け早わかり
articleGitHub Copilot Workspace 速理解:仕様 → タスク分解 →PR までの“自動開発”体験
articleMySQL InnoDB 内部構造入門:Buffer Pool/Undo/Redo を俯瞰
articleMotion(旧 Framer Motion)で学ぶ物理ベースアニメ:バネ定数・減衰・質量の直感入門
articleJavaScript Web Animations API:滑らかに動く UI を設計するための基本と実践
blogiPhone 17シリーズの発表!全モデルiPhone 16から進化したポイントを見やすく整理
blogGoogleストアから訂正案内!Pixel 10ポイント有効期限「1年」表示は誤りだった
blog【2025年8月】Googleストア「ストアポイント」は1年表記はミス?2年ルールとの整合性を検証
blogGoogleストアの注文キャンセルはなぜ起きる?Pixel 10購入前に知るべき注意点
blogPixcel 10シリーズの発表!全モデル Pixcel 9 から進化したポイントを見やすく整理
blogフロントエンドエンジニアの成長戦略:コーチングで最速スキルアップする方法
review今の自分に満足していますか?『持たざる者の逆襲 まだ何者でもない君へ』溝口勇児
reviewついに語られた業界の裏側!『フジテレビの正体』堀江貴文が描くテレビ局の本当の姿
review愛する勇気を持てば人生が変わる!『幸せになる勇気』岸見一郎・古賀史健のアドラー実践編で真の幸福を手に入れる
review週末を変えれば年収も変わる!『世界の一流は「休日」に何をしているのか』越川慎司の一流週末メソッド
review新しい自分に会いに行こう!『自分の変え方』村岡大樹の認知科学コーチングで人生リセット
review科学革命から AI 時代へ!『サピエンス全史 下巻』ユヴァル・ノア・ハラリが予見する人類の未来