[1]
[2]Hire Martians
[3]
Services
[4]
Clients
[5]
Products
[6]
Open Source
[7]
Blog
[8]
Events
[9]
Podcast
[10]
[11]
[12]
[13]
[14]
[15]Hire Martians
[16]
Services
[17]
Clients
[18]
Products
[19]
Open Source
[20]
Blog
[21]
Events
[22]
Podcast
[23]
[24]
[25]
[26]
[27]
7-
Oct
8
Meet us at Rocky Mountain Ruby in Boulder, Colorado!
[28]Hire Martians
[29]
[30]
[31]
[32]

Ruby on Whales: Dockerizing Ruby and Rails development

March 15, 2022
[svg]
Cover for Ruby on Whales: Dockerizing Ruby and Rails developmentCover for Ruby
on Whales: Dockerizing Ruby and Rails development

Topics

  • [33]Backend
  • [34]Full Cycle Software Development
  • [35]Performance Optimization
  • [36]Ruby on Rails
  • [37]Ruby
  • [38]Docker
  • [39]PostgreSQL
  • [40]Node.js

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  • [svg]
    Vladimir Dementyev

    Vladimir Dementyev

    Principal Backend Engineer

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Translations

  • Japanese[41]クジラに乗ったRuby: Evil Martians流Docker+Ruby/Rails開発環境構
    築
  • Chinese[42]骑鲸之路——Docker模式下的Rails开发环境构筑

This post introduces the Docker configuration I use for developing my Ruby on
Rails projects. This configuration came out of—and then further evolved—during
[DEL:production:DEL] development at Evil Martians. Read on to learn all the
details, and feel free to use it, share it, and enjoy!

Notice: This article is regularly updated with the best and latest
recommendations; for details, take a look at the [43]Changelog.

So, where to start? This has been a pretty long journey: back in the day, I
used to develop using Vagrant, but its VMs were a bit too heavy for my 4GB RAM
laptop. In 2017, I decided to make the switch to containers, and this was how I
first began using Docker. But don’t get the impression that this was an instant
fix! I was in search of a configuration that was perfect for myself, my team,
and well, everyone else. And something which was just good enough would not cut
it. It took quite some time to develop a standard approach (as more formerly
enshrined with the first release of this article in 2019). Since that first
iteration of this post revealed my secret to the world, many Rails teams and
devs have adopted my technique, and actually, they’ve helped to contribute and
improve it!

With that out of the way, let me just go ahead and present the config itself.
Along the way, I’ll explain almost every line (because we’ve all had enough of
those cryptic tutorials that just assume you know stuff).

This post was originally adapted from my talk at RailsConf 2019: [44]
“Terraforming legacy Rails applications”.

    The source code can be found in the [45]evilmartians/ruby-on-whales
    repository on GitHub.

Before we get on with it, let’s note that we’ll be using up-to-date software
versions for this example: Docker Desktop 20.10+ and Docker Compose v2,
Ruby 3.1.0, PostgreSQL 14, etc.

The bulk of the post consists mostly of annotated code and configuration
examples, structured as follows:

  • [46]The basics: Dockerfile and docker-compose.yml
  • [47]Introducing Dip
  • [48](Micro-)services vs Docker for development
  • [49]From development to production
  • [50]Introducing the Ruby on Whales interactive generator

Basic Docker configuration

[51]Dockerfile

The Dockerfile defines our Ruby application’s environment. This environment is
where we’ll run servers, access the console (rails c), perform tests, do Rake
tasks, and otherwise interact with our code in any way as developers:

# syntax=docker/dockerfile:1

ARG RUBY_VERSION
ARG DISTRO_NAME=bullseye

FROM ruby:$RUBY_VERSION-slim-$DISTRO_NAME

ARG DISTRO_NAME

# Common dependencies
RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
  --mount=type=cache,target=/var/lib/apt,sharing=locked \
  --mount=type=tmpfs,target=/var/log \
  rm -f /etc/apt/apt.conf.d/docker-clean; \
  echo 'Binary::apt::APT::Keep-Downloaded-Packages "true";' > /etc/apt/apt.conf.d/keep-cache; \
  apt-get update -qq \
  && DEBIAN_FRONTEND=noninteractive apt-get install -yq --no-install-recommends \
    build-essential \
    gnupg2 \
    curl \
    less \
    git

# Install PostgreSQL dependencies
ARG PG_MAJOR
RUN curl -sSL https://www.postgresql.org/media/keys/ACCC4CF8.asc | \
    gpg --dearmor -o /usr/share/keyrings/postgres-archive-keyring.gpg \
    && echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/postgres-archive-keyring.gpg] https://apt.postgresql.org/pub/repos/apt/" \
    $DISTRO_NAME-pgdg main $PG_MAJOR | tee /etc/apt/sources.list.d/postgres.list > /dev/null
RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
  --mount=type=cache,target=/var/lib/apt,sharing=locked \
  --mount=type=tmpfs,target=/var/log \
  apt-get update -qq && DEBIAN_FRONTEND=noninteractive apt-get -yq dist-upgrade && \
  DEBIAN_FRONTEND=noninteractive apt-get install -yq --no-install-recommends \
    libpq-dev \
    postgresql-client-$PG_MAJOR

# Install NodeJS and Yarn
ARG NODE_MAJOR
ARG YARN_VERSION=latest
RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
    --mount=type=cache,target=/var/lib/apt,sharing=locked \
    --mount=type=tmpfs,target=/var/log \
    apt-get update && \
    apt-get install -y curl software-properties-common && \
    curl -fsSL https://deb.nodesource.com/gpgkey/nodesource.gpg.key | apt-key add - && \
    echo "deb https://deb.nodesource.com/node_${NODE_MAJOR}.x $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/nodesource.list && \
    apt-get update && \
    DEBIAN_FRONTEND=noninteractive apt-get install -yq --no-install-recommends nodejs
RUN npm install -g yarn@$YARN_VERSION

# Application dependencies
# We use an external Aptfile for this, stay tuned
COPY Aptfile /tmp/Aptfile
RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
  --mount=type=cache,target=/var/lib/apt,sharing=locked \
  --mount=type=tmpfs,target=/var/log \
  apt-get update -qq && DEBIAN_FRONTEND=noninteractive apt-get -yq dist-upgrade && \
  DEBIAN_FRONTEND=noninteractive apt-get install -yq --no-install-recommends \
    $(grep -Ev '^\s*#' /tmp/Aptfile | xargs)

# Configure bundler
ENV LANG=C.UTF-8 \
  BUNDLE_JOBS=4 \
  BUNDLE_RETRY=3

# Store Bundler settings in the project's root
ENV BUNDLE_APP_CONFIG=.bundle

# Uncomment this line if you want to run binstubs without prefixing with `bin/` or `bundle exec`
# ENV PATH /app/bin:$PATH

# Upgrade RubyGems and install the latest Bundler version
RUN gem update --system && \
    gem install bundler

# Create a directory for the app code
RUN mkdir -p /app
WORKDIR /app

# Document that we're going to expose port 3000
EXPOSE 3000
# Use Bash as the default command
CMD ["/bin/bash"]

This configuration only contains the essentials, and so it can be used as a
starting point. Let me illustrate what we’re are doing here a bit further. The
first three lines might look a bit strange:

ARG RUBY_VERSION
ARG DISTRO_NAME=bullseye
FROM ruby:$RUBY_VERSION-slim-$DISTRO_NAME

Why not just use FROM ruby:3.1.0, or whatever is the stable Ruby version du
jour? Well, we’re going this route because we want to make our environment
configurable from the outside using Dockerfile as a sort of a template:

  • The exact versions of the runtime dependencies are specified in the 
    docker-compose.yml (see below 👇).
  • The list of apt-installable dependencies is stored in a separate file
    (also, see below 👇👇).

Additionally, we parameterize the Debian release (bullseye by default) to make
sure we’re adding the correct sources for our other dependencies (such as
PostgreSQL).

Alright, now, note that we declare the argument once again after the FROM
statement:

FROM ruby:$RUBY_VERSION-slim-$DISTRO_NAME
ARG DISTRO_NAME

That’s the tricky part of how Dockerfiles work: the args are reset after the 
FROM statement. For more details, check out [52]this issue.

Moving on, the rest of the file contains the actual build steps. First, we’ll
need to manually install some common system dependencies (Git, cURL, etc.), as
we’re using the slim base Docker image to reduce the size:

# Common dependencies
RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
  --mount=type=cache,target=/var/lib/apt,sharing=locked \
  --mount=type=tmpfs,target=/var/log \
  apt-get update -qq \
  && DEBIAN_FRONTEND=noninteractive apt-get install -yq --no-install-recommends \
    build-essential \
    gnupg2 \
    curl \
    less \
    git

We’ll explain all the details of installing system dependencies below,
alongside the application-specific dependencies.

Installing PostgreSQL and NodeJS via apt requires adding their deb package
repos to the sources list.

Here’s PostgreSQL (based on the [53]official documentation):

ARG PG_MAJOR
RUN curl -sSL https://www.postgresql.org/media/keys/ACCC4CF8.asc | \
    gpg --dearmor -o /usr/share/keyrings/postgres-archive-keyring.gpg \
    && echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/postgres-archive-keyring.gpg] https://apt.postgresql.org/pub/repos/apt/" \
    $DISTRO_NAME-pgdg main $PG_MAJOR | tee /etc/apt/sources.list.d/postgres.list > /dev/null
RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
  --mount=type=cache,target=/var/lib/apt,sharing=locked \
  --mount=type=tmpfs,target=/var/log \
  apt-get update -qq && DEBIAN_FRONTEND=noninteractive apt-get -yq dist-upgrade && \
  DEBIAN_FRONTEND=noninteractive apt-get install -yq --no-install-recommends \
    libpq-dev \
    postgresql-client-$PG_MAJOR

Since we aren’t expecting anyone to use this Dockerfile without [54]
Docker Compose, we don’t provide a default value for the PG_MAJOR argument (the
same applies to NODE_MAJOR below, and YARN_VERSION further below).

Also, notice that in the code above that the DISTRO_NAME argument which we
defined at the very beginning of the file comes back into play.

And, we repeat our apt-get ... apt-get clean spell again: we want to make sure
all the major pieces of our environment are built in an isolated way (this will
help us to better utilize Docker cache layers when performing upgrades).

For NodeJS (from the [55]NodeSource repo):

ARG NODE_MAJOR
RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
    --mount=type=cache,target=/var/lib/apt,sharing=locked \
    --mount=type=tmpfs,target=/var/log \
    apt-get update && \
    apt-get install -y curl software-properties-common && \
    curl -fsSL https://deb.nodesource.com/gpgkey/nodesource.gpg.key | apt-key add - && \
    echo "deb https://deb.nodesource.com/node_${NODE_MAJOR}.x $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/nodesource.list && \
    apt-get update && \
    DEBIAN_FRONTEND=noninteractive apt-get install -yq --no-install-recommends nodejs

Then, we install Yarn via NPM:

ARG YARN_VERSION=latest
RUN npm install -g yarn@$YARN_VERSION

So, why are we adding NodeJS and Yarn in the first place? Although Rails 7
allows you to [56]go Node-less via [57]import maps or precompiled binaries
(like [58]tailwindcss-rails), these additions increase the chances of
supporting legacy pipelines or adding modern Webpacker alternatives.

Now it’s time to install the application-specific dependencies:

COPY Aptfile /tmp/Aptfile
RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
  --mount=type=cache,target=/var/lib/apt,sharing=locked \
  --mount=type=tmpfs,target=/var/log \
  apt-get update -qq && DEBIAN_FRONTEND=noninteractive apt-get -yq dist-upgrade && \
  DEBIAN_FRONTEND=noninteractive apt-get install -yq --no-install-recommends \
    $(grep -Ev '^\s*#' /tmp/Aptfile | xargs)

Let’s talk about that Aptfile trick a bit:

COPY Aptfile /tmp/Aptfile
RUN apt-get install \
    $(grep -Ev '^\s*#' /tmp/Aptfile | xargs) \

I borrowed this idea from [59]heroku-buildpack-apt, which allows for installing
additional packages on Heroku. If you’re using this buildpack, you can even
re-use the same Aptfile for both the local and the production environment.

Our [60]default Aptfile contains only a single package (we’ll use Vim to edit
the Rails Credentials):

vim

In one of the previous projects I worked on, we generated PDFs using LaTeX and 
[61]TexLive. In a case like that, our Aptfile might look like this:

vim
# TeX packages
texlive
texlive-latex-recommended
texlive-fonts-recommended
texlive-lang-cyrillic

By doing this we can keep task-specific dependencies in a separate file, thus
making our Dockerfile more universal.

With regards to DEBIAN_FRONTEND=noninteractive, I kindly ask you to take a look
at this [62]answer on Ask Ubuntu.

The --no-install-recommends option helps save some space (and makes our image
smaller) by disabling the installation of recommended packages. You can see
more [63]about saving disk space here.

That first (fairly cryptic) part of every RUN statement that installs packages
also serves the same purpose: it moves out the local repository of retrieved
package files into a cache that will be preserved between builds. We need this
magic to be in every RUN statement that installs packages to make sure this
particular [64]Docker layer doesn’t contain any garbage. It also greatly speeds
up image build!

[65]RUN --mount is relatively new feature of Docker. Traditionally, every
package installation step would be appended with a dark spell full of rm and 
truncate commands to clean up temporary files.

The final part of the Dockerfile is mostly devoted to Bundler:

# Configure bundler
ENV LANG=C.UTF-8 \
  BUNDLE_JOBS=4 \
  BUNDLE_RETRY=3 \

# Store Bundler settings in the project's root
ENV BUNDLE_APP_CONFIG=.bundle

# Uncomment this line if you want to run binstubs without prefixing with `bin/` or `bundle exec`
# ENV PATH /app/bin:$PATH

# Upgrade RubyGems and install the latest Bundler version
RUN gem update --system && \
    gem install bundler

Using LANG=C.UTF-8 sets the default locale to UTF-8. This is an emotional
setting, as otherwise, Ruby would use US-ASCII for strings—and that’d mean
waving goodbye to those sweet, sweet emojis! 👋

Setting BUNDLE_APP_CONFIG is required if you’ll use the <root>/.bundle folder
to store project-specicic Bundler settings (like credentials for private gems).
The default Ruby image [66]defines this variable so Bundler doesn’t fall back
to the local config.

Optionally, you can add your <root>/bin folder to the PATH in order to run
commands without bundle exec. We don’t do this by default, because it could
break in a multi-project environment (for instance, when you have local gems or
engines in your Rails app).

Previously, we also had to specify the Bundler version (taking advantage of 
[67]some hacks to make sure it’s picked up by the system). Luckily, since
Bundler 2.3.0, we no longer need to manually install the version defined in the
Gemfile.lock (BUNDLED_WITH). Instead, to avoid conflicts, Bundler [68]does this
for us.

[69]compose.yml

[70]Docker Compose is a tool we can use to orchestrate our containerized
environment. It allows us to link containers to each other, and to define
persistent volumes and services.

Below is the compose file for developing a typical Rails application with
PostgreSQL as the database, and with Sidekiq as the background job processor:

x-app: &app
  build:
    context: .
    args:
      RUBY_VERSION: '3.2.2'
      PG_MAJOR: '15'
      NODE_MAJOR: '18'
  image: example-dev:1.0.0
  environment: &env
    NODE_ENV: ${NODE_ENV:-development}
    RAILS_ENV: ${RAILS_ENV:-development}
  tmpfs:
    - /tmp
    - /app/tmp/pids

x-backend: &backend
  <<: *app
  stdin_open: true
  tty: true
  volumes:
    - ..:/app:cached
    - bundle:/usr/local/bundle
    - rails_cache:/app/tmp/cache
    - node_modules:/app/node_modules
    - packs:/app/public/packs
    - packs-test:/app/public/packs-test
    - history:/usr/local/hist
    - ./.psqlrc:/root/.psqlrc:ro
    - ./.bashrc:/root/.bashrc:ro
  environment: &backend_environment
    <<: *env
    REDIS_URL: redis://redis:6379/
    DATABASE_URL: postgres://postgres:postgres@postgres:5432
    WEBPACKER_DEV_SERVER_HOST: webpacker
    MALLOC_ARENA_MAX: 2
    WEB_CONCURRENCY: ${WEB_CONCURRENCY:-1}
    BOOTSNAP_CACHE_DIR: /usr/local/bundle/_bootsnap
    XDG_DATA_HOME: /app/tmp/caches
    YARN_CACHE_FOLDER: /app/node_modules/.yarn-cache
    HISTFILE: /usr/local/hist/.bash_history
    PSQL_HISTFILE: /usr/local/hist/.psql_history
    IRB_HISTFILE: /usr/local/hist/.irb_history
    EDITOR: vi
  depends_on: &backend_depends_on
    postgres:
      condition: service_healthy
    redis:
      condition: service_healthy

services:
  rails:
    <<: *backend
    command: bundle exec rails

  web:
    <<: *backend
    command: bundle exec rails server -b 0.0.0.0
    ports:
      - '3000:3000'
    depends_on:
      webpacker:
        condition: service_started
      sidekiq:
        condition: service_started

  sidekiq:
    <<: *backend
    command: bundle exec sidekiq -C config/sidekiq.yml

  postgres:
    image: postgres:14
    volumes:
      - .psqlrc:/root/.psqlrc:ro
      - postgres:/var/lib/postgresql/data
      - history:/user/local/hist
    environment:
      PSQL_HISTFILE: /user/local/hist/.psql_history
      POSTGRES_PASSWORD: postgres
    ports:
      - 5432
    healthcheck:
      test: pg_isready -U postgres -h 127.0.0.1
      interval: 5s

  redis:
    image: redis:6.2-alpine
    volumes:
      - redis:/data
    ports:
      - 6379
    healthcheck:
      test: redis-cli ping
      interval: 1s
      timeout: 3s
      retries: 30

  webpacker:
    <<: *app
    command: bundle exec ./bin/webpack-dev-server
    ports:
      - '3035:3035'
    volumes:
      - ..:/app:cached
      - bundle:/usr/local/bundle
      - node_modules:/app/node_modules
      - packs:/app/public/packs
      - packs-test:/app/public/packs-test
    environment:
      <<: *env
      WEBPACKER_DEV_SERVER_HOST: 0.0.0.0
      YARN_CACHE_FOLDER: /app/node_modules/.yarn-cache

volumes:
  bundle:
  node_modules:
  history:
  rails_cache:
  postgres:
  redis:
  packs:
  packs-test:

We define six services and two extension fields (x-app and x-backend). [71]
Extension fields allow us to define common parts of the configuration. We can
attach YAML anchors to them, and later, embed anywhere in the file.

NOTE: In the end, we don’t use Docker Compose or execute the docker compose up
command in order to run our application. Instead, we use Dip (see [72]below),
and thus, the compose.yml file only acts as a services registry. Another
important thing to note is that we put the compose.yml file into the .dockerdev
/ folder. This is why we mount the source code as ..:/app and not .:/app.
Please, keep this in mind if you’re considering using this configuration
without Dip (which is not recommended).

On that note, let’s go ahead and take a thorough look at each service.

x-app

The main purpose of this extension is to provide all the required information
to build our application container (as defined in the Dockerfile above):

x-app: &app
  build:
    context: .
    args:
      RUBY_VERSION: '3.2.2'
      PG_MAJOR: '15'
      NODE_MAJOR: '18'

What is the context? The context directory defines the [73]build context for
Docker. This is something like a working directory for the build process—for
example, when we execute the COPY command. As this directory is packaged and
sent to the Docker daemon every time an image is built, it’s better to keep it
as small as possible. We’re good here, since our context is just the .dockerdev
folder.

And, as we mentioned earlier, we’ll specify the exact version of our
dependencies using the args as declared in the Dockerfile.

It’s also a good idea to pay attention to the way we tag images:

image: example-dev:1.0.0

One of the benefits of using Docker for development is the ability to
automatically synchronize configuration changes across the team. This means the
only time you need to upgrade the local image version is when you make changes
to it (or to the arguments or files it relies on). Using example-dev:latest is
like shooting yourself in the foot.

Keeping an image version also helps work with two different environments
without any additional hassle. For example, when working on a long-standing
“chore/upgrade-to-ruby-3” branch, you can easily switch to master and use the
older image with the older version of Ruby: no need to rebuild anything.

    Rule of thumb: Increase the version number in the image tag every time you
    change Dockerfile or its arguments (upgrading dependencies, etc.)

Next, we add some common environment variables (those shared by multiple
services, e.g., Rails and Webpacker):

environment: &env
  NODE_ENV: ${NODE_ENV:-development}
  RAILS_ENV: ${RAILS_ENV:-development}

There are several things going on here, but I’d like to focus on just one: the 
X=${X:-smth} syntax. This could be translated as “For X variable within the
container, if present, use the host machine’s X env variable, otherwise, use
another value”. Thus, we make it possible to run a service in a different
environment specified along with a command, e.g., RAILS_ENV=test docker-compose
up rails.

Note that we’re using a dictionary value (NODE_ENV: xxx) and not a list value (
- NODE_ENV=xxx) for the environment field. This allows us to re-use the common
settings (see below).

We also tell Docker to [74]use tmpfs for the /tmp folder within a container—and
also for the tmp/pids folder of our application. This way, we ensure that no 
server.pid survives a container exit (say goodbye to any “A server is already
running” errors):

tmpfs:
  - /tmp
  - /app/tmp/pids

x-backend

Alright, so now, we’ve finally reached the most interesting part of this post.

This service defines the shared behavior of all Ruby services.

Let’s talk about the volumes first:

x-backend: &backend
  <<: *app
  stdin_open: true
  tty: true
  volumes:
    - ..:/app:cached
    - rails_cache:/app/tmp/cache
    - bundle:/usr/local/bundle
    - history:/usr/local/hist
    - node_modules:/app/node_modules
    - packs:/app/public/packs
    - packs-test:/app/public/packs-test
    - ./.psqlrc:/root/.psqlrc:ro
    - ./.bashrc:/root/.bashrc:ro
    - ./.pryrc:/root/.pryrc:ro
  environment: &backend_environment
    <<: *env
    REDIS_URL: redis://redis:6379/
    DATABASE_URL: postgres://postgres:postgres@postgres:5432
    WEBPACKER_DEV_SERVER_HOST: webpacker
    MALLOC_ARENA_MAX: 2
    WEB_CONCURRENCY: ${WEB_CONCURRENCY:-1}
    BOOTSNAP_CACHE_DIR: /usr/local/bundle/_bootsnap
    XDG_DATA_HOME: /app/tmp/caches
    YARN_CACHE_FOLDER: /app/node_modules/.yarn-cache
    HISTFILE: /usr/local/hist/.bash_history
    PSQL_HISTFILE: /usr/local/hist/.psql_history
    IRB_HISTFILE: /usr/local/hist/.irb_history
    EDITOR: vi
  depends_on: &backend_depends_on
    postgres:
      condition: service_healthy
    redis:
      condition: service_healthy
volumes:
  - ..:/app:cached
  - bundle:/usr/local/bundle
  - rails_cache:/app/tmp/cache
  - node_modules:/app/node_modules
  - packs:/app/public/packs
  - packs-test:/app/public/packs-test
  - history:/usr/local/hist
  - ./.psqlrc:/root/.psqlrc:ro
  - ./.bashrc:/root/.bashrc:ro

The Docker team is striving to make Docker work faster on MacOS. The latest
releases (since [75]4.6.0) come with VirtioFS accelerated directory sharing and
virtualization.framework support. Go check the “Experimental Features” tab in
the Docker Desktop Preferences. You might find the resulting performance
improvement to be pretty amazing: ([76]regular actions become ~2x faster)!

The first item in the volumes list mounts the project directory to the /app
folder within a container using the cached strategy. This cached modifier was
the key to efficient Docker development on macOS.

Wait, was?

Yeah. Was. That’s because since the release of gRPC FUSE synchronization, it’s 
[77]no longer needed. Still, I decided to keep it for a while, for two reasons:
first, some of your teammates may still be using older Docker desktop versions,
and second, I ran some benchmarks and found that using older osxfs file sharing
could have better performance (but only when using :cached). So, even on modern
versions of Docker, it could make sense to uncheck the “Use gRPC FUSE for file
sharing” option inside the preferences menu.

The next line tells our container to use a volume named bundle to store the
contents of /usr/local/bundle (this is where gems are stored [78]by default).
By doing this, we persist our gem data across runs: all the volumes defined in 
compose.yml will stay put until we run compose down --volumes.

The following lines have also been dutifully placed in order to nullify the
“Docker is slow on Mac” curse. We put all the generated files into Docker
volumes to avoid any heavy disk operations on the host machine:

- rails_cache:/app/tmp/cache
- node_modules:/app/node_modules
- packs:/app/public/packs
- packs-test:/app/public/packs-test

    To give Docker a suitably fast speed on macOS, follow these two rules: use 
    :cached to mount source files (if not using gRPC FUSE), and use volumes for
    generated content (assets, bundle, etc.).

NOTE: If you’re using Sprockets (or Propshaft), don’t forget to add a dedicated
volume to store the assets (assets:/app/public/assets). For tailwindcss-rails,
add something like assets_builds:/app/assets/builds.

We’ll then mount different command line tools configuration files and a volume
to persist their history:

- history:/usr/local/hist
- ./.psqlrc:/root/.psqlrc:ro
- ./.bashrc:/root/.bashrc:ro

Oh, and why is psql in the Ruby container? That’s because it’s used internally
when you run rails dbconsole.

Pressing onward, our [79].psqlrc file contains the following trick which makes
it possible to specify the path to the history file via the env variable—thus
allowing us to specify the path to the history file via the PSQL_HISTFILE env
variable, or otherwise, fall back to the default $HOME/.psql_history:

\set HISTFILE `[[ -z $PSQL_HISTFILE ]] && echo $HOME/.psql_history || echo $PSQL_HISTFILE`

The .bashrc file allows us to add terminal customizations within a container:

alias be="bundle exec"

Alright, let’s talk about the environment variables:

environment: &backend_environment
  <<: *env
  # ----
  # Service discovery
  # ----
  REDIS_URL: redis://redis:6379/
  DATABASE_URL: postgres://postgres:postgres@postgres:5432
  WEBPACKER_DEV_SERVER_HOST: webpacker
  # ----
  # Application configuration
  # ----
  MALLOC_ARENA_MAX: 2
  WEB_CONCURRENCY: ${WEB_CONCURRENCY:-1}
  # -----
  # Caches
  # -----
  BOOTSNAP_CACHE_DIR: /usr/local/bundle/_bootsnap
  # This env variable is used by some tools (e.g., RuboCop) to store caches
  XDG_DATA_HOME: /app/tmp/cache
  # Puts the Yarn cache into a mounted volume for speed
  YARN_CACHE_FOLDER: /app/node_modules/.yarn-cache
  # ----
  # Dev tools
  # ----
  HISTFILE: /usr/local/hist/.bash_history
  PSQL_HISTFILE: /usr/local/hist/.psql_history
  IRB_HISTFILE: /usr/local/hist/.irb_history
  EDITOR: vi

First of all, we “inherit” variables from the common environment variables (<<:
*env).

The first group of variables (DATABASE_URL, REDIS_URL, and 
WEBPACKER_DEV_SERVER_HOST) connect our Ruby application to other services.

The DATABASE_URL and WEBPACKER_DEV_SERVER_HOST variables are supported by Rails
(ActiveRecord and Webpacker respectively) out of the box. Some libraries
(Sidekiq) also support REDIS_URL, but not all of them: for instance, Action
Cable must be explicitly configured.

The second group contains some application-wide settings. For example, we
define MALLOC_ARENA_MAX and WEB_CONCURRENCY to help us keep Ruby memory
handling in check.

Read more about Ruby memory spells and techniques:

[80]Cables vs. malloc_trim, or yet another Ruby memory usage benchmark

Cables vs. malloc_trim, or yet another Ruby memory usage benchmark

March 19, 2019
Read also

Also, we have the variables responsible for storing caches in Docker volumes (
BOOTSNAP_CACHE_DIR, XDG_DATA_HOME, YARN_CACHE_FOLDER).

We use [81]bootsnap to speed up application load time. We store its cache in
the same volume as the Bundler data. This is because this cache mostly contains
the gem data, and we want to make sure the cache is reset every time we drop
the Bundler volume (for instance, during a Ruby version upgrade).

The final group of variables aim to improve the developer experience. HISTFILE:
/usr/local/hist/.bash_history is the most significant here: it tells Bash to
store its history in the specified location, thus making it persistent. The
same goes for PSQL_HISTFILE and IRB_HISTFILE.

NOTE: You need to configure IRB to store history in the specified location. To
do that, drop these lines into your .irbrc file:

IRB.conf[:HISTORY_FILE] = ENV["IRB_HISTFILE"] if ENV["IRB_HISTFILE"]

Finally, EDITOR: vi is used, for example, by the rails credentials:edit command
to manage credentials files.

And with that, the only lines in this service we’ve yet to cover are:

stdin_open: true
tty: true

These lines make this service interactive, that is, they provide a TTY. We need
this, for example, to run the Rails console or Bash within a container.

This is the same as running a Docker container with the -it option.

rails

The rails server is our default backend service. The only thing it overrides is
the command to execute:

rails:
  <<: *backend
  command: bundle exec rails

This service is meant for executing all the commands needed in development (
rails db:migrate, rspec, etc.).

web

The web service is meant for launching a web server. It defines the exposed
ports and the required dependencies to run the app itself.

webpacker

The only thing I want to mention here is the WEBPACKER_DEV_SERVER_HOST: 0.0.0.0
setting: it makes the Webpack dev server accessible from the outside (it runs
on localhost by default).

Health checks

When running common Rails commands such as db:migrate, we want to ensure that
the DB is up and ready to accept connections. How can we tell Docker Compose to
wait until a dependent service is ready? We can use [82]health checks!

You’ve probably noticed that our depends_on definition isn’t just a list of
services:

backend:
  # ...
  depends_on:
    postgres:
      condition: service_healthy
    redis:
      condition: service_healthy

postgres:
  # ...
  healthcheck:
    test: pg_isready -U postgres -h 127.0.0.1
    interval: 5s

redis:
  # ...
  healthcheck:
    test: redis-cli ping
    interval: 1s
    timeout: 3s
    retries: 30

Introducing Dip

If you still think that Docker Compose way is too complicated, there’s a tool
called [83]Dip (developed by one of my colleages at Evil Martians) which aims
to make the developer experience even smoother.

[84]Reusable development containers with Docker Compose and Dip

Reusable development containers with Docker Compose and Dip

November 17, 2020
Read also

[85]Dip is a thin wrapper over docker compose, which provides a switch from
infrastructure-oriented flow to development-oriented one. The key benefits of
using Dip are as follows:

  • The ability to define application-specific interactive commands and
    sub-commands.
  • The dip provision flow to quickly set up a development environment from
    scratch.
  • Support for multiple compose.yml files (including OS-specific
    configurations).

With Dip in place, to start working on the app locally, you just need to
execute a few commands:

# Builds a Docker image if none, runs additional commands
$ dip provision
# Runs a Rails server with the defined dependencies
$ dip rails s
=> Booting Puma
=> Rails 7.0.2.2 application starting in development
=> Run `bin/rails server --help` for more startup options
[1] Puma starting in cluster mode...
...
[1] - Worker 0 (PID: 9) booted in 0.0s, phase: 0

Here is our typical [86]dip.yml file:

version: '7.1'

# Define default environment variables to pass
# to Docker Compose
environment:
  RAILS_ENV: development

compose:
  files:
    - .dockerdev/compose.yml
  project_name: example_demo

interaction:
  # This command spins up a Rails container with the required dependencies (such as databases),
  # and opens a terminal within it.
  runner:
    description: Open a Bash shell within a Rails container (with dependencies up)
    service: rails
    command: /bin/bash

  # Run a Rails container without any dependent services (useful for non-Rails scripts)
  bash:
    description: Run an arbitrary script within a container (or open a shell without deps)
    service: rails
    command: /bin/bash
    compose_run_options: [ no-deps ]

  # A shortcut to run Bundler commands
  bundle:
    description: Run Bundler commands
    service: rails
    command: bundle
    compose_run_options: [ no-deps ]

  # A shortcut to run RSpec (which overrides the RAILS_ENV)
  rspec:
    description: Run RSpec commands
    service: rails
    environment:
      RAILS_ENV: test
    command: bundle exec rspec

  rails:
    description: Run Rails commands
    service: rails
    command: bundle exec rails
    subcommands:
      s:
        description: Run Rails server at http://localhost:3000
        service: web
        compose:
          run_options: [service-ports, use-aliases]

  yarn:
    description: Run Yarn commands
    service: rails
    command: yarn
    compose_run_options: [ no-deps ]

  psql:
    description: Run Postgres psql console
    service: postgres
    default_args: anycasts_dev
    command: psql -h postgres -U postgres

  'redis-cli':
    description: Run Redis console
    service: redis
    command: redis-cli -h redis

provision:
  - dip compose down --volumes
  - dip compose up -d postgres redis
  - dip bash -c bin/setup

Let me explain some bits of this in further detail.

First, the compose section:

compose:
  files:
    - .dockerdev/compose.yml
  project_name: example_demo

Here we should specify the path to our Compose configuration (.dockerdev/
compose.yml). Accordingly, we can run dip from the project root, and the
correct configuration will be picked up.

The project_name is important: if we don’t specify it, the folder containing
the compose.yml file would be used (“dockerdev”), which could lead to
collisions between different projects.

The rails command is also worth some additional attention:

rails:
  description: Run Rails commands
  service: rails
  command: bundle exec rails
  subcommands:
    s:
      description: Run Rails server at http://localhost:3000
      service: web
      compose:
        run_options: [service-ports, use-aliases]

By default, the dip rails command would call bundle exec rails within a Rails
container. However, we use the subcommand feature of Dip here to treat dip
rails s differently:

  • We use the web service, not rails (so, the deps are up).
  • We expose the service ports (3000 in our case).
  • We also enable network aliases, so other services can access this container
    via the web hostname.

Under the hood, this will result in the following Docker Compose command:

docker compose run --rm --service-ports --use-aliases web

Note that it uses run, and not up. This difference makes our server
terminal-accessible. For example, this means that we can attach a debugger and
use it without any problems (with the up command the terminal is
non-interactive).

Interactive provisioning

To learn how to keep configuration under control, check out this “Terraforming
Rails” series:

[87]Anyway Config: Keep your Ruby configuration sane

Anyway Config: Keep your Ruby configuration sane

April 14, 2020
[svg]
Cover for Anyway Config: Keep your Ruby configuration sane
Read also

For most applications, building an image and setting up a database is not
enough to start developing: beyond this, some kind of secrets, or credentials,
or .env files are required. Here, we’ve managed to use Dip to help new
engineers quickly assemble all these wayfallen parts by providing an
interactive provision experience.

Let’s consider, for example, that we need to put a .env.development.local file
with some secret info and also configure RubyGems to download packages from a
private registry (say, Sidekiq Pro). For this, I’ll write the following
provision script:

# The command is extracted, so we can use it alone
configure_bundler:
  command: |
    (test -f .bundle/config && cat .bundle/config | \
      grep BUNDLE_ENTERPRISE__CONTRIBSYS__COM > /dev/null) ||
    \
      (echo "Sidekiq ent credentials: "; read -r creds; dip bundle config --local enterprise.contribsys.com $creds)

provision:
  - (test -f .env.development.local) || (echo "\n\n ⚠️  .env.development.local file is missing\n\n"; exit 1)
  - dip compose down --volumes
  - dip configure_bundler
  - (test -f config/database.yml) || (cp .dockerdev/database.yml.example config/database.yml)
  - dip compose up -d postgres redis
  - dip bash -c bin/setup

Below you can see a demonstration of this command running in action:

An interactive Dip provisioning example

Services vs Docker for development

You can use a good ‘ol [88]Makefile to do the same, for sure. However, we’ve
found that using a dedicated tool (like Dip) to define everything in a
declarative manner is more efficient.

One more use case for standardizing the development setup is to make it
possible to run multiple independent services locally. Let me quickly
demonstrate how we do this with Dip. First, you need to dockerize each
application (following this post). After that, we need to connect the apps to
each other. How can we do this? With the help of Docker Compose [89]external
networks.

We add the following line to the dip.yml for each app:

# ...
provision:
  # Make sure the named network exists
  - docker network inspect my_project > /dev/null 2>&1 || \
    docker network create my_project
# ...

Finally, we attach services to this network via aliases in the compose.yml
files:

# service A: compose.yml
service:
  ruby:
    # ...
    networks:
      default:
      project:
        aliases:
          - project-a

networks:
  project:
    external:
      name: my_project

# service B: compose.yml
service:
  web:
    # ...
    environment:
      # We can access the service A via its alias defined for the external network
      SERVICE_URL: http://project-a:3000

networks:
  project:
    external:
      name: my_project

From development to production

So, here’s one of the most popular questions we’ve been asked since launching
the first version of this article: how to go live with Docker? To answer this,
we’d need to write a entirely new article… and we will 😉.

For now, let me give a sneak preview of how can we extend the current
development setup to cover the production environment as well.

First of all, we’re not going to talk about a Docker Compose-based deployment,
so compose.yml is out. All we need is to update our Docker image to reflect the
difference between development and production:

 1. For security reasons, we should execute the code on behalf of the regular,
    non-root user.
 2. We should keep all the required dependencies and artifacts within the image
    itself; we cannot use volumes (the image should be self-contained).
 3. We should keep and copy the source code into a container.
 4. The resulting image should be as slim as possible.

To achieve this, we’ll refactor our existing Dockerfile to define multiple
stages (and to support [90]multi-stage builds). Below is the annotated example:

# syntax=docker/dockerfile:1

ARG RUBY_VERSION
ARG DISTRO_NAME=bullseye

# Here we add the the name of the stage ("base")
FROM ruby:$RUBY_VERSION-slim-$DISTRO_NAME AS base

ARG PG_MAJOR
ARG NODE_MAJOR
ARG YARN_VERSION

# Common dependencies
# ...
# The following lines are exactly the same as before
# ...
# ...
WORKDIR /app

EXPOSE 3000
CMD ["/bin/bash"]

# Then, we define the "development" stage from the base one
FROM base AS development

ENV RAILS_ENV=development

# The major difference from the base image is that we may have development-only system
# dependencies (like Vim or graphviz).
# We extract them into the Aptfile.dev file.
COPY Aptfile.dev /tmp/Aptfile.dev
RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
  --mount=type=cache,target=/var/lib/apt,sharing=locked \
  --mount=type=tmpfs,target=/var/log \
  apt-get update -qq && DEBIAN_FRONTEND=noninteractive apt-get -yq dist-upgrade && \
  DEBIAN_FRONTEND=noninteractive apt-get install -yq --no-install-recommends \
    $(grep -Ev '^\s*#' /tmp/Aptfile.dev | xargs)

# The production-builder image is responsible for installing dependencies and compiling assets
FROM base as production-builder

# First, we create and configure a dedicated user to run our application
RUN groupadd --gid 1005 my_user \
  && useradd --uid 1005 --gid my_user --shell /bin/bash --create-home my_user
USER my_user
RUN mkdir /home/my_user/app
WORKDIR /home/my_user/app

# Then, we re-configure Bundler
ENV RAILS_ENV=production \
  LANG=C.UTF-8 \
  BUNDLE_JOBS=4 \
  BUNDLE_RETRY=3 \
  BUNDLE_APP_CONFIG=/home/my_user/bundle \
  BUNDLE_PATH=/home/my_user/bundle \
  GEM_HOME=/home/my_user/bundle

# Install Ruby gems
COPY --chown=my_user:my_user Gemfile Gemfile.lock ./
RUN mkdir $BUNDLE_PATH \
  && bundle config --local deployment 'true' \
  && bundle config --local path "${BUNDLE_PATH}" \
  && bundle config --local without 'development test' \
  && bundle config --local clean 'true' \
  && bundle config --local no-cache 'true' \
  && bundle install --jobs=${BUNDLE_JOBS} \
  && rm -rf $BUNDLE_PATH/ruby/${RUBY_VERSION}/cache/* \
  && rm -rf /home/my_user/.bundle/cache/*

# Install JS packages
COPY --chown=my_user:my_user package.json yarn.lock ./
RUN yarn install --check-files

# Copy code
COPY --chown=my_user:my_user . .

# Precompile assets
# NOTE: The command may require adding some environment variables (e.g., SECRET_KEY_BASE) if you're not using
# credentials.
RUN bundle exec rails assets:precompile

# Finally, our production image definition
# NOTE: It's not extending the base image, it's a new one
FROM ruby:$RUBY_VERSION-slim-$DISTRO_NAME AS production

# Production-only dependencies
RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
  --mount=type=cache,target=/var/lib/apt,sharing=locked \
  --mount=type=tmpfs,target=/var/log \
  apt-get update -qq \
  && apt-get dist-upgrade -y \
  && DEBIAN_FRONTEND=noninteractive apt-get install -yq --no-install-recommends \
    curl \
    gnupg2 \
    less \
    tzdata \
    time \
    locales \
  && update-locale LANG=C.UTF-8 LC_ALL=C.UTF-8

# Upgrade RubyGems and install the latest Bundler version
RUN gem update --system && \
    gem install bundler

# Create and configure a dedicated user (use the same name as for the production-builder image)
RUN groupadd --gid 1005 my_user \
  && useradd --uid 1005 --gid my_user --shell /bin/bash --create-home my_user
RUN mkdir /home/my_user/app
WORKDIR /home/my_user/app
USER my_user

# Ruby/Rails env configuration
ENV RAILS_ENV=production \
  BUNDLE_APP_CONFIG=/home/my_user/bundle \
  BUNDLE_PATH=/home/my_user/bundle \
  GEM_HOME=/home/my_user/bundle \
  PATH="/home/my_user/app/bin:${PATH}" \
  LANG=C.UTF-8 \
  LC_ALL=C.UTF-8

EXPOSE 3000

# Copy code
COPY --chown=my_user:my_user . .

# Copy artifacts
# 1) Installed gems
COPY --from=production-builder $BUNDLE_PATH $BUNDLE_PATH
# 2) Compiled assets (by Webpacker in this case)
COPY --from=production-builder /home/my_user/app/public/packs /home/my_user/app/public/packs
# 3) We can even copy the Bootsnap cache to speed up our Rails server load!
COPY --chown=my_user:my_user --from=production-builder /home/my_user/app/tmp/cache/bootsnap* /home/my_user/app/tmp/cache/

CMD ["bundle", "exec", "rails", "server", "-b", "0.0.0.0"]

Introducing the Ruby on Whales interactive generator

As a bonus, our Ruby on Whales [91]repository ships with a Rails template
(published on [92]Rails Bytes), which can help you quickly adopt Docker for
development by running a single command (and answering a few questions).

Without further ado, check out the demonstartion below:

An interactive Ruby on Whales installer

You can give it a try by running a single command:

rails app:template LOCATION='https://railsbytes.com/script/z5OsoB'

Radio wave representing wind sounds on Mars

Acknoledgements

I would like to thank:

  • [93]Sergey Ponomarev for sharing performance tips and helping battle-test
    the initial dockerization attempts.
  • [94]Mikhail Merkushin for his work on Dip.
  • [95]Dmitriy Nemykin for helping with the major (v2) upgrade.
  • [96]Oliver Klee ([97]Brain Gourmets) for continuous PRs with the
    configuration improvements and actualization.

Radio wave representing wind sounds on Mars

Changelog

2.0.3 (2023-09-21)

  • Upgrade Node.js installation script.

2.0.2 (2022-11-30)

  • Use RUN --mount for caching packages between builds instead of manual
    cleanup.

2.0.1 (2022-03-22)

  • Replace deprecated apt-key with gpg.

2.0.0 (2022-03-02)

  • Major upgrade and new chapters.

1.1.4 (2021-10-12)

  • Added tmp/pids to tmpfs (to deal with “A server is already running”
    errors).

1.1.3 (2021-03-30)

  • Updated Dockerfile to mitigate MiniMagic licensing issues. See [98]
    terraforming-rails#35
  • Use dictionary to organize environment variables. See [99]
    terraforming-rails#6

1.1.2 (2021-02-26)

  • Update dependencies versions. See [100]terraforming-rails#28
  • Allow to use comments in Aptfile. See [101]terraforming-rails#31
  • Fix path to Aptfile inside Dockerfile. See [102]terraforming-rails#33

1.1.1 (2020-09-15)

  • Use .dockerdev directory as build context instead of project directory. See
    [103]terraforming-rails#26 for details.

1.1.0 (2019-12-10)

  • Change base Ruby image to slim.
  • Specify Debian release for Ruby version explicitly and upgrade to buster.
  • Use standard Bundler path (/usr/local/bundle) instead of /bundle.
  • Use Docker Compose file format v2.4.
  • Add health checking to postgres and redis services.

Join our email newsletter

Get all the new posts delivered directly to your inbox. Unsubscribe anytime.

[104][                    ]Your email[105][                    ]
Subscribe
Or [107]subscribe to a feed
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[108]chronicles@evilmartians.com

United States

[109]+1 888 400 5485

Portugal

[110]+351 308 808 570

Japan

[111]+81 6 6225 1242

  • [112]Contact us
  • [113]Careers
  • [114]日本語版

[115]Privacy policy
[116]Cookie & privacy preferences
[117]Notice at collection

Designed and developed by Evil Martians


References:

[1] https://evilmartians.com/
[2] https://cal.com/team/evilmartians/exploration
[3] https://evilmartians.com/services
[4] https://evilmartians.com/clients
[5] https://evilmartians.com/products
[6] https://evilmartians.com/opensource
[7] https://evilmartians.com/chronicles
[8] https://evilmartians.com/events
[9] https://evilmartians.com/devpropulsionlabs
[10] https://x.com/evilmartians
[11] https://www.linkedin.com/company/evil-martians
[12] https://github.com/evilmartians
[13] https://www.youtube.com/@evil.martians
[14] https://evilmartians.com/
[15] https://cal.com/team/evilmartians/exploration
[16] https://evilmartians.com/services
[17] https://evilmartians.com/clients
[18] https://evilmartians.com/products
[19] https://evilmartians.com/opensource
[20] https://evilmartians.com/chronicles
[21] https://evilmartians.com/events
[22] https://evilmartians.com/devpropulsionlabs
[23] https://x.com/evilmartians
[24] https://www.linkedin.com/company/evil-martians
[25] https://github.com/evilmartians
[26] https://www.youtube.com/@evil.martians
[27] https://evilmartians.com/events/evolution-of-real-time-and-anycable-rocky-mountain
[28] https://cal.com/team/evilmartians/exploration
[29] https://x.com/evilmartians
[30] https://www.linkedin.com/company/evil-martians
[31] https://github.com/evilmartians
[32] https://www.youtube.com/@evil.martians
[33] https://evilmartians.com/chronicles?categories=backend
[34] https://evilmartians.com/chronicles?services=software-development
[35] https://evilmartians.com/chronicles?services=audit-and-optimization
[36] https://evilmartians.com/chronicles?skills=rubyonrails
[37] https://evilmartians.com/chronicles?skills=ruby
[38] https://evilmartians.com/chronicles?skills=docker
[39] https://evilmartians.com/chronicles?skills=postgresql
[40] https://evilmartians.com/chronicles?skills=nodejs
[41] https://techracho.bpsinc.jp/hachi8833/2022_04_07/116843
[42] https://xfyuan.github.io/2020/07/dockeerizing-rails-development/
[43] https://evilmartians.com/chronicles/ruby-on-whales-docker-for-ruby-rails-development#changelog
[44] https://noti.st/palkan/vhsbxO/terraforming-legacy-rails-applications
[45] https://github.com/evilmartians/ruby-on-whales
[46] https://evilmartians.com/chronicles/ruby-on-whales-docker-for-ruby-rails-development#basic-docker-configuration
[47] https://evilmartians.com/chronicles/ruby-on-whales-docker-for-ruby-rails-development#introducing-dip
[48] https://evilmartians.com/chronicles/ruby-on-whales-docker-for-ruby-rails-development#services-vs-docker-for-development
[49] https://evilmartians.com/chronicles/ruby-on-whales-docker-for-ruby-rails-development#from-development-to-production
[50] https://evilmartians.com/chronicles/ruby-on-whales-docker-for-ruby-rails-development#introducing-the-ruby-on-whales-interactive-generator
[51] https://github.com/evilmartians/ruby-on-whales/blob/main/example/.dockerdev/Dockerfile
[52] https://github.com/moby/moby/issues/34129
[53] https://www.postgresql.org/download/linux/debian/
[54] https://docs.docker.com/compose/
[55] https://github.com/nodesource/distributions/blob/master/README.md#debinstall
[56] https://world.hey.com/dhh/modern-web-apps-without-javascript-bundling-or-transpiling-a20f2755
[57] https://github.com/WICG/import-maps
[58] https://github.com/rails/tailwindcss-rails
[59] https://github.com/heroku/heroku-buildpack-apt
[60] https://github.com/evilmartians/terraforming-rails/blob/master/examples/dockerdev/.dockerdev/Aptfile
[61] https://www.tug.org/texlive/
[62] https://askubuntu.com/a/972528
[63] http://xubuntugeek.blogspot.com/2012/06/save-disk-space-with-apt-get-option-no.html
[64] https://docs.docker.com/storage/storagedriver/#images-and-layers
[65] https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/reference.md#run---mount
[66] https://github.com/docker-library/ruby/issues/129#issue-229195231
[67] https://github.com/evilmartians/terraforming-rails/pull/24
[68] https://github.com/rubygems/rubygems/pull/4076
[69] https://github.com/evilmartians/ruby-on-whales/blob/main/example/.dockerdev/compose.yml
[70] https://docs.docker.com/compose/
[71] https://github.com/compose-spec/compose-spec/blob/master/spec.md#extension
[72] https://evilmartians.com/chronicles/ruby-on-whales-docker-for-ruby-rails-development#introducing-dip
[73] https://docs.docker.com/compose/compose-file/#context
[74] https://docs.docker.com/v17.09/engine/admin/volumes/tmpfs/#choosing-the-tmpfs-or-mount-flag
[75] https://www.docker.com/blog/speed-boost-achievement-unlocked-on-docker-desktop-4-6-for-mac/
[76] https://twitter.com/palkan_tula/status/1504499523216945167
[77] https://github.com/docker/for-mac/issues/5402
[78] https://github.com/infosiftr/ruby/blob/9b1f77c11d663930f4175c683b1c5f268d4d8191/Dockerfile.template#L47
[79] https://github.com/evilmartians/ruby-on-whales/blob/main/example/.dockerdev/.psqlrc
[80] https://evilmartians.com/chronicles/cables-vs-malloc_trim-or-yet-another-ruby-memory-usage-benchmark
[81] https://www.github.com/Shopify/bootsnap
[82] https://docs.docker.com/compose/compose-file/compose-file-v3/#healthcheck
[83] https://evilmartians.com/opensource/dip
[84] https://evilmartians.com/chronicles/reusable-development-containers-with-docker-compose-and-dip
[85] https://evilmartians.com/opensource/dip
[86] https://github.com/evilmartians/ruby-on-whales/blob/main/example/dip.yml
[87] https://evilmartians.com/chronicles/anyway-config-keep-your-ruby-configuration-sane
[88] https://makefile.site/
[89] https://docs.docker.com/compose/networking/#use-a-pre-existing-network
[90] https://docs.docker.com/develop/develop-images/multistage-build/
[91] https://github.com/evilmartians/ruby-on-whales
[92] https://railsbytes.com/public/templates/z5OsoB
[93] https://github.com/sponomarev
[94] https://github.com/bibendi
[95] https://github.com/fargelus/
[96] https://github.com/oliverklee
[97] https://www.braingourmets.com/
[98] https://github.com/evilmartians/terraforming-rails/pull/35
[99] https://github.com/evilmartians/terraforming-rails/pull/6
[100] https://github.com/evilmartians/terraforming-rails/pull/28
[101] https://github.com/evilmartians/terraforming-rails/pull/31
[102] https://github.com/evilmartians/terraforming-rails/issues/33
[103] https://github.com/evilmartians/terraforming-rails/issues/26
[107] https://evilmartians.com/chronicles.atom
[108] mailto:chronicles@evilmartians.com
[109] tel:+18884005485
[110] tel:+351308808570
[111] tel:+81662251242
[112] https://evilmartians.com/contact-us
[113] https://wellfound.com/company/evilmartians
[114] https://evilmartians.jp/
[115] https://evilmartians.com/privacy
[116] https://evilmartians.com/cookies
[117] https://evilmartians.com/privacy#notice_at_collection