Этап 4 - Работа с контейнерами

Container проще отлаживать, если воспринимать его как process с lifecycle. Он создается, запускается, останавливается, проверяется и в конце удаляется.

Lifecycle, а не просто commands

docker run скрывает несколько шагов. Docker создает container object, готовит writable layer, подключает networks, присоединяет mounts и запускает настроенный process. Если главный process завершается, container останавливается.

1. created
2. running
3. paused or stopped
4. restarted
5. removed

Поверхности debugging

Logs — первая поверхность debugging. Docker собирает stdout и stderr, поэтому application должна писать полезные logs туда. docker exec — вторая поверхность: он позволяет увидеть files, DNS, environment variables и tools изнутри running container.

Limits и restart behavior

Resource limits превращают Docker из удобного инструмента в operational tool. Memory limits не дают одному container съесть host. CPU limits управляют scheduling. Restart policies решают, что делать после crash или restart host.

Правило main process

Container живет столько, сколько живет его main process. Если этот process успешно завершается, container останавливается. Если он падает, container останавливается, если restart policy не говорит Docker запустить его снова. Это отличается от virtual machine, где много background services могут жить независимо.

Это правило объясняет частое удивление новичков: команда вроде docker run ubuntu может завершиться сразу. Image валиден, но внутри нет long-running main process. Если нужен interactive shell, его нужно запустить явно через -it и shell command.

Для applications это значит, что startup command критична. Container должен запускать реальный foreground process, а не стартовать background daemon и сразу завершаться.

Inspect перед изменениями

Когда что-то падает, сначала соберите evidence, а не меняйте command. docker ps -a показывает, существует ли container и какой у него exit status. docker logs дает application output. docker inspect показывает configuration, которую Docker реально применил.

Только после этого стоит использовать docker exec, и только если container еще running. Exec отлично подходит для проверки files, environment variables, DNS resolution или installed tools. Но это плохой способ вручную исправлять production state, потому что такие изменения исчезнут при пересоздании container.

Что появляется после запуска container

После docker run container object существует на том Docker host, где была выполнена command. Если вы запустили command на ноутбуке, container находится на ноутбуке. Если вы подключились по SSH на VPS и запустили command там, container находится на VPS.

Это важно для debugging. docker ps показывает только containers того Docker host, к которому подключен ваш CLI. Если container работает на server, локальный docker ps его не покажет, если CLI не настроен на remote host.

Files, записанные внутри container, не становятся автоматически files в project directory. Они живут в container writable layer, если вы не подключили volume или bind mount. Logs Docker собирает из output process внутри container.

Команды: запустить и проверить

Выполняйте эти commands в terminal той машины, где установлен Docker. Для локального обучения это terminal на вашем ноутбуке. Для VPS сначала подключитесь к server по SSH, затем запускайте commands там. Не вставляйте commands вслепую: запустите одну command, посмотрите, что изменилось, затем переходите к следующей.

docker run -d --name web -p 8080:80 nginx:1.27
docker logs web
docker exec -it web sh
docker inspect web
docker stop web && docker rm web

Таблица для ориентира

Порядок debugging

Когда container ведет себя неправильно, не пересобирайте image сразу. Сначала проверьте, running ли container, затем прочитайте logs, затем inspect configuration, и только потом заходите внутрь container, если нужен его internal viewpoint.

Такой порядок защищает от случайных fixes. Он разделяет application failure, wrong runtime configuration, missing files, network mistakes и resource problems.

Контрольная точка

Вы готовы к следующей теме, когда logs, exec и inspect ощущаются как три разных tools, а не как взаимозаменяемые debugging commands.

Практика: lifecycle container

Запустите container в detached mode, остановите его и сравните docker ps с docker ps -a. Затем удалите его и сравните снова. Смысл в том, чтобы увидеть: “not running” и “not existing” — разные состояния. Многие новички теряют время, потому что пытаются читать logs у удаленного container или удалить container, который всего лишь stopped.

Короткий вывод

Главный ориентир: container — это object вокруг process. Process может остановиться, но object еще остается; object можно удалить, но volume может сохраниться. Эти различия важны при каждом debugging session.