Docker tips for Ruby on Rails apps

“How to run a rails console” and other common questions

After spending another day of work in one of our projects trying to fix local dependency issues, we’ve decided to finally move our Ruby on Rails app over to Docker. The process was almost no-brainer but we needed to fill gaps between our previous workflow and the new one. Following article presents docker ways of performing most common tasks when working on Ruby on Rails application.

Application setup

We’ve followed instructions from https://semaphoreci.com/community/tutorials/dockerizing-a-ruby-on-rails-application for Docker setup and ended up with following docker-compose.yml file:

docker-compose.yml

It has one subtle difference- DB_* environment variables are defined inside docker-compose.yml instead of .env file as .env file is not added to our git repository.

Things to consider:

1. Move docker-related environment variables to docker-compose

2. Add other environment variables to .env file that is not tracked in version control system

3. Make sure you preserve postgres data by adding “postgres-volume”. This will prevent data loss when removing containers

4. Make sure you use “.dockerignore” file to exclude /tmp, /.git, /log folders

How to run rails console

Running rails console is something that we do quite often when we want to debug an issue on live server, but at the same time we don’t want to modify code by adding debugger instructions.

We can do it now with following command:

docker-compose run web rails console

The following task will spin up new docker container with rails console as its command instead of default rails s

How to run migrations

Whenever we work on local machine we always run our migrations as one time jobs with following command:

docker-compose run web rake db:migrate

For production applications we’re using entrypoint to ensure that migrations are always run on container start:

docker-entrypoint.sh

Just remember to add docker-entrypoint.sh as an ENTRYPOINT instruction.

How to work with debugger

When you want to work with debugger you need to make sure it will allow communication with your container via console. It can be achieved by adding tty and stdin_open flags to your docker compose as follows:

docker-compose.yml with debugger options

When you stop on a breakpoint, you won’t be able to type in anything in docker-compose by design. All you have to do is to attach to running container. First we need to find container id:

docker ps

This command will print all running containers. You just need to find a container id corresponding to your web application. Having that id you can attach and start debugging:

docker attach CONTAINER_ID

How to lint my files

If you already have all your linters installed as gems from within Gemfile, running them is easy as piece of cake. You can use the same pattern as in previous instructions, for example to run rubocop:

docker-compose run web rubocop

If you want not to run container every single time, but use instead one running instance you can use following command and run linter commands from there:

docker-compose exec web bash
root@216d180c59fa:/app# rubocop

We’re currently working on dockerized linter environment and plugins for popular text editors so this step will be a lot easier… please stay tuned.

If you enjoyed this story please hit 👏 button so others find this article too. You may also be interested in the way we’ve saved our pull requests

We can also be friends on Twitter ;)