Docker 操作マニュアル

まず daemon と Compose プロジェクトを特定し、コンテナ・イメージ・ボリューム・ポートを区別する。例の名前は myapp。コマンドはクライアントで実行するが、bind mount のパスは daemon 側のもの。

やりたいこと	参照先
終了・再起動ループ	状態とログ
ポート公開とデータ保持	作成とパス
Compose の更新	設定から稼働へ
ディスク使用量が多い	対象別の整理

daemon を確認して状態を読む

接続先 daemon を確認する

# 選択中の context を表示する
docker context show

docker context ls で Endpoint と照合する。--context や DOCKER_HOST / DOCKER_CONTEXT も接続先に影響する。docker info で接続と daemon を確認し、失敗時はアドレス・サービス・権限を調べる。

コンテナと終了原因を特定する

# 終了済みも含め、名前・状態・ポートを表示する
docker ps -a --format '{{.Names}}	{{.Status}}	{{.Ports}}'

-a は停止済みも含む。以降の myapp はここで確認した名前に置き換える。Exited は終了、Restarting は再試行を示すだけで、原因は別途調べる。

# 終了コード・OOM・ヘルスチェック状態を読む
docker inspect myapp --format '{{json .State}}'

ExitCode、OOMKilled、Error、開始・終了時刻を確認する。Health があれば Log のプローブ出力を読む。下の表で次の確認先を選ぶ。

# 直近 10 分のログを最大 100 行読む
docker logs --tail 100 --since 10m myapp

--tail は行数、--since は期間。追跡は --follow を追加し Ctrl-C で終了する。対象はログドライバー経由の標準出力・標準エラーで、アプリ独自のログファイルとは限らない。

リソースとプロセスを分けて確認する

# CPU・メモリ・I/O を一度取得する
docker stats --no-stream myapp

メモリ使用量と上限を比較する。ピークは継続観測が必要で、現在の低使用率だけでは過去の OOM を否定できない。

# 現在のプロセスからアプリの起動を確認する
docker top myapp

プロセスの存在だけではログや実際のリクエスト確認の代わりにならない。

根拠	意味と次の確認
ExitCode / Error	アプリの終了ログを確認。非ゼロは Docker 自体の障害とは限らない
OOMKilled=true	制限・ホストメモリ・カーネルログを確認。137 単独では OOM と断定不可
unhealthy	Health.Log の検査結果を見る。コンテナは稼働中の場合もある
Restarting	終了原因を確認してから RestartPolicy を見る

ポートとデータの場所を明示する

ネットワークと永続ボリュームを用意する

新規作成の例。未使用名を使い、既存なら inspect してから再利用する。作成に失敗したら先に原因を解決する。

# アプリ用のユーザー定義ネットワークを作る
docker network create app-net

成功するとネットワーク ID が出る。同じネットワークのコンテナは名前で通信できる。

# コンテナとは別の寿命を持つボリュームを作る
docker volume create app-data

成功すると名前が出る。ストレージを作る操作で、アプリの保存先設定までは行わない。

ループバックにポートを公開する

# 用意したネットワークとボリュームで起動する
docker run -d --name myapp \
  --network app-net \
  --publish 127.0.0.1:8080:80 \
  --mount type=volume,src=app-data,dst=/app/data \
  --restart unless-stopped \
  --memory 512m \
  nginx:stable

-d はバックグラウンド実行、--name は名前、--memory はメモリ上限、unless-stopped は再起動方針。ID が出ても正常動作の証明ではない。ps / logs と以下のポート・マウントを確認する。

作成構文の例であり、nginx が自動的に /app/data に業務データを書くわけではない。実際のアプリの保存先を合わせる。行継続の逆斜線の後にコメントを置かない。本番は必要な版または digest を固定する。

図を準備しています

対象	意味
127.0.0.1:8080:80	daemon ホストのループバック 8080 → コンテナ 80。同一ネットワークの他コンテナはサービス名:80
--mount type=bind	ホストパスの対応付け。マウント先のイメージ内データは隠れる
--mount type=volume	Docker 管理のデータ。コンテナとは別の寿命
EXPOSE	イメージのメタデータ。ホストポートを公開しない

ポートと保存先を検証する

# ホスト側の公開アドレスとポートを確認する
docker port myapp

80/tcp が 127.0.0.1:8080 に対応することを確認する。なければ作成時の指定を調べる。

# ボリューム名・保存先・書き込み可否を確認する
docker inspect myapp --format '{{json .Mounts}}'

Type、Name、Destination、RW と実際のアプリの書き込み先を照合する。別の場所に書けば、マウントが正しくてもコンテナ層に残る。

# ネットワーク・アドレス・別名を確認する
docker inspect myapp --format '{{json .NetworkSettings.Networks}}'

コンテナ間通信は共通ネットワークと待ち受け先を確認する。DNS 設定は別途 docker exec myapp cat /etc/resolv.conf で読む。

# daemon ホスト上で公開 HTTP ポートへ接続する
curl -v http://127.0.0.1:8080/

接続先・HTTP 状態・本文を確認する。リモート context ではクライアントのループバックではなく daemon ホストで実行する。

実行中の設定を取得する・コンテナに入る

# コンテナ内設定をクライアントにコピーして確認する
docker cp myapp:/etc/nginx/nginx.conf ./nginx.running.conf

コピー元はコンテナ、先はクライアントの現在のディレクトリ。未使用または保存済みの名前を使う。設定の再読込は行わない。対話診断は別途 docker exec -it myapp sh。shell を終了しても主プロセスは止まらない。

HTTP 確認の curl は daemon ホストで実行する。リモート context では手元の localhost は別物。shell のないイメージでは exec sh が失敗するため、inspect・logs・cp などを使う。

再起動だけでは新設定にならない

Compose プロジェクトを確認する

対象の compose.yaml のディレクトリで実行する。サービス名 app は config から確認し、コンテナ名 myapp とは区別する。ディレクトリや -f / -p が違うと対象も変わる。

# 展開した設定を表示せず構文を検証する
docker compose config --quiet

通常、成功時は出力なし。ファイルや環境変数のエラーを直してから進む。

# この設定に含まれるサービスを列挙する
docker compose config --services

docker compose ps -a の既存インスタンスと照合し、app が更新対象か確かめる。

取得・反映・検証の順で更新する

# 設定のイメージを取得する。コンテナは再作成しない
docker compose pull app

取得失敗は認証・通信・参照を解決してから up へ進む。ソースから作るサービスは代わりに docker compose build app。pull と build は常に両方必要ではない。

# 設定に基づき app と必要な依存を作成・更新する
docker compose up -d app

差分によって再作成され、接続が途切れる場合がある。restart だけでは環境変数などのコンテナ設定変更は反映されない。

# 更新後の状態とヘルスチェックを確認する
docker compose ps -a app

docker compose logs --tail 100 app と実リクエストも確認する。失敗時はログを保存し、記録した前のイメージ・設定を戻して up する。データ移行は自動で巻き戻らない。

正しい Compose ディレクトリで実行し、必要なら -f と -p を指定する。restart は既存コンテナを再起動するだけで環境変数の変更を反映しない。up -d は必要に応じ再作成する。config 全出力には展開済み資格情報が含まれ得る。

コマンド	効果
docker stop -t 30 myapp	設定された停止シグナルを送り、猶予後に強制終了
docker compose down	プロジェクトのコンテナ・ネットワークを削除。通常は名前付きボリュームを保持
docker compose down -v	管理対象の名前付き・付属匿名ボリュームも削除。external は対象外

使用量を特定してから対象を削除

使用量から対象を選ぶ

# イメージ・コンテナ・ボリューム・キャッシュの使用量を確認する
docker system df -v

RECLAIMABLE は参照関係からの推定で、業務上削除可能という意味ではない。共有レイヤーのため単純合計もできない。

# 終了済みコンテナを列挙し、残す必要を個別確認する
docker container ls -a --filter status=exited

logs、inspect、マウント、書き込み層の必要なファイルを確認してから削除を決める。停止済みでも不要とは限らない。

# 不要と確認した停止コンテナを削除する
docker rm myapp

書き込み層は削除され、名前付きボリュームは残る。実行中なら上表の stop と確認を先に行う。docker ps -a で消えたことを確かめる。

# 対象ボリューム・ラベル・保存場所を確認する
docker volume inspect app-data

docker ps -a --filter volume=app-data で参照も確認し、バックアップの復元を検証する。データを破棄すると決めた場合だけ docker volume rm app-data。未参照でも不要とは限らない。

イメージの削除と移送を分ける

# イメージの参照とサイズを確認する
docker image ls

レイヤーは docker image history nginx:stable で確認する。不要と判断した IMAGE を一覧から選び docker image rm IMAGE で削除する。

# イメージとレイヤーをクライアントのアーカイブへ出す
docker save nginx:stable -o nginx-image.tar

既存バックアップを上書きしない保存先を選ぶ。転送後、次を転送先のクライアントで実行する。

# 転送先 daemon にイメージを読み込む
docker load -i nginx-image.tar

表示されたタグと docker image inspect nginx:stable の ID を確認する。ボリューム、実行設定、コンテナの現在の書き込み層は含まれない。

バックアップと保持要件を確認してから rm/rmi/volume rm を個別に行う。prune は参照状態で判断し、データの価値は分からない。save/load や commit はマウント済みボリュームのバックアップにならない。

docker.sock の操作権限はホストへの強い権限を与える。chmod 666 で解消しない。"iptables": false は nftables バックエンドへの切替設定ではない。

Docker storage · Compose up · Docker nftables