How to Dockerize a Ruby on Rails application
Tags: ruby, rails, docker, softwaredevelopment
Published: 2024-05-21 14:59:36

Containerization is a game-changer in software development, delivering key advantages like streamlined deployment, scalability, and consistency across development, testing, and production environments.

In this post, I’m going to walk you through a configuration for dockerizing your Ruby on Rails app and dive into each detail so you know exactly how it works.

## Install Docker

Install [Docker Desktop](https://www.docker.com/products/docker-desktop/) if you’re on Mac or Windows, or a [Docker Engine](https://docs.docker.com/engine/install/) if you’re using Linux.

## Project Structure

Here’s the structure of the project that will be dockerized:

```
your-project-name/
│
├── backend (rails backend)
│   ├── Gemfile
│   ├── Gemfile.lock
│   └── ... (other rails files)

├── frontend (frontend folder)
│   ├── package.json
│   └── ... (other frontend files)
│
├── bin (place for script)
│   ├── run (script that run docker)
│   └── ... (other scripts)
│
├── docker
│   ├── development
│   ├──├── frontend.Dockerfile
│   └──└── backend.Dockerfile
│
└── docker-compose.yml
```

## Proposed Configuration
Most folks just want to copy the config and hit the ground running. Below, I’ve shared my configuration and broken it down for you.

Tech stack for this sample project:

- Ruby 3.3.0
- Svelte 4 (you can use any other)
- Postgres 14

### backend.Dockerfile

```docker
FROM ruby:3.3.0-bookworm

RUN set -eux; \
    apt-get update; \
    apt-get -y upgrade

ARG UID=1000

RUN set -eux; \
    useradd -s /bin/bash -u ${UID} -m backend; \
    mkdir -p /backend/vendor/bundle; \
    chown -R backend:backend /backend

USER backend

WORKDIR /backend

ENV BUNDLE_PATH=vendor/bundle
ENV BUNDLE_APP_CONFIG=$BUNDLE_PATH
ENV BUNDLE_USER_CACHE=vendor/bundle/cache

# This will force using gems with native extensions instead
# of pre-compiled versions.
# Using precompiled versions leads to compatibility issues
# in the case of ARM platform.
RUN bundle config set force_ruby_platform true
```

### docker-compose.yml

```Yaml
version: "3.9"

services:
  backend: &backend
    build:
      context: .
      dockerfile: docker/development/backend.Dockerfile
    volumes:
      - ./backend:/backend:cached
      - backend_tmp:/backend/tmp
      - bundle:/backend/vendor
    command: bin/rails s -b 0.0.0.0
    ports:
      - "3000:3000"
    tty: true
    stdin_open: true
    depends_on:
      - db

  db:
    image: postgres:14
    volumes:
      - db_data:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: password

  frontend:
    build:
      context: .
      dockerfile: docker/development/frontend.Dockerfile
    volumes:
      - ./frontend:/frontend:cached
      - node_modules:/frontend/node_modules
    command: yarn dev --port 3001 --host 0.0.0.0
    ports:
      - "3001:3001"

volumes:
  bundle:
  db_data:
  node_modules:
  backend_tmp:
    driver_opts:
      type: tmpfs
      device: tmpfs
      o: uid=1000,gid=1000
```

Change default in `backend/config/database.yml` to:

```Yaml
default: &default
  adapter: postgresql
  encoding: unicode
  host: <%= ENV.fetch("DB_HOST", "db") %>
  username: postgres
  password: <%= ENV.fetch("DB_PASSWORD", "password") %>
```
To get everything up and running, you need to build images (or pull), install gem, prepare db, and install packages for the frontend. You can find all of these scripts in this repository. 

For simplicity, I combined all scripts into one `bin/setup` file.

### bin/setup

```Bash
#!/bin/bash

#exit immediately if any command within the script or session 
#exits with a non-zero status

set -e 

docker compose build

docker compose run --rm backend /bin/bash -c 'bundle install'
docker compose run --rm backend /bin/bash -c 'bundle exec rails db:prepare'
docker compose run --rm backend /bin/bash -c 'bundle exec rails db:seed'
#change yarn to your package manager
docker compose run --rm frontend /bin/bash -c 'yarn install'

```
Give permission to run scripts from the bin folder using `chmod +x -R ./bin/` from the project root folder. Then run this script `bin/setup`.

Congratulations! Now you can run docker using `docker compose up`.

## Configuration Explained
Now let’s talk more about the specific configuration of the **backend.Dockerfile**.

### Bookworm
`FROM ruby:3.3.0-bookworm`, why bookworm, and what is it? 

Bookworm is the name of the [Debian version](https://www.debian.org/releases/). Most of the time, we don’t care about the size of the docker image, so I recommend picking the latest Debian version. 

Also, I recommend always explicitly specifying the version of an image - never pick the _latest_ as it can upgrade and break the application.

###  Update and upgrade software packages 

```Docker
RUN set -eux; \
    apt-get update; \
    apt-get -y upgrade
```

These commands update and upgrade the software packages within a Docker container, ensuring they are up-to-date and secure. The script exits on errors and automatically confirms all prompts for a smooth, non-interactive process.

### Set Up Application User and Directory Structure

```Docker
ARG UID=1000
RUN set -eux; \
    useradd -s /bin/bash -u ${UID} -m backend; \
    mkdir -p /backend/vendor/bundle; \
    chown -R backend:backend /backend
```

It creates a new user named backend with a specified user ID, sets up a directory for the application, and assigns ownership of this directory to the new user. Then it creates a directory for Ruby dependencies and sets the application user as its owner for secure and organized access.

**frontend.Dockerfile** has almost the same configuration.

### Volumes for the backend service
The main thing to understand in **docker-compose.yml** is how volumes are mounted.
Volumes for the backend service:

```YAML
volumes:
      - ./backend:/backend:cached
      - backend_tmp:/backend/tmp
      - bundle:/backend/vendor
```

#### Bind Mount from Local Directory 
`./backend:/backend:cached`
This volume mounts the backend directory on the host machine to _/backend_ inside the container. With _:cached_  for optimized I/O performance.

#### Named Volumes
`backend_tmp:/backend/tmp`
A named volume _backend_tmp_ is mounted to _/backend/tmp_ inside the container, managed by Docker for data persistence.

`bundle:/backend/vendor`
This bundle is another named volume mounted to _/backend/vendor_, ensuring the persistence of Ruby dependencies (gems) across container restarts.

### Volumes for the db service

```YAML
volumes:
      - db_data:/var/lib/postgresql/data
```

`db_data:/var/lib/postgresql/data`
This volume is used to store the Postgres database within _db_data_, ensuring that data remains persistent across container restarts.

### Volumes for the frontend service

```YAML
volumes:
      - ./frontend:/frontend:cached
      - node_modules:/frontend/node_modules
```

`./frontend:/frontend:cached`
The local frontend directory is mounted to _/frontend_ inside the container, with _:cached_ for optimized I/O performance.

`node_modules:/frontend/node_modules`
Ensures persistent storage of Node.js dependencies in _node_modules_, avoiding loss on container rebuild.

### Volume Definitions

```YAML
volumes:
  bundle:
  db_data:
  node_modules:
  backend_tmp:
    driver_opts:
      type: tmpfs
      device: tmpfs
      o: uid=1000,gid=1000
```
`bundle, db_data, node_modules`
These are simply declared, allowing Docker to manage them for persistence.

`backend_tmp`
Specified with _driver_opts_ to configure as _tmpfs_, meaning it's stored in memory, not persisted on the host disk, with _uid=1000, gid=1000_ for file ownership. Ideal for temporary data not requiring persistence across restarts.

## Debugging
If you take scripts from [this repository](https://github.com/Set27/dockerize_rails_example), you can smoothly debug a rails application by running this script `bin/run_and_attach`. This allows you to debug inside the same terminal.

## Conclusion
By dockerizing your Rails app, you're setting yourself up for success with an application that's portable and easy to deploy.

Whether you are hosting it on a server, using a PaaS like Heroku, or orchestrating it with Kubernetes, Docker lays a solid foundation.
Well done on dockerizing your Rails app! Here's to smooth sailing in your app development and deployment!

> Originally published on the [datarockets' blog](https://datarockets.com/blog/code/dockerize-ruby-on-rails-application/).