Локальный запуск legacy Ruby-сайта выполнен

Старый bizneshelper.ru успешно запущен локально в Docker.

Подтверждённая конфигурация legacy-среды

• Ruby on Rails 3.2.21.
• На исходном сервере использовался Ruby 2.2.5 через Passenger.
• Для контейнера использован Ruby 2.2.10 как совместимая версия той же ветки.
• Bundler 1.15.4.
• MySQL используется как внешняя уже поднятая служба.
• Сайт запускается в production-окружении.

Что было сделано

• Подготовлен Dockerfile для старого Ruby-стека на базе Ruby 2.2.10.
• Для Debian Jessie переключены apt-источники на архивные репозитории, так как штатные репозитории этой версии больше недоступны.
• Установлены необходимые системные зависимости для сборки legacy-гемов и работы MySQL/libv8.
• Сервис bizneshelper добавлен в docker-compose и подключён к существующей MySQL-службе через переменные окружения.
• Настроен отдельный локальный порт для доступа к приложению.
• В database.yml добавлена поддержка подключения к MySQL по host вместо локального Unix socket.
• Версия ckeditor понижена до совместимой с Rails 3.2 ветки.
• Подтверждено, что наличие Rails 5-ориентированных каталогов app/channels и app/jobs не блокирует запуск при текущей production-конфигурации с отключённой агрессивной загрузкой классов.

Обнаруженные особенности и риски

1. Debian Jessie требует использования архивных репозиториев и специальных параметров установки пакетов.
2. Часть legacy-гемов несовместима с современными версиями библиотек и требует фиксации старых версий.
3. mysql2 старой ветки чувствителен к окружению и способу подключения к MySQL.
4. ckeditor в более новой версии использует API Rails 4+ и поэтому должен быть зафиксирован на совместимой версии.
5. В исходном проекте присутствуют артефакты более новых Rails-версий, что указывает на исторические изменения проекта и требует осторожности при автоматической миграции кода.

Результат

Legacy-сайт воспроизводимо запускается локально и доступен как эталон для дальнейшей инвентаризации, сравнения поведения и миграции на haih-cms.

Что проверить далее

• Полноту отображения ключевых страниц и форм.
• Работу поиска с Solr.
• Корректность загрузки legacy-медиа.
• Поведение админки.
• Фактические маршруты, friendly_id и редиректы.
• Соответствие локальной базы исходной структуре данных.

В открытом worklog не фиксируются пароли, локальные абсолютные пути и иные чувствительные параметры среды.

Уточнение по воспроизводимости 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-файлов.