第07章:中に入る(exec / shell)“箱の中を覗く”🕵️♂️🐳✨
この章は「困ったら中を見て、落ち着いて状況を把握できる」ようになる回だよ〜!🔦😊 ログ(第6章)で“何が起きたか”を見たら、次は 「じゃあ中はどうなってる?」 を確認しにいく感じ👍
1) 今日のゴール🎯✨
- ✅ 動いてるコンテナに シェルで入れる(
exec)🐚 - ✅ 中で ファイル / 環境変数 / プロセス を確認できる👀
- ✅ 「直すために中でゴリゴリ編集」じゃなくて、原因確認のために覗く感覚がつく🧠✨
2) execって何?(超ざっくり)🧩
-
docker execは “動いてるコンテナの中で別プロセスを追加で実行する” コマンドだよ🔧 つまり「コンテナに入る」は厳密には「コンテナ内でシェルを起動して操作する」ってこと!🧑💻 ※メインのプロセス(PID 1)が動いてる間だけ実行できるよ。(Docker Documentation) -
ついでに重要ポイント👇
docker execは 文字列コマンドをそのまま解釈しない("echo a && echo b"みたいなのはダメ) やるならsh -c "..."みたいに シェル経由 にするのが定番!(Docker Documentation)
3) まずは“入る”!基本の型(これだけ覚えればOK)🧠⚡
3.1 動いてるコンテナを探す🔍
docker ps
NAMES列に コンテナ名 が出るよ(例:todo-apiとか)📛
3.2 シェルで入る(いちばん基本)🐚
最頻出の形:
docker exec -it <コンテナ名またはID> sh
-i:入力できる(インタラクティブ)⌨️-t:それっぽいターミナル(TTY)になる🖥️
「bashで入りたい!」の場合😎
docker exec -it <コンテナ名> bash
ただし!Alpine系(軽いイメージ)だと bash が入ってなくてコケがち💥
その場合は sh を使うのが正解✅(もしくは bash を入れる必要あり)(Stack Overflow)
4) ハンズオン①:中に入って“観察”してみよう🔦👀
ここからは「見る専」でいこう!🕵️♂️✨
Step 1:入る
docker exec -it <コンテナ名> sh
入れたら、プロンプトが変わって「中にいる感」出るよ😆🐳
Step 2:どこにいる?何がある?📁
pwd
ls -la
Step 3:OSとユーザーを確認(地味に超大事)🧾
cat /etc/os-release
whoami
id
「えっ、Alpineだったの!?」みたいな発見あるある😂 (使えるコマンドが少ない理由がここでわかったりする)
Step 4:環境変数(設定の正体)を見る🎚️
env | sort
- 第8章(環境変数)につながる超重要ポイントだよ〜!✨
Step 5:プロセス確認(何が動いてる?)🏃♂️💨
ps aux
- 「Node起動してるはずなのに無い…?」とか
- 「予想外のプロセスが暴れてる…?」とか ここで気付ける👀🔥
Step 6:一旦出る(終了)🚪
exit
5) ハンズオン②:1発コマンドで“中を覗く”👀⚡(入らなくてもOK)
「入るほどじゃないけど、ちょっと見たい」時はこれが便利!
Nodeのバージョン見る例(Todo APIコンテナ想定)🟦
docker exec <コンテナ名> node -v
ファイルの存在チェック(例:package.json)📦
docker exec <コンテナ名> ls -la
docker exec <コンテナ名> test -f package.json && echo "OK" || echo "NO"
複数コマンドやりたい時(sh -c)🧪
docker exec <コンテナ名> sh -c "pwd && ls -la && env | sort | head"
docker exec は「実行ファイル」が必要なので、こういう時はシェルに任せるのが定番だよ🧠(Docker Documentation)
6) Composeを使ってるなら:docker compose exec が最強🥇🧩
Compose環境だと「コンテナ名が毎回違う問題」が出がち😵
そこで サービス名で入れる のが docker compose exec!
docker compose exec api sh
- これは「Composeサービスを対象にした
docker exec相当」って説明が公式にあるよ📘(Docker Documentation) - しかも TTY がデフォルトで割り当てられるので、そのまま対話しやすい👍(Docker Documentation)
7) VS Codeから“中に入る”ルート(ターミナル苦手でも安心)🧑💻🪄
7.1 そのまま“開発環境としてアタッチ”する🧷
VS Code のコマンドパレットで Dev Containers: Attach to Running Container... が使えるよ!(Visual Studio Code) コンテナ内でターミナルも使えるようになるから、体験としてはめちゃ快適😊✨
Alpine だと拡張機能が動かないケースがある(glibc依存など)って注意もあるよ⚠️(Visual Studio Code)
7.2 Docker拡張の“Attach Shell”系(使う人向け)🐳
「Attach Shell が bash で開かない」みたいな時、設定で調整できる例もあるよ🛠️(Zenn)
8) よくある詰まりポイント集🪤😵💫(ここ超あるある)
8.1 Error: No such container / is not running 🧊
docker psに出てない=動いてない → 第4章の stop/rm を思い出しつつ、起動し直そう🔁
8.2 bash: not found 😭
- Alpine系のイメージでありがち
→
shで入るのが正解✅ (Stack Overflow)
8.3 「中に入ったけどコマンドが無い」🫠
- “軽量イメージ”はデバッグ用ツールまで削ってることが多い
→ 最近は
docker debugで軽量コンテナでもデバッグしやすくする仕組みがあるよ🧰(Docker Documentation)
9) 超重要:やりがち事故と“考え方”🧯⚠️
❌ 中で直して終わり(その場しのぎ)
コンテナの中でファイル編集して直しても、消したら終わり💨 基本は「原因確認」して、Dockerfile / compose / 環境変数 / ホスト側のコードで直す方向が安全だよ🛡️
✅ 中でやるのはこれが中心
- 観察:
env,ps,ls,cat👀 - その場の再現:
node -vとかcurlとか(入ってれば)🧪 - “何が起きてるか”を言語化して、次の一手へ🧠✨
10) AI活用(この章は相性めちゃ良い)🤖✨
10.1 “調査コマンドセット”を作ってもらう📌
例プロンプト👇(そのまま投げてOK)
- 「Node/TSのAPIコンテナに入った時、まず確認するコマンド10個を目的付きで出して」
- 「AlpineとDebianで使えるコマンド差分が出やすいので、代替案もセットで」
10.2 “現状報告”を短くまとめてもらう🧾
- 「
envとps auxの結果を貼るから、怪しい点を3つ指摘して」 - 「このコンテナの中身から、想定されるDockerfileの構造を推測して」
11) 最後のチェック(できたら勝ち🏆🎉)
- ✅
docker psで対象を見つけられる - ✅
docker exec -it <name> shで中に入れる - ✅
env / ps / ls / cat /etc/os-releaseを見て状況が説明できる - ✅
bash not foundの意味がわかって、shに切り替えられる - ✅ Composeなら
docker compose exec <service> shを使える(Docker Documentation)
次の第8章(環境変数)に行くと、この章で見た env が一気に“武器”になるよ〜!🎚️🔥