Worklog for task "Locally Deploy the Original Ruby Website"

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.