Почему «docker compose restart» не выкладывает новый код — и как это обнаружить

Ситуация, в которой легко оказаться при любом проекте на Docker: вы правите файлы на сервере, перезапускаете сервис, в логах нет ошибок — и считаете, что обновление выехало. А на самом деле контейнер продолжает работать на старой версии. Со мной это случилось на проекте автопостинга: я «выложил» три функции подряд и узнал, что ни одна из них не работает, только когда добавлял четвёртую.

В чём причина

Если исходный код копируется в образ на этапе сборки (COPY . . в Dockerfile), а при запуске в контейнер подключены только тома с данными, то изменения файлов на хосте контейнер не видит. Команда docker compose restart лишь останавливает и запускает тот же самый контейнер из того же самого образа. Новые файлы в него не попадают.

Как я это понял

Подсказкой стали миграции базы данных. Новая доработка добавляла миграцию, а внутри контейнера команда alembic current показывала прежнюю версию схемы. Вывод был один: код внутри образа старше кода на диске. Именно поэтому полезно проверять не «ответил ли сервис», а конкретное доказательство новой версии — номер миграции, хэш коммита, строку версии.

Как выкладывать правильно

Последовательность для сервисов, собранных в образ, такая: сначала docker compose build <сервисы>, затем docker compose up -d <сервисы>, который пересоздаёт контейнеры уже из нового образа. Если в обновлении есть миграция, убедитесь, что она применилась, а не предполагайте это. Перед выкладкой имеет смысл проверить, что в сервисе не идёт долгая задача: пересоздание контейнера прервёт её на середине.

Что закрепить в процессе

Выкладку лучше оформить скриптом или CI-пайплайном, чтобы человек не вспоминал порядок команд на ходу. В конце скрипта пусть стоит проверка версии — иначе сообщение «деплой успешен» ничего не гарантирует. Именно такие мелочи отличают поддерживаемый веб-сервис от проекта, в котором каждое обновление — повод для тревоги.