Dockerコンテナデバッグガイド：execコマンドで内部に入って問題を特定する正しい方法

金曜の午後3時、テスト環境のAPIが突然「502 Bad Gateway」を返し始めました。
慌てて docker ps を叩くと、コンテナのステータスは「Up 2 hours」。落ちてはいません。
docker logs を見ても、冷たい「Connection refused」の文字だけ。

こういう時が一番焦りますよね。「外からは動いているように見えるのに、中身が死んでいる」。
設定ファイルが間違っているのか？ プロセスが固まっているのか？ そもそもポートが開いていないのか？
これを確認するには、コンテナというブラックボックスの**「中に入る」**しかありません。

正直に言うと、私がDockerを使い始めた頃は「入り方」が分からず、適当にググった docker attach を使ってコンテナを停止させてしまったり、中に vim がなくて途方に暮れたりしました。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

この記事では、そんな失敗をしないための「正しいコンテナへの入り方（exec）」と、中で行うべき「プロのデバッグ手順」を解説します。

基礎：正しいコンテナの「入り方」

最もよく使うコマンド

コンテナに入る（ログインする）ための標準コマンドはこれです：

docker exec -it my-nginx bash

パラメータ解説：

• -it：-i（入力を受け付ける）と -t（ターミナルを割り当てる）の組み合わせ。「対話モードにする」という意味です。
• my-nginx：入りたいコンテナの名前（またはID）。
• bash：中で実行したいプログラム（シェル）。

実行するとプロンプトが root@abc123def456:/# のように変わり、コンテナ内部をLinuxサーバーのように操作できるようになります。

「bashがない」と言われたら？

Alpine Linuxベースの軽量イメージなどでは、以下のエラーが出ることがあります：

OCI runtime exec failed: ... executable file not found

これは bash がインストールされていないためです。その場合は sh を使いましょう：

docker exec -it my-alpine sh

私の経験上、とりあえず bash を試して、ダメなら sh。これで99%解決します。

安全な出方

作業が終わったら、以下のコマンドで抜けます：

exit

またはショートカット Ctrl + D。
重要：execで入っている場合、exitしてもコンテナは停止しません。 安心してください。

exec vs attach：絶対に間違えてはいけない違い

多くの初心者がここで躓きます。「attach」というコマンドもあるからです。

違いを一言で言うと：

• exec：新しい「別の入口」を作って入る（推奨）。
• attach：メインプロセスの「画面」を共有する（危険）。

なぜattachが危険なのか？
docker attach my-nginx で入ると、あなたはNginxが動いているメインプロセスそのものに接続します。
ここでうっかり「終わったから出よう」として Ctrl + C を押すと……メインプロセスに終了信号が送られ、コンテナ自体が停止します。

Alibaba Cloud - 開発者向けクラウドの第一候補、ライトサーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

本番環境でこれをやると大事故になります。
「デバッグには必ず exec を使う」。 これだけは覚えて帰ってください。

コンテナ内で「道具がない」問題の対処法

コンテナに入れた！設定ファイルを確認しよう……と思った矢先：

root@abc:/# vim /etc/nginx/nginx.conf
bash: vim: command not found
root@abc:/# ping google.com
bash: ping: command not found

「何もねえ！」
Dockerイメージは軽量化のため、vimもpingもcurlも入っていないことが普通です。

解決策1：一時的にインストールする

開発環境や緊急時なら、その場で入れてしまいましょう。

Debian/Ubuntu系 (apt)

apt-get update
apt-get install -y vim curl iputils-ping net-tools

Alpine系 (apk)

apk update
apk add vim curl bash

CentOS系 (yum)

yum install -y vim curl

※注意：ここでインストールしたツールは、コンテナを再起動すると消えます。

解決策2：cat / sed で乗り切る（本番向け）

本番環境のコンテナに勝手にツールを入れるのは、セキュリティや汚染の観点から推奨されません。
あるもので戦いましょう。

ファイルを見る： vim がなくても cat や less、head はあります。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

cat /etc/nginx/nginx.conf

ファイルを編集する： sed や echo を使います。

# 設定を上書き追記
echo "debug_mode=on" >> config.ini

# 置換する（listen 80 -> 8080）
sed -i 's/listen 80/listen 8080/g' /etc/nginx/nginx.conf

ユーザー権限のトラブルシュート

「Permission denied」でファイルが見れない/書けないことがあります。
コンテナはセキュリティのため、非rootユーザーで動いている場合があるからです。

そんな時は、強制的にrootで入る オプションを使います：

docker exec -it -u 0 my-app bash
# -u 0 は rootユーザー（UID 0）を指定

または

docker exec -it --user root my-app bash

これで神の権限（root）が手に入ります。ただし、作成したファイルの所有権などが変わってしまうので、作業には注意が必要です。

プロのデバッグ・ワークフロー

トラブル発生時、私はいつもこの手順で調査します。

Step 1. 外からログを見る
まずは入らずにログ確認。

docker logs --tail 100 my-app

Step 2. 中に入ってプロセス確認
ログで分からなければ侵入します。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

docker exec -it my-app bash
ps aux

「あるはずのプロセス（php-fpmなど）が死んでいないか？」を確認。

Step 3. 設定ファイルと環境変数の確認
設定ミスは最も多い原因です。

cat /app/config/settings.yaml
env | grep DB_PASSWORD

「環境変数が渡っていない」「パスワードが間違っている」ことがよくあります。

Step 4. ネットワーク疎通確認
DBに繋がらない？ curlで叩いてみます。

curl http://mysql:3306
# pingが入っていない事が多いので、curlやnc（netcat）が便利です

Step 5. 最後の手段：ファイル修正と再起動（reload）
設定ファイルを修正し、サービスをリロードします。

nginx -s reload
kill -HUP 1  # メインプロセスに設定再読み込みシグナルを送る

まとめ

コンテナのデバッグは、黒魔術ではありません。正しいドア（exec）から入り、基本的なLinuxコマンドで調査するだけです。

1. docker exec -it <コンテナ> bash で入る（attachは禁止）。
2. bash がなければ sh。
3. ツールがなければ apt-get か cat で代用。
4. 権限がなければ -u root。

これだけ覚えておけば、もう「Upしているのに繋がらない」ゾンビコンテナの前で立ち尽くすことはありません。さあ、自信を持ってブラックボックスの中へ飛び込みましょう！

3 min read · 公開日: 2025年12月18日 · 更新日: 2026年1月22日

Easton

技術開発