Что будет, если контейнер уже был создан

Docker различает image, созданный container и запущенный container.

docker run --name demo-app demo-app:1.0
docker run --name demo-app demo-app:1.0

Вторая команда завершится конфликтом имени: run пытается создать новый объект. Чтобы запустить остановленный:

docker start demo-app

Чтобы заменить его новым экземпляром:

docker stop demo-app
docker rm demo-app
docker run --name demo-app demo-app:1.1

Удаление контейнера не удаляет named volumes, если их не удалять явно.

Что делает Compose

docker compose up -d сравнивает желаемую конфигурацию сервиса с контейнером проекта:

  • запускает подходящий остановленный контейнер;
  • создаёт отсутствующий;
  • пересоздаёт сервис, если изменилась существенная конфигурация или image;
  • оставляет named volumes подключёнными, пока явно не запросили удаление.

Compose идентифицирует свои объекты labels проекта и сервиса, а не просто совпадением случайного имени. Поэтому заранее созданный вручную контейнер не становится автоматически частью проекта.

Полезные команды:

docker compose ps -a
docker compose config
docker compose up -d --force-recreate app
docker compose down

down -v удаляет volumes проекта и для БД является destructive-операцией.

Типичные сбои

  • Повторять docker run вместо docker start.
  • Пересоздать container и ожидать сохранения данных из writable layer.
  • Изменить environment для БД и ждать повторной инициализации старого volume.
  • Использовать container_name в Compose и получить конфликты между проектами.
  • Выполнить down -v без backup.

Вопросы для собеседования

Что произойдёт при повторном run --name? Docker попытается создать новый container и сообщит о конфликте имени.

Когда нужен start? Когда container уже существует, но остановлен.

Пересоздаёт ли Compose сервис при изменении конфигурации? Да, если конфигурация или image требуют нового container.

Что обычно переживает пересоздание container? Named volume и внешние хранилища; writable layer — нет.

См. Docker, Docker Volume.