実行中のコンテナに入る - docker exec

docker exec -it CONTAINER bash は最頻出の組み合わせ。

-i で stdin をつなぎ、-t で TTY を割り当てる。

これでカーソル移動や Ctrl+C が効く対話シェルになる。

用途は、設定ファイルの確認、権限の検証、アプリが吐いたファイルの中身を見る、DNS 解決が通るか試す、などさまざま。

ただし docker exec は一時的な調査用途に限定し、永続的な変更はイメージに戻すこと。

コンテナ内で apt-get install しても次回起動では消えるし、再現性もない。

調査で得た知見は Dockerfile か compose の設定として恒久化するのが原則。

docker exec -it api bash
# inside the container
ps -ef
cat /etc/nginx/nginx.conf
exit

ベースイメージごとに使えるシェルとパッケージマネージャが違う。

docker exec -it alpine-container bash でエラーになるのはこれが原因。

ベース	シェル	パッケージマネージャ	デバッグツール追加例
debian / ubuntu	bash	apt-get	apt-get update && apt-get install -y procps curl
alpine	sh（bash なし）	apk	apk add --no-cache procps curl
distroless / scratch	なし	なし	kubectl debug / docker run --pid=container:TARGET で別コンテナを隣接

distroless イメージは意図的にシェルを外しているので、シェル経由の調査は別コンテナを隣接させる手法に切り替える。

# Alpine
docker exec -it web sh
apk add --no-cache curl

# Debian
docker exec -it web bash
apt-get update && apt-get install -y curl

サイズ差はそのまま pull 時間、ストレージ、脆弱性スキャン対象ファイル数に影響する。

項目	Alpine	Debian slim	Debian (full)
libc	musl	glibc	glibc
基本ユーティリティ	BusyBox	GNU coreutils	GNU coreutils
イメージサイズ目安	約 5MB	70〜80MB	約 120MB
パッケージマネージャ	apk	apt-get	apt-get

向き・不向き（用途別の判断）

• Node.js や Go の静的バイナリ中心のアプリ: Alpine が実用的
• Python アプリ: manylinux wheel が musl 上でそのまま動かずソースビルドで遅くなるため、Debian ベースを選ぶケースが多い
• Node.js のネイティブモジュール / glibc 前提の Python ホイール / TZ データ: musl 起因の互換性問題でハマりやすい