Ворклог по задаче "Локально развернуть исходный Ruby-сайт"

Уточнение по воспроизводимости Docker-запуска

При перезапуске контейнера обнаружена типичная для legacy Rails проблема: приложение пишет runtime-файлы непосредственно внутрь дерева проекта, которое целиком подключено в контейнер как bind-mount.

Обнаруженная ошибка

Rails отказывался стартовать с сообщением A server is already running, потому что после предыдущего запуска в tmp/pids/ сохранялся server.pid. При аварийной остановке или пересоздании контейнера этот файл оставался на хостовой файловой системе вместе с проектом.

Причина

В контейнер монтируется весь каталог сайта. Это создаёт сразу два эффекта:

1. Содержимое, подготовленное в образе внутри каталога приложения, может быть перекрыто bind-mount содержимым хоста после старта контейнера. Поэтому установку зависимостей, завязанную на состояние смонтированного проекта, нельзя надёжно считать завершённой только на этапе сборки Dockerfile.
2. Runtime-файлы Rails (tmp/pids и потенциально другие временные данные) сохраняются внутри смонтированного каталога и переживают жизненный цикл контейнера. Старый PID-файл затем блокирует новый запуск.

Принятое решение

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

rm -rf /app/tmp/pids/ && (bundle check || bundle install --frozen) && bundle exec rails server -b 0.0.0.0

Логика запуска теперь такая:

• перед стартом удаляются старые PID-файлы Rails;
• bundle check быстро проверяет наличие нужных гемов;
• bundle install --frozen выполняется только если зависимости отсутствуют или неполны;
• после подготовки запускается Rails-сервер, слушающий интерфейс контейнера.

Архитектурный вывод

Текущая Docker-схема ориентирована на максимально прямое воспроизведение legacy-проекта через bind-mount исходников, а не на полностью immutable-образ. Для исследовательской миграционной среды это допустимо, но важно учитывать, что состояние проекта и runtime-контейнера частично смешиваются.

При дальнейшем использовании окружения стоит отдельно контролировать каталоги tmp, log, загружаемые файлы и зависимости, чтобы временные файлы legacy-приложения не влияли на повторяемость запуска. Если окружение потребуется использовать длительно или передавать другим разработчикам, имеет смысл вынести изменяемые runtime-каталоги в отдельные volumes либо исключить их из bind-mount схемы.

Результат

После изменения команды запуска контейнер корректно переживает повторные старты и сам восстанавливает недостающие зависимости без ручного удаления Rails PID-файлов.