Navigating Docker Debugging Challenges: Overriding ENTRYPOINT

Image from Bern Dittrich from Unsplash

Debugging a Docker container that won’t run can be hard. It’s even harder when an image fails to run in different environments because of missing configurations.

Just recently, I had this problem. My application container wouldn’t run in the production environment. After a long night of debugging, I finally found the problem.

docker run --detach --name app --env-file .env-production docker/image

When I run docker run command to run my Rails application with above command. My Rails application container wouldn’t start because the ENTRYPOINT command, which sets up the initial database, failed. The application couldn’t connect to the PostgreSQL database, so the container stopped at that step.

# Run and own only the runtime files as a non-root user for security
RUN useradd rails --create-home --shell /bin/bash && \
    chown -R rails:rails db log storage tmp
USER rails:rails

# Entrypoint prepares the database.
ENTRYPOINT ["/rails/bin/docker-entrypoint"]

# Start the server by default, this can be overwritten at runtime
EXPOSE 3000
CMD ["./bin/rails", "server"]

One solution could be to rebuild the image, remove the ENTRYPOINT command, and then debug inside the Docker container. But this can take a lot of time, especially when your Docker image size is large.

Then I learned something new. We can change the ENTRYPOINT when we start a Docker container by using the --entrypoint flag.

docker run -it --name app --env-file .env-production --entrypoint bin/bash docker/image

With this command, you can directly dive into the Docker container, bypassing the usual entry point. This opens up a new avenue for debugging and identifying missing configurations, saving valuable time and effort.