How to Dockerize a Ruby on Rails application

Matvei Tratseuski — Tue, 21 May 2024 14:59:36 +0000

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 if you’re on Mac or Windows, or a Docker Engine 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

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

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:

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

#!/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. 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

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

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:

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

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

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

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, 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.

Forem: Matvei Tratseuski