Plymouth Software Logo

Rails on Docker: Using an Entrypoint File in your Containers

Written by Chris • 28 August 2018

Photo by Franck V. on Unsplash.

When using Docker to run your Rails apps in development, you might come across a leftover file in your app's tmp/ folder.

This file is created when you run rails server to start your app. If your container is not shut down properly, this file is not removed.

This prevents you from starting a new container; as the file is copied into the new container, you will be confronted with the following message when you try to run your app:

web_1    | A server is already running. Check /usr/src/app/tmp/pids/
web_1    | Exiting

Of course, the simple way to resolve this is to remove the offending file ($ rm tmp/pids/ and restart your container.

This can quickly become annoying, though, and won't help if (for example) you are trying to scale the number of containers in your development environment. Every new container will inherit the tmp/pids/ file, and so exit immediately.

Using an Entrypoint File

To properly handle this situation is to use a docker entrypoint file. This is a simple shell script that becomes the command that is called when your container starts.

Entrypoint files are commonly used to set up or configure a container at runtime. For example, when you run the postgres or mariadb containers, their entrypoint files create and configure a default database.

An example entrypoint file for our Rails app to resolve the problem above might be:


rm -f tmp/pids/
bin/rails server -b -p $PORT

Save this file as in your app's folder (in the same location as Dockerfile). You'll also need to make sure it is executable by modifying its permissions:

$ chmod u+x ./

Next, in your app's Dockerfile, set the CMD line to run your new entrypoint file:

# Dockerfile
FROM ruby:2.5
# ...
CMD ./

Note that you could use the _ENTRYPOINT_ command in this instance, but as we're supplying default arguments (_server_, _-b_ and _-p_) to the _bin/rails_ command, I prefer to use _CMD_ in line with the Docker documentation.

Alternatively, if you only want to use your entrypoint file for local development, you could simply override the container's default command in your docker-compose.yml file:

# docker-compose.yml
# ...
  build: .
  command: ./
  # ...

Now you can spin up your container(s) in the normal way using Docker compose:

$ docker-compose up -d --scale web=2

Next Steps

In this simple example, you've seen how to use an entrypoint file to initialise the state of a container at runtime. You can also use entrypoint files to perform much more complicated setup, such as creating runtime files and databases, configuring local services, and more.