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.
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:
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
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:
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
stdin_open flags to your docker compose as follows:
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:
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
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 ;)