Docker よく使うコマンドメモ：デプロイ、更新、トラブルシューティングで本当に使うものだけ

Docker のコマンド自体はそれほど多くないのですが、ややこしいのはすぐに混同してしまうことです。

新しいイメージをプルしたのに、Webサイトが古いバージョンのまま動いていたり、コンテナを削除して再作成したらデータベースも一緒に消えてしまったり、サーバーのディスクがいきなりいっぱいになって調べてみたら Docker のログファイルが原因だったり。

これらの問題は複雑ではありませんが、しばらくすると必ず一度は遭遇します。いざ問題が発生してからドキュメントを調べ直すと、またパラメータを確認するのに時間がかかってしまいます。

そこで、日頃サーバーのデプロイやメンテナンスでよく使う Docker コマンドをまとめておきました。

これは完全な Docker マニュアルではありません。一年に一度も使わないようなパラメータまでは収録していません。日常的に最もよく使う操作と、データ消失につながる可能性のあるコマンドだけをまとめています。

はじめに：Docker の構成要素を把握しておく

Docker のコマンドが混同しやすいのは、イメージ、コンテナ、ボリューム、ネットワークが同時に出てくるからです。

それぞれの関係はおおよそ次のとおりです。

一、まずは Docker の現在の状態を確認する

Docker で問題が発生したとき、私はすぐにサービスを再起動せず、まずはコンテナの状態を確認します。

docker ps

このコマンドは実行中のコンテナだけを表示します。

停止中のコンテナも見たい場合は、-a を追加します。

docker ps -a

出力で特に重要なのは以下の項目です。

• NAMES：コンテナ名
• IMAGE：使用しているイメージ
• STATUS：現在の状態
• PORTS：ポートマッピング

コンテナによっては、起動後すぐに終了してしまうものもあります。その場合、docker ps だけでは確認できないため、以下を使う必要があります。

docker ps -a

Docker が現在使用しているディスク容量を確認するには、以下を実行します。

docker system df

イメージ、コンテナ、ボリュームごとのより詳細な使用量を確認するには、以下を実行します。

docker system df -v

サーバーのディスクが突然いっぱいになったとき、この 2 つのコマンドがとても役立ちます。

不要一看到 /var/lib/docker 很大，就直接进去删除文件。这个目录由 Docker 自己管理，手动删除里面的内容，很容易把整个 Docker 环境弄坏。

二、コンテナのログを確認する

コンテナの起動に失敗したら、最初にやるべきことはコンテナの中に入ることではなく、ログを確認することです。

docker logs 容器名称

例：

docker logs nginx

ログが多すぎる場合は、最後の 100 行だけ見ることができます。

docker logs --tail 100 nginx

新しいログを継続的に表示する：

docker logs -f nginx

私が普段よく使うのは、次の組み合わせです。

docker logs -f --tail 200 nginx

最初に最後の 200 行のログを表示し、その後は新しく出力されるログを継続的に表示します。

直近 30 分のログを確認する：

docker logs --since 30m nginx

コンテナが再起動を繰り返す場合は、2 つのターミナルを同時に開きます。

1 つ目のターミナルで状態を確認：

docker ps

2 つ目のターミナルでログを継続的に確認：

docker logs -f --tail 200 容器名称

一般的に、環境変数の欠落、設定ファイルの誤り、ディレクトリの権限不足、データベースへの接続失敗などは、すべてログの中に手がかりがあります。

三、コンテナの起動・停止・再起動

既存のコンテナを起動する：

docker start 容器名称

コンテナを停止する：

docker stop 容器名称

コンテナを再起動する：

docker restart 容器名称

例：

docker restart nginx

docker stop は先にコンテナ内のプログラムに正常終了するよう通知します。

PostgreSQL、MySQL、Redis のようにデータを書き込むサービスの場合は、docker stop を優先して使い、プログラムにデータ保存とファイルクローズの時間を与えるべきです。

コンテナが完全に応答しなくなった場合にのみ、以下を検討します。

docker kill 容器名称

docker kill はコンテナプロセスを直接強制終了するため、docker stop よりも強力です。

コンテナのフリーズを解決できますが、日常的な再起動手段として使うべきではありません。

四、コンテナの中に入る

コンテナに入るには通常、以下を使います。

docker exec -it 容器名称 bash

例：

docker exec -it nginx bash

ただし、すべてのイメージに Bash がインストールされているわけではありません。

Alpine などの軽量イメージには通常、sh しかありません。

docker exec -it nginx sh

root ユーザーで入る必要がある場合：

docker exec -it -u root 容器名称 sh

インタラクティブなターミナルに入らずに、コマンドを 1 つだけ実行することもできます。

docker exec nginx ls -lah /etc/nginx

コマンドの中にcd、パイプ、複数の操作が含まれる場合は、sh -c を使う必要があります。

docker exec nginx sh -c 'cd /etc/nginx && ls -lah'

以下のような書き方は通常、動作しません。

docker exec nginx "cd /etc/nginx && ls"

なぜなら、cd は独立した実行可能プログラムではなく、シェルの内部コマンドだからです。

コンテナの中に入るのは問題の切り分けには適していますが、長期的な設定変更には向きません。

例えば、コンテナ内で/etc/nginx/nginx.conf を修正しても、次にコンテナが再作成されると、それらの変更はほぼ確実に消えてしまいます。

本当に長期間保持すべき設定は、Dockerfile に書くか、ホスト側からマウントする必要があります。

五、イメージの基本操作

ローカルにあるイメージを確認する：

docker images

次のようにも書けます：

docker image ls

イメージをプルする：

docker pull nginx

バージョンを指定する：

docker pull nginx:1.29-alpine

本番環境では、明確なバージョンを指定すべきであり、常に

nginx:latest

latest を使うのは避けるべきです。

今日プルしたlatest と数か月後にプルしたlatest は、中身がまったく異なる可能性があります。これにより更新は簡単になりますが、問題が発生したときのロールバックが難しくなります。

イメージを削除する：

docker rmi 镜像名称

例：

docker rmi nginx:1.29-alpine

イメージがまだ何らかのコンテナに使用されている場合、Docker は削除を拒否します。

そのコンテナが停止していても、イメージを参照している可能性があります。まず以下のコマンドで確認しましょう。

docker ps -a

六、新しいイメージをプルしたのに、なぜプログラムは古いままなのか

これは Docker を使う上で非常に誤解されやすいポイントです。

実行する：

docker pull nginx:latest

これは単に新しいイメージをサーバーにダウンロードしただけです。

すでに実行中のコンテナは自動的には新しいイメージに置き換わりません。コンテナ作成時に使用されたイメージがすでに決まっているからです。

Docker Compose プロジェクトでは、通常以下を実行する必要があります。

docker compose pull
docker compose up -d

1 つ目のコマンドでイメージをプルし、2 つ目のコマンドで新しいイメージに基づいてコンテナを再作成します。

だけを実行しても、

docker compose restart

通常は効果がありません。

restart は元のコンテナを再起動するだけで、イメージを置き換えたり、新しく変更したポートやディレクトリのマウント、環境変数を適用したりしません。

そのため、compose.yaml を変更した後は、以下を実行すべきです。

docker compose up -d

コンテナが正しく再作成されなかった疑いがある場合は、以下を使います。

docker compose up -d --force-recreate

ただし、ほとんどの場合は通常のdocker compose up -d で十分です。

七、Docker Compose のよく使うコマンド

現在の新しいバージョンの Docker では、通常以下を使います。

docker compose

古いバージョンではなく：

docker-compose

プロジェクトを起動する：

docker compose up -d

-d はバックグラウンド実行を意味します。

プロジェクトの状態を確認する：

docker compose ps

ログを確認する：

docker compose logs

ログを継続的に確認する：

docker compose logs -f

特定のサービスのみを確認する：

docker compose logs -f web

プロジェクト内のコンテナを停止するが、削除はしない：

docker compose stop

再起動する：

docker compose start

プロジェクトのコンテナを停止して削除する：

docker compose down

イメージを再構築して起動する：

docker compose up -d --build

リモートのイメージをプルする：

docker compose pull

Compose ファイルにフォーマットエラーがないか確認する：

docker compose config

確認だけして、完全な設定を出力したくない場合：

docker compose config -q

プロジェクトを更新する前に、私はまず以下を実行します。

docker compose config -q

何も出力がなければ、通常は設定の構文に問題はありません。

八、より確実なアップデート手順

プロジェクトが以下にあるとします。

/opt/myapp

まずプロジェクトディレクトリに移動します。

cd /opt/myapp

設定を確認する：

docker compose config -q

現在の実行状態を確認する：

docker compose ps

新しいイメージをプルする：

docker compose pull

コンテナを再作成する：

docker compose up -d --remove-orphans

更新後の状態を確認する：

docker compose ps

最後にログを確認する：

docker compose logs --tail 200

プログラムが正常に動作していれば、その後に古いイメージのクリーンアップを検討します。

docker image prune

クリーンアップ処理を更新手順の最初に置かないでください。

新しいバージョンが正常に動作していることを先に確認してから、古いイメージを削除します。そうすれば、問題が発生したときに少なくとも古いバージョンを再び使う機会が残ります。

九、データはどこに保存されるのか

Docker コンテナ自体は重要なデータを保存するのに適していません。

コンテナを削除すると、その書き込み可能層も削除されます。

長期間保存する必要があるデータは、通常次の 2 つの場所に置きます。

1. Docker ボリューム
2. ホストのディレクトリ

ボリュームを確認する：

docker volume ls

特定のボリュームの情報を確認する：

docker volume inspect 数据卷名称

例：

docker volume inspect postgres-data

Compose でのよくあるボリュームの書き方：

services:
  database:
    image: postgres:18
    volumes:
      - postgres-data:/var/lib/postgresql/data

volumes:
  postgres-data:

こうすれば、コンテナを削除しても、postgres-data ボリュームは通常そのまま残ります。

ホストのディレクトリを使う場合は、次のように書きます。

services:
  app:
    image: myapp:1.0.0
    volumes:
      - /opt/myapp/data:/app/data

左側がホスト側のディレクトリ：

/opt/myapp/data

右側がコンテナ内部のディレクトリ：

/app/data

ここで最も問題になりやすいのは、パスの書き間違いです。

コンテナにもともと/app/config 内に設定ファイルが含まれているのに、空のディレクトリをマウントしたとします。

volumes:
  - /opt/myapp/config:/app/config

すると、コンテナ本来の/app/config がホストの空ディレクトリで上書きされます。

プログラムを起動すると、設定ファイルが突然消えたように振る舞います。

そのため、マウントする前にホスト側のディレクトリが存在するか、中に正しいファイルがあるかを確認しておくのが賢明です。

ls -lah /opt/myapp/config

十、コンテナ同士の接続方法

同じ Compose プロジェクト内のサービスは、サービス名を使って直接接続できます。

例：

services:
  app:
    image: myapp:1.0.0

  database:
    image: postgres:18

アプリケーションがデータベースに接続するとき、アドレスは次のように書くべきです。

database:5432

コンテナの IP をハードコードしてはいけません。

172.20.0.3:5432

コンテナを再作成すると IP アドレスは変わることがありますが、サービス名は通常変わりません。

Docker ネットワークを確認する：

docker network ls

ネットワークの詳細情報を確認する：

docker network inspect 网络名称

カスタムネットワークを作成する：

docker network create my-network

既存のコンテナをネットワークに追加する：

docker network connect my-network 容器名称

2 つのコンテナが互いにアクセスできない場合は、まず同じ Docker ネットワーク内にいるかどうかを確認してください。

十一、ポートをすべてパブリックネットワークに公開しない

以下の設定：

ports:
  - "8080:80"

これは通常、ホストの 8080 ポートをコンテナの 80 ポートにマッピングすることを意味します。

デフォルトでは、すべてのネットワークインターフェースで待ち受ける可能性があります。

0.0.0.0:8080

つまり、サーバーのファイアウォールが許可していれば、外部デバイスがこのポートにアクセスできる可能性があります。

サービスがホスト上の Nginx や OpenResty にのみ提供すればよい場合は、ローカルホストにバインドできます。

ports:
  - "127.0.0.1:8080:80"

こうすれば、外部ネットワークからは直接アクセスできず、ホストのローカル接続のみが可能になります。

データベースや Redis も、通常はパブリックネットワークに直接公開する必要はありません。

同じ Compose ネットワーク内のアプリケーションは、直接アクセスできます。

database:5432
redis:6379

すべての内部サービスにports を設定する必要はありません。

十二、リソース使用量の確認

全コンテナの CPU とメモリ使用量をリアルタイムで確認する：

docker stats

1 回だけ出力する：

docker stats --no-stream

特定のコンテナを指定する：

docker stats nginx

コンテナ内のプロセスを確認する：

docker top nginx

コンテナが突然終了した場合、メモリ不足でシステムによって強制終了されていないか確認できます。

docker inspect --format '{{.State.OOMKilled}}' 容器名称

次のように返ってきた場合：

true

このコンテナで OOM Kill（メモリ不足によるカーネルによる強制終了）が発生したことを示しています。

終了コードも確認できます：

docker inspect --format '{{.State.ExitCode}}' 容器名称

再起動回数を確認する：

docker inspect --format '{{.RestartCount}}' 容器名称

これらの情報は、コンテナが再起動を繰り返す問題の調査に非常に役立ちます。

十三、Docker のログがディスクを圧迫する理由

Docker はデフォルトでjson-file を使用してコンテナのログを保存することがあります。

ログローテーションを設定していないと、ログファイルが際限なく増え続けます。

変更する：

/etc/docker/daemon.json

以下を追加します。

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

これは次のことを意味します。

• 各ログファイルの最大サイズは 10MB
• 最大 3 つのログファイルを保持

変更が完了したら Docker を再起動します。

sudo systemctl restart docker

ただし、新しいログ設定は通常、以後作成されるコンテナにのみ適用されることに注意してください。

すでに存在するコンテナは再作成が必要な場合があります。

Compose でもサービスごとに個別に設定できます。

services:
  app:
    image: myapp:1.0.0
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

サーバーのディスク容量がなぜか減り続ける場合、データベースやアップロードファイルだけでなく、Docker のログも確認すべきです。

十四、Docker のスペースをクリーンアップする

停止済みのコンテナを削除する：

docker container prune

未使用のイメージ（ dangling イメージ）を削除する：

docker image prune

使われていないネットワークを削除する：

docker network prune

使われていないボリュームを削除する：

docker volume prune

総合的にクリーンアップする：

docker system prune

これらのコマンドはすべて確認を求められます。

しかし、「未使用」という言葉を見ただけで、その中のデータに価値がないと判断してはいけません。

例えば、データベースコンテナが削除された後、対応するボリュームは一時的にどのコンテナからも使われていない状態になることがあります。Docker はそれを未使用ボリュームと判断しますが、データベースファイルはまだその中にあります。

以下のコマンドを実行する前は、細心の注意が必要です。

docker volume prune -a

docker system prune -a --volumes

docker compose down -v

特に以下：

docker compose down -v

通常の：

docker compose down

はコンテナとネットワークのみ削除します。

加上 -v 以后，还会删除项目使用的数据卷。如果 PostgreSQL、MySQL 或上传文件保存在这些数据卷中，数据也会一起消失。

クリーンアップの前に、少なくとも以下を確認しましょう。

docker ps -a
docker images
docker volume ls
docker system df -v

不要把 docker system prune -a --volumes 当成日常清理命令。

これはむしろ「これらのものはすべて不要だと確認した」という意思を示すコマンドです。

十五、ディレクトリのパーミッションエラーへの対処

コンテナがホストのディレクトリをマウントした後、プログラムが次のようなエラーを出すことがあります。

Permission denied

まずホスト側のディレクトリのパーミッションを確認します。

ls -ld /opt/myapp/data

ファイルに対応する UID と GID を確認する：

ls -ln /opt/myapp/data

次にコンテナ内のプログラムが使用するユーザーを確認します。

docker exec 容器名称 id

コンテナが UID 1000、GID 1000 を使用している場合、実情に応じてホスト側のディレクトリの所有者を変更します。

sudo chown -R 1000:1000 /opt/myapp/data

権限の問題に遭遇したとき、多くの人はすぐに以下を実行します。

chmod -R 777 /opt/myapp/data

これで一時的に問題が解決することもありますが、通常は正しい対処法ではありません。

777 はすべてのユーザーに読み取り・書き込み・実行権限を与えるため、本当の UID、GID、ディレクトリの所有権の問題を隠してしまいます。

まずコンテナがどのユーザーで動作しているかを確認し、それから対応する権限を調整する方が、通常はより確実です。

十六、混同しやすいポイント

docker pull は実行中のコンテナを更新しない

これは単にイメージをダウンロードするだけです。

Compose プロジェクトを更新するには、さらに以下が必要です。

docker compose up -d

docker restart は新しい設定を適用しない

これは元のコンテナを再起動するだけです。

Compose ファイルを変更した後は、以下を使用すべきです。

docker compose up -d

コンテナを削除してもボリュームは削除されないとは限らない

通常の：

docker rm 容器名称

は名前付きボリュームを削除しません。

しかし：

docker rm -v 容器名称

はコンテナが使用している匿名ボリュームを削除する可能性があります。

コンテナ内で手動で変更したファイルは信頼できない

コンテナを再作成すると、変更内容が消える可能性があります。

長期間保持すべき設定は、Dockerfile、Compose ファイル、またはホストのマウントディレクトリに記述すべきです。

コンテナの IP に依存しない

コンテナ名または Compose のサービス名を使ってアクセスします。

すべてのポートをパブリックネットワークにマッピングしない

内部サービスはできるだけ Docker ネットワーク内に閉じ込めます。

十七、私が日常的に最もよく使うコマンド群

コンテナを確認する：

docker ps -a

ログを確認する：

docker logs -f --tail 200 容器名称

コンテナに入る：

docker exec -it 容器名称 sh

リソースを確認する：

docker stats

ディスク使用量を確認する：

docker system df -v

Compose の設定を確認する：

docker compose config -q

Compose プロジェクトを更新する：

docker compose pull
docker compose up -d --remove-orphans

更新後の状態を確認する：

docker compose ps
docker compose logs --tail 200

これらのコマンドで、日常的なデプロイ、更新、トラブルシューティングのほとんどをカバーできます。

おわりに

Docker で最も誤解されやすいのは、コンテナが小型のサーバーのように見えることです。

しかし、コンテナは仮想マシンではありません。

コンテナは、いつでも削除され、再作成され、置き換えられる実行環境のようなものです。本当に重要なものは、コンテナの中だけに置くべきではありません。

プログラムはイメージの中に、設定は Compose またはマウントディレクトリに、データはボリュームまたは独立したストレージに。コンテナに問題が起きたら、再作成すればよいのです。

これを理解すれば、多くの Docker コマンドを無理に暗記する必要はなくなります。

最後に、もう一度注意します。以下のようなパラメータを見かけたら、実行する前に一度止まって考えてください。

-v
--volumes
prune
rm -f
--privileged

これらは必ずしも危険というわけではありませんが、データの削除、強制操作、コンテナ権限の拡大を意味することが多いです。

特にこのコマンド：

docker compose down -v

データのバックアップを確認するまでは、むやみに実行しないでください。