Local Startup of Legacy Ruby Site Completed

The old bizneshelper.ru has been successfully launched locally using Docker.

Confirmed Legacy Environment Configuration

• Ruby on Rails 3.2.21.
• The original server used Ruby 2.2.5 via Passenger.
• Ruby 2.2.10 was used for the container as a compatible version of the same branch.
• Bundler 1.15.4.
• MySQL is used as an external, already running service.
• The site is launched in the production environment.

What Was Done

• Prepared a Dockerfile for the old Ruby stack based on Ruby 2.2.10.
• Switched apt sources for Debian Jessie to archive repositories, as the standard repositories for this version are no longer available.
• Installed the necessary system dependencies for building legacy gems and running MySQL/libv8.
• Added the bizneshelper service to docker-compose and connected it to the existing MySQL service via environment variables.
• Configured a separate local port for accessing the application.
• Added support in database.yml for connecting to MySQL via host instead of a local Unix socket.
• Downgraded the ckeditor version to a branch compatible with Rails 3.2.
• Confirmed that the presence of Rails 5-oriented directories app/channels and app/jobs does not block startup under the current production configuration with aggressive class loading disabled.

Discovered Features and Risks

1. Debian Jessie requires the use of archive repositories and special package installation parameters.
2. Some legacy gems are incompatible with modern library versions and require pinning to older versions.
3. The older branch of mysql2 is sensitive to the environment and the method of connecting to MySQL.
4. A newer version of ckeditor uses the Rails 4+ API and therefore must be pinned to a compatible version.
5. The original project contains artifacts from newer Rails versions, indicating historical project changes and requiring caution during automated code migration.

Result

The legacy site can be reproduced and launched locally, and is available as a benchmark for further inventory, behavioral comparison, and migration to haih-cms.

What to Check Next

• Completeness of key pages and forms display.
• Solr search operation.
• Correctness of legacy media loading.
• Admin panel behavior.
• Actual routes, friendly_id, and redirects.
• Compliance of the local database with the original data structure.

Passwords, local absolute paths, and other sensitive environment parameters are not recorded in the public worklog.

Clarification on Docker Run Reproducibility

When restarting the container, a typical legacy Rails issue was discovered: the application writes runtime files directly inside the project tree, which is fully mounted into the container as a bind-mount.

Detected Error

Rails refused to start with the message A server is already running because a server.pid file persisted in tmp/pids/ from the previous run. Upon an unclean shutdown or container recreation, this file remained on the host file system alongside the project.

Cause

The entire site directory is mounted into the container. This creates two effects simultaneously:

1. Content prepared in the image inside the application directory can be overridden by the host's bind-mount content after the container starts. Therefore, dependency installation tied to the state of the mounted project cannot be reliably considered complete solely at the Dockerfile build stage.
2. Rails runtime files (tmp/pids and potentially other temporary data) are saved inside the mounted directory and outlive the container lifecycle. The old PID file then blocks a new start.

Adopted Solution

The service startup command has been supplemented with a preliminary step:

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

The startup logic is now as follows:

• old Rails PID files are deleted before startup;
• bundle check quickly checks for the presence of required gems;
• bundle install --frozen is executed only if dependencies are missing or incomplete;
• after preparation, the Rails server is launched, listening on the container interface.

Architectural Conclusion

The current Docker scheme is oriented toward the most direct reproduction of a legacy project via source code bind-mounts rather than a fully immutable image. For an exploratory migration environment this is acceptable, but it is important to keep in mind that the project state and the runtime container are partially mixed.

With further use of the environment, the tmp, log, uploaded files, and dependencies should be separately controlled so that legacy application temporary files do not affect startup repeatability. If the environment needs to be used for a long time or transferred to other developers, it makes sense to move mutable runtime directories into separate volumes or exclude them from the bind-mount scheme.

Result

After modifying the startup command, the container correctly survives restarts and automatically restores missing dependencies without manual deletion of Rails PID files.