Nativifying a docker development environment

I’ve written 4 posts in this blog where I explain how to use docker in the local development environment. Most of our projects are dockerized from scratch as it’s one of the easiest ways to onboard a developer onto a project, and the easiest way to come back to a project after some time passed. How I use docker and docker-compose hasn’t changed much since, except for a couple of improvements in handling volumes. What did change a long time ago, which I didn’t cover in this blog, is that I barely use docker compose run for running commands in containers most of the time.

Instead, I have proxy commands (local commands in my $PATH) that execute docker compose run for me. There’s only one reason for this: in my local computer almost everything is dockerized and I don’t like typing docker compose run every time I want to run a rails command.

So, what does one of these proxy commands look like? Let’s take a look at the rails command:

#!/bin/bash

docker compose run --rm web rails "$@"

The script just executes docker-compose run (a one-off command) on the web service. In this case, it’s rails, and sends $@ as an argument to rails, meaning everything you send to your rails command will be sent to the rails command within the container. This allows you to execute any rails subcommand, such as rails c, rails db:migrate, etc.

As you can see there is a caveat for this to work: all projects where you use the rails command must have a docker-compose.yml file and that docker-compose.yml file must have a web service where the rails command exists (ie. where the app lives). Here’s where Convention over configuration comes in handy.

These commands have proven to be extremely useful to me, and as you can imagine I have lots of them in my $PATH besides rails: bundle, rake, ruby, npm, yarn, standardrb. You name it.

So far I never experienced the lack of tools by working entirely on docker. With this little trick, I can even run certain VS Code extensions that are extremely useful in my day-to-day work, such as Standard Ruby and StandardJS.

If you haven’t already, I emphatically recommend you try this out!