Here’s something that should be Docker 101, but for some reason people don’t really tell you: there’s no such thing as just “Dockerizing” a Rails app. There are two use cases for using Docker with Rails. Before you go down the path of Dockerizing your app, you have to pick which use case you’re after. The implementation for each is very different from the other.
You can Dockerize an app for development or you can Dockerize it for production.
Dockerizing for development
The reason you would want to Dockerize an app for development is to make it easier for a new developer to get a development environment set up on their machine.
When you have your app Dockerized for development, Docker can install and run services for you. For example, if your app uses PostgreSQL, Redis, webpack-dev-server, and Sidekiq, Docker will run all those processes for you, and before that Docker will install PostgreSQL and Redis if you don’t already have them.
This means that each new developer who starts the project doesn’t have to go through a potentially long and painful process of installing all the dependencies for your app before getting to work. They can just clone the repo, run a single command, and be up and running.
Dockerizing for production
The benefits of Dockerizing for production overlap with Dockerizing for development, but they’re not exactly the same.
In my development example I mentioned that you might have certain services running locally like PostgreSQL, Redis, webpack-dev-server, and Sidekiq. In a production environment, you of course don’t have all these processes running on a single machine or VM. Rather, you might have (if you’re using AWS for example), your database hosted on RDS, a Redis instance on ElasticCache, Sidekiq running on a worker EC2 instance, and no webpack-dev-server because that doesn’t apply in production. So the need is very different.
So unlike a development use case, a production Docker use case doesn’t include installing and running various services for you, because running all kinds of services on a host machine is not how a “modern” production infrastructure configuration works.
I’ve never Dockerized a Rails app for production, so if I tried to describe the benefits of Dockerizing for production, I’d mostly be talking out of my ass. Here’s a link to what I think is a pretty good explanation.
I will say that I’ve evaluated Docker as a potential part of my production infrastructure and I’ve decided against it (for now at least). The problems that Docker in production solves aren’t really problems that I have. The app I work on at work doesn’t serve that many users. I don’t have crazy scaling or performance needs. I’ve gotten by just fine so far using Ansible for orchestration.
The other reason I’ve chosen not to use Docker in production is that there’s so little overlap between what it takes to get a development Docker config working and what it takes to get a Dockerized production infrastructure working. For production, getting the app itself Dockerized seems to be just the first step. After that you have to choose a cloud solution (ECS, Fargate, Google Cloud Run, etc.) and figure out how to get your container plugged into the cloud service, which in my experience is highly non-trivial. Unless there’s a really compelling use case, all that work seems like a waste of time.
- There are two ways to Dockerize a Rails app: for development and for production.
- Dockerizing for development makes it easier to spin up a development environment.
- Dockerizing for production helps avoid the problem of having snowflake servers.
- Dockerizing for development could probably benefit just about any team, but Dockerizing for production is probably much more dependent on your app’s unique hosting needs.