Як потрапити всередину запущеного контейнера?

Отримання shell всередині запущеного container це базовий debugging-хід. Команда docker exec, магічні флаги -it, а підступ у тому, що не у кожного image є shell.

#Теорія

#TL;DR

• docker exec -it <name> <cmd> запускає <cmd> як НОВИЙ процес всередині container, не на додачу до PID 1.
• -i тримає stdin відкритим; -t виділяє TTY. Обидва потрібні для інтерактивних shell.
• Більшість Linux base-image мають /bin/sh. Деякі (Ubuntu, Debian) ще й /bin/bash. Distroless і FROM scratch не мають жодного.
• Exec'нутий процес успадковує namespaces container (бачить ту саму filesystem, мережу, процеси), але батько у нього daemon, а не PID 1 застосунку.
• docker exec для запуску у container, що вже running. Щоб отримати shell під час старту container, бери docker run -it <image> sh.

#Швидкий приклад

Комбо -it настільки поширене, що запам'ятовується як один флаг. Без нього: тільки -i = stdin працює, але немає TTY-aware tools (як vi, less); тільки -t = TTY, але не можеш печатати; жодного = shell виходить одразу.

#Як обрати shell

Якщо сумніваєшся, спробуй sh спочатку. Якщо не працює, спробуй bash. Якщо обидва не працюють, image мабуть без shell.

#Поширені флаги, які варто знати

#Типові помилки

Забути -i або -t

Без TTY sh читає з закритого stdin і помирає. Завжди -it для інтерактиву.

Спробувати bash на Alpine

Alpine постачається з busybox sh, не bash. Бери sh.

Спробувати exec у FROM scratch image

Image без shell. Для debug або перебудуй з shell-шаром, або запусти docker run --entrypoint /bin/sh -it <image> (що теж впаде, якщо у image нема shell), або зроби окремий *-debug варіант. Стандартний патерн: distroless :debug теги включають busybox; бери їх лише для debug.

Плутати docker exec з docker attach

docker exec зазвичай те, що тобі треба. attach для кейсів, коли треба бачити stdout/stderr PID 1 live (іноді для інтерактивних REPL як PID 1).

#Реальне застосування

• Debugging проблемного сервісу: docker exec -it web sh і подивитися всередині.
• Запуск міграцій проти DB container: docker exec -it db psql -U postgres -f /tmp/migrate.sql (або docker compose exec).
• Тригер one-off задачі: docker exec api npm run cache:flush.
• Перевірка config всередині running container: docker exec web cat /etc/nginx/nginx.conf.

#Питання для поглиблення

Q: Чому мій exec'нутий shell помирає, коли container рестартує?

A: Рестарт container вбиває усі процеси всередині, включно з твоїм. Exec-сесії не зберігаються через рестарти.

Q: Чи можу exec у зупинений container?

A: Ні. docker exec потребує running container. Для зупиненого можеш docker start -ai <name>, щоб оживити з прикріпленим stdio, або зробити commit у новий image і запустити його з shell як entrypoint.

Q: Яка різниця між docker exec і docker compose exec?

A: docker compose exec <service> це Compose-aware обгортка, знає ім'я сервісу, project-контекст і автоматично підключається до правильного container. Під капотом викликає docker exec. Ті самі флаги працюють.

Q: Як запустити shell як інший користувач?

A: docker exec -u root -it web sh (або будь-який UID/username). Корисно, коли дефолтний USER container non-root, а тобі треба встановити/inspect щось privileged.

Q: (Senior) Коли exec, а коли просто перебудувати image?

A: Exec для діагностики, перевірити файли, env, мережу у живому стані. Rebuild для фіксів, усе, що ти змінюєш через exec, втрачається при наступному рестарті. Спокуса exec-fix-і-вдавати-що-добре це справжній anti-pattern; завжди відображай фікс у Dockerfile або config.

#Приклади

#Прогулятися всередині Postgres container

Exec дає тобі shell; далі це просто звичайна shell-сесія.

#Запуск one-off бекапу без інтерактивного shell

-it не треба, бо немає взаємодії; pg_dump пише у stdout, host shell редиректить у файл.

#Compose: exec у сервіс по імені

Exec у Compose це те, до чого будеш тягнутися щодня під час dev, він знає сервіси твого project без набирання container ID.