Dockerの基本操作・運用コマンド｜起動・停止・ログ・Compose
LinuxサーバーのDocker Engineでコンテナの状態確認・起動・停止・ログ調査・Compose運用を行うためのガイドです。実行する前にコマンドが参照のみか、状態変更か、削除かを分け、作業対象を確認できます。
このページの目的
Dockerのよく使うコマンドを、操作対象（イメージ／コンテナ／ボリューム）と本番影響に分けて整理します。Docker Desktopの画面操作、Kubernetes、詳細なDockerfile作成は対象外です。
最初にやること
docker context showとdocker ps -aで接続先と対象コンテナを確認します。次にdocker logs・docker inspectで状態を把握し、必要な操作だけを実行します。
dockerグループへの追加はroot相当の権限を与えるため、単なる権限エラー対策として安易に行わないでください。接続先コンテキスト・ユーザー・変更承認を確認します。Dockerの運用・トラブルシューティング全6記事
目的別に運用系3件・障害系3件へ進めます。
運用系・個別テーマ
Docker Compose設定と安全な反映
compose.yamlがどのコンテナ・ポート・ボリュームを管理するか確認し、構成と反映影響を分けて判断します。
詳しく確認 →Docker運用Dockerログ確認・容量対策
docker logsとDocker Engineのログ保存方式の違い、既存コンテナへの設定反映条件を理解します。
詳しく確認 →運用・個別テーマDocker Volumeの確認とバックアップ
コンテナの削除で残るデータ・失われるデータを区別し、検証用Volumeで安全なバックアップ・リストア手順を学びます。
確認する →トラブルシューティング
Dockerコンテナ起動失敗
Docker daemonへの接続障害と、コンテナ内アプリの終了を分け、ログ・終了コード・設定を順番に調べます。
詳しく確認 →障害対応Dockerのport is already allocated
競合しているホストポート・IP・プロセスを特定し、既存サービスを停止せず変更案を判断します。
確認する →障害対応Docker daemonへ接続できない・Permission denied
接続先の設定、Docker Engine・rootlessモード、UNIXソケット権限を変更せずに確認します。
確認する →Kubernetesの運用へ進む場合はKubernetes・kubectl基本操作ガイドを参照してください。
1. 最低限押さえるDockerの3つの対象
| 対象 | 役割 | コマンド例 |
|---|---|---|
| イメージ（Image） | コンテナを作るための実行環境・ファイル内容の基になるもの | docker image ls |
| コンテナ（Container） | イメージから作られ、プロセスを実行する単位。停止してもコンテナが残る場合がある | docker ps -a |
| ボリューム（Volume） | コンテナのライフサイクルとは別にデータを保持するための仕組み | docker volume ls |
docker runはイメージから新しいコンテナを作って起動します。一方、docker startは既存の停止済みコンテナを起動します。両者は置き換え可能ではありません。
2. 操作前に接続先・バージョン・一覧を確認する
docker versionはクライアントとサーバーの情報を表示します。サーバー接続に失敗する場合は、daemonが停止しているとは限らず、CLIの接続先・ソケット権限・リモート接続などを切り分けます。
docker context showの結果がdefaultとは限りません。リモートdaemonを向いている場合、コマンドは手元のPCではなく接続先サーバーに影響します。DOCKER_HOST・DOCKER_CONTEXTなどの接続設定も確認します。リモートdaemonでのホスト側コマンドとbind mountは、CLI端末のローカル環境と区別してください。3. Docker基本コマンド早見表
| 目的 | コマンド | 影響区分 |
|---|---|---|
| 稼働中の一覧 | docker ps | 参照のみ |
| 停止済みも含む一覧 | docker ps -a | 参照のみ |
| 直近100行のログ | docker logs --tail 100 web01 | 参照のみ |
| 状態・終了コード | docker inspect web01 | 参照のみ・機密情報に注意 |
| 停止済みを再起動 | docker start web01 | 状態変更 |
| コンテナを停止 | docker stop web01 | サービス停止 |
| 稼働中を再起動 | docker restart web01 | サービス中断 |
| コンテナを削除 | docker rm web01 | 削除・復元要件確認 |
| Compose定義を確認 | docker compose config -q | 設定検証（通常は参照のみ） |
| Composeサービス一覧 | docker compose ps -a | 参照のみ |
表のweb01は説明用のコンテナ名です。操作前にdocker ps -aで実際の名前・IDを確認して置き換えます。例示された削除コマンドを本番でそのまま実行しないでください。
状態表示の想定例（実測ではありません）：docker ps -aでUp 2 minutesならプロセス稼働、Exited (0)なら終了済みです。いずれもアプリの正常性は未確認のため、Health・通信・ログを続けて確認します。
4. 新しいコンテナを作って起動する
この操作は新しいコンテナを作成し、必要に応じてイメージを取得し、プロセスを起動します。以下は検証用サーバーでの例です。ポート競合やイメージの取得元を確認してください。
-dはバックグラウンド実行、--nameは名前指定、-pはポート公開です。127.0.0.1:を指定することで、通常の全インターフェース公開を避けた検証用の例にしています。ただし既存のネットワーク設定・リバースプロキシやホスト上のプロセス構成も確認してください。
127.0.0.1指定だけで完全に隔離されると判断せず、Engineのバージョン・ホストのネットワーク・Firewallを確認してください。Docker公式の注意事項を参照。-p 8080:80のようにホストIPを省くと、設定によって外部インターフェースから到達可能になります。Dockerやホストのファイアウォール設定を踏まえ、サービス公開範囲を決めてください。テスト環境の後片付けは、対象コンテナと保持データを確認したうえで、停止後に削除します。以下は検証用demo-webだけを対象とした例です。
5. 既存コンテナの起動・停止・再起動
| 操作 | 実際に起きること | 確認ポイント |
|---|---|---|
start | 停止済みの既存コンテナを起動 | もとの設定・マウント・起動コマンドで動くか |
stop | コンテナ内のメインプロセスを停止するよう要求 | 停止猶予、アプリの終了処理、利用者への影響 |
restart | 既存コンテナを停止して起動 | 障害原因を確認せず再起動だけ繰り返さない |
rm | コンテナ自体を削除する | 書き込みデータの保存先、復元可否を事前に確認 |
docker restartは手動で再起動する操作です。--restart=always等の再起動ポリシー設定とは異なります。再起動ループが起きる場合は、ログ・終了コード・ポリシーの3点を確認してください。6. ログ・終了コード・詳細情報を確認する
docker execは稼働中のコンテナ内部で新たにコマンドを実行する操作です。上のls /は参照例ですが、docker exec自体は任意のプログラムを実行できるため、使うコマンドの副作用を個別に判断してください。最小構成イメージにはshやlsが存在しないこともあります。
| 見え方 | 最初に確認すること |
|---|---|
Up・running | 起動しているがアプリが正常とは限らない。ヘルスチェック・接続確認へ |
Exited | ExitCodeと直前のログ、メインプロセス終了理由を確認 |
Restarting | 直近ログ、再起動ポリシー、終了コードを確認 |
docker logsが空 | アプリのstdout/stderrへの出力とログドライバーの設定を確認 |
docker inspectに値が表示 | 環境変数等に認証情報が含まれることがある。出力の共有前に伏せる |
ログドライバーの種類や設定によってはdocker logsで内容を確認できません。ログがないことだけで「エラーなし」と判断しないでください。Linuxホストのサービスログ確認やsystemd journalの容量管理は、コンテナ側のログと管理対象が異なります。
7. Docker Composeの基本操作
ComposeはYAMLファイルに定義された複数サービスをまとめて扱う機能です。以下のコマンドは正しいComposeプロジェクトのディレクトリで実行し、対象のComposeファイルとプロジェクト名を確認します。
| コマンド | 主な作用 | 注意点 |
|---|---|---|
config -q | Compose設定の整合性を検証 | 環境変数・ファイル参照の不足で失敗する場合がある |
up -d | 必要なコンテナやネットワークを作成・更新して起動 | イメージや設定の差異によって再作成が発生する |
stop | サービスを停止 | サービス停止による業務影響 |
down | コンテナと既定の対象ネットワークを削除 | 名前付きボリュームは原則保持、匿名ボリュームの再利用に注意 |
down -v | さらにCompose定義の名前付き・匿名ボリュームも削除対象 | データ消失のおそれ。通常の停止目的では使わない |
docker system pruneやdocker compose down -vを、ディスク不足への最初の対応として実行しないでください。どのイメージ・コンテナ・ボリュームが業務データを保持しているかを先に確認します。8. ボリューム・ネットワーク・容量確認の注意
ホストディレクトリを直接マウントするbind mount、Dockerが管理するvolume、コンテナ自身の書き込み可能レイヤーは保存先と削除時の扱いが違います。削除前にdocker inspectのMountsを確認し、永続データの有無とバックアップ・復元方法を確かめます。
docker system dfはDockerオブジェクトが使用している容量の確認です。ホスト全体の空き容量はLinuxのディスク使用量確認、No space left on device発生時は容量不足の切り分けを併用します。
9. 結果別に最初の確認先を選ぶ
| 困っていること | 最初に見るもの |
|---|---|
| コンテナが一覧に見えない | docker ps -aとCLIの接続先コンテキストを確認 |
| コンテナが起動直後に停止する | docker logs --tail 100、終了コード、イメージの起動設定を確認 |
| コンテナが再起動を繰り返す | 状態・終了コード・再起動回数・ポリシーを確認。ログ取得前に無闇に再起動しない |
| Composeファイルでエラー | docker compose config -q、実行ディレクトリ・変数・Composeファイルを確認 |
| ログが表示されない | ログドライバー、stdout/stderr、アプリ独自ログを確認 |
| 通信できない・容量がない | Linuxネットワーク疎通と容量不足へ |
このページは基本操作の入口です。Docker固有の起動障害・Compose障害は今後別ページを設ける場合も、ここで説明したコマンドの意味を繰り返さず、各症状の原因判定に専念させます。
10. 本番操作前のチェックリスト
- 対象のDocker contextとサーバーが正しいか
- コンテナ名・Composeプロジェクト・対象サービスを確認したか
- 参照操作と、停止・再作成・削除のどれを実行するか区別したか
- ポート公開先・データの保存先・バックアップ状況を確認したか
- 業務影響、保守時間帯、ロールバック手順、関連ログの取得方法を確かめたか
- 作業後にコンテナ状態・アプリヘルス・通信・ログを再確認するか
docker context show → docker ps -a → docker logs・docker inspectで事実を集め、必要な場合だけ状態変更を行います。docker stopやdownの実行自体を成功判定にせず、業務の正常性を確認してください。11. 操作後に正常性を判定する
runningだけで完了としません。検証用nginxの例ではcurl -fI http://127.0.0.1:8080/の応答を確認し、本番アプリでは監視、依存先、業務操作、外部公開範囲も照合します。docker inspectの出力には秘匿値が含まれる場合があるため共有前に確認してください。
変更を伴う詳細手順はComposeの変更・切り戻し、Volumeの整合性と復元、ログ保持設定に分離しています。失敗時は起動失敗の原因別調査へ進んでください。