#Как проявляется проблема и где искать причину
После docker build контейнер не обязан автоматически перейти на новый образ. Он может продолжать использовать старый image ID, если не пересоздавался, если сборка шла в другом проекте или тег остался прежним.
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Контейнер не пересозданСборка создала новый образ, но старый контейнер всё ещё работает | container inspect показывает прежний идентификатор | Планово пересоздать тестовый сервис |
| Разные каталоги/проектыdocker compose запущен не с тем файлом или профилем | compose config отличается от ожидаемого | Уточнить проект и тег образа |
#Пошаговая диагностика и устранение
- 1. Определите точный проектОткройте каталог с compose.yaml и убедитесь, что это нужный проект. Выполните docker compose config --services и сравните имена со списком приложения.Linux · Терминал (Bash)КомандаКаталог проекта; только чтение.
docker compose config --services
- 2. Узнайте, какой образ запущен сейчасПроверьте Image ID работающего контейнера через inspect и сохраните его для сравнения. Имя/тег не всегда означает, что контейнер обновился.
- Первое значение — фактический ID образа, второе — его ссылка при созданииLinux · Терминал (Bash)КомандаПервое значение — фактический ID образа, второе — его ссылка при создании.
docker inspect --format "{{.Image}} {{.Config.Image}}" ИМЯ_КОНТЕЙНЕРА
- 3. Посмотрите локальные образыВыведите список образов с тегами и датами. Если последние изменения исходного кода не попали в образ, проверьте Dockerfile, контекст сборки и .dockerignore.
- Чтение; наличие нужного тега не доказывает актуальность кодаLinux · Терминал (Bash)КомандаЧтение; наличие нужного тега не доказывает актуальность кода.
docker image ls --digests
- 4. Проверьте контекст и COPYОткройте Compose-конфигурацию и Dockerfile. Убедитесь, что build.context указывает на ожидаемый каталог, изменённые файлы не исключены через .dockerignore, а COPY действительно забирает их внутрь образа.
- 5. Соберите отдельный тестовый образВ тестовой копии проекта выполните docker compose build ИМЯ_СЕРВИСА; при подозрении на неверно использованный кэш сначала оцените, какой шаг собирает программу, и лишь затем используйте --no-cache.Linux · Терминал (Bash)С осторожностьюИсполняет Dockerfile и может скачивать внешние зависимости; только доверенный проект.
docker compose build ИМЯ_СЕРВИСАКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
- 6. Пересоздайте тестовый сервисКогда данные и тома защищены, примените новый образ именно к тестовому сервису. Простое docker restart использует старый образ, поэтому требуется пересоздание контейнера.Linux · Терминал (Bash)С осторожностьюМожет временно остановить сервис; --no-deps не запускает зависимости.
docker compose up -d --no-deps --force-recreate ИМЯ_СЕРВИСАКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
- 7. Сверьте ID и функциональностьПовторите docker inspect и проверьте версию программы через страницу «О программе», HTTP-ответ или её собственную команду. Если ID изменился, но код старый, причина в сборке/кэше приложения, а не в запуске контейнера.
#Как проверить результат
Фактический Image ID контейнера соответствует новому образу; приложение на тесте показывает обновлённую версию и проходит проверочный сценарий.
#Если исправление не помогло
Если приложение использует внешние файлы через bind mount, старый код может приходить из каталога хоста. Сравните Mounts в docker inspect.