Have a look at our new Handbook: "Transitioning from Monolith to Microservices"!  Discover →

    15 Jul 2022 · Software Engineering

    Dockerizing a Ruby on Rails Application

    26 min read

    In this tutorial, you will learn how to dockerize a Ruby on Rails application from the ground up. We’re going to build it with PostgreSQL, Redis, and Sidekiq. We’ll also be using Unicorn and Nginx in both development and production.

    If you would prefer to use Puma or something else, this shouldn’t be an issue.

    After reading this article:

    • You will have a basic idea of what Docker is.
    • How Docker can help you to streamline development.
    • How you can use Continuous Integration and Delivery (CI/CD) to build and test your Ruby projects.

    You can find the complete code for this tutorial in this repository.

    What is Docker?

    Docker allows you to package up an application or service with all of its dependencies into a standardized unit. This unit is typically labeled as a Docker image.

    Everything the application needs to run is included. The Docker image contains the code, runtime, system libraries and anything else you would install on a server to make it run if you weren’t using Docker.

    What Makes Docker Different from a Virtual Machine

    You may have used Vagrant, VirtualBox, or VMWare to run a virtual machine. They allow you to isolate services, but there are a few major differences that make virtual machines much less efficient.

    For starters, you need to have an entire guest operating system for each application you want to isolate. It also takes many seconds to boot-up a virtual machine, and each VM can potentially be gigabytes in size.

    Docker containers share your host’s kernel, and isolation is done using cgroups and other linux kernel libraries. Docker is very lightweight—it typically takes a few milliseconds for a container to start, and running a container doesn’t use much disk space at all.

    What’s the Bottom Line?

    What if you could develop your Rails application in isolation on your work station without using RVM or chruby, and changing Ruby versions were super easy?

    What if as a consultant or freelancer with 10 Rails projects, you had everything you needed isolated for each project without needing to waste precious SSD disk space?

    What if you could spin up your Rails, PostgreSQL, Redis, and Sidekiq stack in about 5 seconds?

    What if you wanted to share your project on GitHub and other developers only had to run a single command to get everything running in minutes?

    All of this and much more is possible thanks to Docker.

    The Benefits of Using Docker

    If you’re constantly looking for ways to improve your productivity and make the overall software development experience better, you’ll appreciate the following 5 key benefits Docker offers:

    1. Cross Environment Consistency

    Docker allows you to encapsulate your application in such a way that you can easily move it between environments. It will work properly in all environments and on all machines capable of running Docker.

    2. Expand Your Development Team Painlessly

    You should not have to hand over a 30 page document to a new developer to teach them how to set up your application so they can run it locally. This process can take all day or longer, and the new developer is bound to make mistakes.

    With Docker all developers in your team can get your multi-service application running on their workstation in an automated, repeatable, and efficient way. You just run a few commands, and minutes later it all works.

    3. Use Whatever Technology Fits Best

    If you’re a startup or a shop that uses only one language, you could be putting yourself at a disadvantage. Since you can isolate an application in a Docker container, it becomes possible to broaden your horizons as a developer by experimenting with new languages and frameworks.

    You no longer have to worry about other developers having to set up your technology of choice. You can hand them a Docker image and tell them to run it.

    4. Build Your Image Once and Deploy It Many Times

    Since your applications are inside of a pre-built Docker image, they can be started in milliseconds. This makes it very easy to scale up and down.

    Time-consuming tasks such as installing dependencies only need to be run once at build time. Once the image has been built, you can move it around to many hosts.

    This not only helps with scaling up and down quickly, but it also makes your deployments more predictable and resilient.

    5. Developers and Operation Managers Can Work Together

    Docker’s toolset allows developers and operation managers to work together towards the common goal of deploying an application.

    Docker acts as an abstraction. You can distribute an application, and members of another team do not need to know how to configure or set up its environment.

    It also becomes simple to distribute your Docker images publicly or privately. You can keep tabs of what changed when new versions were pushed and more.


    You will need to install Docker. Docker can be run on most major Linux distributions, and there are tools to let you run it on OSX and Windows too.

    This tutorial focuses on Linux users, but it will include comments when things need to be adjusted for OSX or Windows.

    Installing Docker

    Follow one of the installation guides below for your operating system:

    Before proceeding, you should have Docker installed and you need to have completed at least the hello world example included in one of the installation guides above.

    The Rails Application

    The application we’re going to build will be for the latest version of Rails which happens to be Rails 6 at the time of writing. You can find all the code in this tutorial in this repo.

    Create a Repository

    Create a new GitHub repository to host your code:

    • Clone it to your machine:
    $ git clone YOUR_REPOSITORY_URL

    Generating a New Rails Application

    We’re going to generate a new Rails project without even needing Ruby installed on our work station. We can do this by using the official Ruby Docker image.

    Creating a Rails Image

    We’ll install Rails on a Docker container. For that, we’ll need a Dockerfile. A Dockerfile contains all the commands that you would need to install the programs and libraries. It uses a special syntax that is easy to read.

    Create a file called Dockerfile.rails:

    # Dockerfile.rails
    FROM ruby:3.1.2 AS rails-toolbox
    # Default directory
    ENV INSTALL_PATH /opt/app
    RUN mkdir -p $INSTALL_PATH
    # Install rails
    RUN gem install rails bundler
    #RUN chown -R user:user /opt/app
    WORKDIR /opt/app
    # Run a shell
    CMD ["/bin/sh"]

    The basic Dockerfile commands are:

    • FROM: defines what image to start from. We’ll use the official Ruby image as a starting point.
    • ARG: specifies build-time argument variables. If your workstation is running Linux, the user and group ids should match between the host and the docker container.
    • RUN: executes commands inside the container. In the example, we use it to create a user and group and then to install the Rails gems.
    • ENV: defines environment variables.
    • WORKDIR: changes the current directory inside the container.
    • USER: changes the active user inside the container.
    • CMD: defines the program to run when the container starts.

    To build the image:

    $  docker build -t rails-toolbox -f Dockerfile.rails .

    Creating the Project

    We’ll use the new Rails image to create our project:

    $ docker run -it -v $PWD:/opt/app rails-toolbox rails new --skip-bundle drkiq

    Docker run starts a new container and runs a program inside:

    • -it: attaches your terminal process with the container.
    • -v $PWD:/opt/app: binds your host machine current directory to the container, so files created inside are visible in your machine
    • rails new --skip-bundle drkiq: That’s the command we’re passing to the Rails image. It creates a new project called “drkiq”.

    After running the command, you should find a new directory with Ruby files. It has a brand new Rails project.

    Rails new creates a new git repository, but since we already have one at the top level of the project, we won’t need it, you can delete it:

    $ rm -rf drkiq/.git

    Setting Up a Strong Base

    Before we start adding Docker-specific files to the project, let’s add a few gems to our Gemfile and make a few adjustments to our application to make it production-ready.

    Modifying the Gemfile

    Add the following lines to the bottom of your Gemfile:

    gem 'unicorn', '~> 6.1.0'
    gem 'pg', '~> 1.3.5'
    gem 'sidekiq', '~> 6.4.2'
    gem 'redis-rails', '~> 5.0.2'

    DRYing Out the Database Configuration

    Change your config/database.yml to look like this:

      url: <%= ENV['DATABASE_URL'].gsub('?', '_development?') %>
      url: <%= ENV['DATABASE_URL'].gsub('?', '_test?') %>
      url: <%= ENV['DATABASE_URL'].gsub('?', '_staging?') %>
      url: <%= ENV['DATABASE_URL'].gsub('?', '_production?') %>

    We will be using environment variables to configure our application. The above file allows us to use the DATABASE_URL, while also allowing us to name our databases based on the environment in which they are being run.

    DRYing Out the Secrets File

    Create a config/secrets.yml file, it should look like this:

    development: &default
      secret_key_base: <%= ENV['SECRET_TOKEN'] %>
      <<: *default
      <<: *default
      <<: *default

    YAML is a markup language. If you’ve never seen this syntax before, it involves setting each environment to use the same SECRET_TOKEN environment variable.

    This is fine since the value will be different in each environment.

    Editing the Application Configuration

    Add the following lines to your config/application.rb:

    # ...
    module Drkiq
      class Application < Rails::Application
        config.load_defaults 7.0
        config.log_level = :debug
        config.log_tags  = [:subdomain, :uuid]
        config.logger    = ActiveSupport::TaggedLogging.new(Logger.new(STDOUT))
        config.cache_store = :redis_store, ENV['CACHE_URL'],
                             { namespace: 'drkiq::cache' }
        config.active_job.queue_adapter = :sidekiq

    Creating the Unicorn Config

    Next, create the config/unicorn.rb file and add the following content to it:

    # Heavily inspired by GitLab:
    # https://github.com/gitlabhq/gitlabhq/blob/master/config/unicorn.rb.example
    worker_processes ENV['WORKER_PROCESSES'].to_i
    listen ENV['LISTEN_ON']
    timeout 30
    preload_app true
    GC.respond_to?(:copy_on_write_friendly=) && GC.copy_on_write_friendly = true
    check_client_connection false
    before_fork do |server, worker|
      defined?(ActiveRecord::Base) && ActiveRecord::Base.connection.disconnect!
      old_pid = "#{server.config[:pid]}.oldbin"
      if old_pid != server.pid
          sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
          Process.kill(sig, File.read(old_pid).to_i)
        rescue Errno::ENOENT, Errno::ESRCH
    after_fork do |server, worker|
      defined?(ActiveRecord::Base) && ActiveRecord::Base.establish_connection

    Creating the Sidekiq Initialize Config

    Now you can also create the config/initializers/sidekiq.rb file and add the following code to it:

    sidekiq_config = { url: ENV['JOB_WORKER_URL'] }
    Sidekiq.configure_server do |config|
      config.redis = sidekiq_config
    Sidekiq.configure_client do |config|
      config.redis = sidekiq_config

    Whitelist Docker Host

    Rails have a security features that blocks access from unknown sources. We want our different docker containers to communicate with each other, so we need to whitelist the drkiq container.

    Edit the config/environment/development.rb file and add the following line:

    config.hosts << "drkiq"

    Creating the Environment Variable File

    Last but not least, you need to create an environment file. Go to the top directory of your project, and create a new file next to your Dockerfile.rails file:

    $ cd ..
    $ touch env-example

    The contents of the example environment are:

    # You would typically use rake secret to generate a secure token. It is
    # critical that you keep this value private in production.

    Copy the example file and customize it to your liking. The SECRET_TOKEN should be a random string. The final .env file is secret and should never be checked into git:

    $ cp env-example .env
    $ echo ".env" >> .gitignore

    The above file allows us to configure the application without having to dive into the application code.

    This file would also hold information like mail login credentials or API keys.

    Dockerizing Your Rails Application

    Create the Dockerfile file and add the following content to it:

    # Dockerfile development version
    FROM ruby:3.1.2 AS drkiq-development
    # Install yarn
    RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg -o /root/yarn-pubkey.gpg && apt-key add /root/yarn-pubkey.gpg
    RUN echo "deb https://dl.yarnpkg.com/debian/ stable main" > /etc/apt/sources.list.d/yarn.list
    RUN apt-get update && apt-get install -y --no-install-recommends nodejs yarn
    # Default directory
    ENV INSTALL_PATH /opt/app
    RUN mkdir -p $INSTALL_PATH
    # Install gems
    COPY drkiq/ .
    RUN rm -rf node_modules vendor
    RUN gem install rails bundler
    RUN bundle install
    RUN yarn install
    # Start server
    CMD bundle exec unicorn -c config/unicorn.rb

    The above file creates the Docker image with:

    • Node and Yarn
    • Rails
    • Gems in the Gemfile

    The last part of the Dockerfile sets the correct user and file permissions and starts the unicorn HTTP server.

    Configuring Ngnix

    While unicorn is perfectly capable of serving our application, for better performance and security, it’s recommended to put a real HTTP server in front. An HTTP server configured as a reverse-proxy protects our application from slow clients and speeds up connections thanks to caching.

    We’ll use Nginx, a general-purpose HTTP server in our setup.

    Create a configuration file for Ngnix, the file is called reverse-proxy.conf and is at the root directory of your project, next to the other Dockefiles:

    # reverse-proxy.conf
    server {
        listen 8020;
        server_name example.org;
        location / {
            proxy_pass http://drkiq:8010;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    Create a new file called Dockerfile.nginx to build our custom Nginx image:

    # Dockerfile.nginx
    FROM nginx:latest
    COPY reverse-proxy.conf /etc/nginx/conf.d/reverse-proxy.conf
    EXPOSE 8020
    CMD ["nginx", "-g", "daemon off;"]

    Creating a dockerignore File

    Next, create the .dockerignore file and add the following content to it:


    This file is similar to .gitgnore. It will exclude matching files and folders from being built into your Docker image.

    What is Docker Compose?

    Docker Compose allows you to run 1 or more Docker containers easily. You can define everything in YAML and commit this file so that other developers can simply run docker-compose up and have everything running quickly.

    Creating the Docker Compose Configuration File

    Next, we will create the docker-compose.yml file and copy the following content into it:

    version: "3.9"
        image: postgres:14.2
          POSTGRES_USER: drkiq
          POSTGRES_PASSWORD: test_db_password
          - '5432:5432'
          - drkiq-postgres:/var/lib/postgresql/data
        image: redis:7.0
          - '6379:6379'
          - drkiq-redis:/var/lib/redis/data
          context: .
          - ./drkiq:/opt/app
          - postgres
          - redis
          - '8010:8010'
          - .env
          context: .
        command: bundle exec sidekiq 
          - postgres
          - redis
          - .env
          context: .
          dockerfile: ./Dockerfile.nginx
          - drkiq
          - '8020:8020'

    Everything in the above file is documented on Docker Compose‘s website. The short version is:

    • Postgres and Redis use Docker volumes to manage persistence
    • Postgres, Redis and Drkiq all expose a port
    • Drkiq and Sidekiq both have links to Postgres and Redis.
    • Drkiq and Sidekiq both read in environment variables from .env
    • Sidekiq overwrites the default CMD to run Sidekiq instead of Unicorn.

    Creating the Volumes

    In the docker-compose.yml file, we’re referencing volumes that do not exist. We can create them by running:

    $ docker volume create --name drkiq-postgres
    $ docker volume create --name drkiq-redis

    When data is saved in PostgreSQL or Redis, it is saved to these volumes on your work station. This way, you won’t lose your data when you restart the service because Docker containers are stateless.

    Running Everything

    Now it’s time to put everything together and start-up our stack by running the following:

    $ docker compose up --build

    The first time this command runs it will take quite a while because it needs to pull down all of the Docker images that our application requires.

    This operation is mostly bound by network speed, so your times may vary.

    At some point, it’s going to begin building the Rails application. You will eventually see the terminal output, including lines similar to these:

    postgres_1  | ...
    redis_1     | ...
    drkiq_1     | ...
    sidekiq_1   | ...
    nginx_1     | ...

    You will notice that the drkiq_1 container threw an error saying the database doesn’t exist. This is a completely normal error to expect when running a Rails application because we haven’t initialized the database yet.

    Initialize the Database

    Hit CTRL+C in the terminal to stop everything. If you see any errors, you can safely ignore them.

    Run the following commands to initialize the database:

    $ docker­ compose run drkiq rake db:reset
    $ docker­ compose run drkiq rake db:migrate

    The first command should warn you that db/schema.rb doesn’t exist yet, which is normal. Run the second command to remedy that. It should run successfully.

    If you head over to the db folder in your project, you should notice that there is a schema.rb file and that it’s owned by your user.

    You may also have noticed that running either of the commands above also started Redis and PostgreSQL automatically. This is because we have them defined as links. docker-compose is smart enough to start dependencies.

    Running Everything, Round 2

    Now that our database is initialized, try running the following:

    $ docker compose up

    Testing It Out

    Head over to http://localhost:8020

    You should be greeted with the typical Rails introduction page.

    Working with the Rails Application

    Now that we’ve Dockerized our application, let’s start adding features to it to exercise the commands you’ll need to run to interact with your Rails application.

    Right now the source code is on your work station, and that source code is being mounted into the Docker container in real-time through a volume.

    This means that if you were to edit a file, the changes would take effect instantly, but right now we have no routes or any CSS defined to test this.

    Generating a Controller

    Run the following command to generate a Pages controller with a home action:

    docker compose run drkiq rails g controller Pages home

    In a second or two, it should provide everything you would expect when generating a new controller.

    This type of command is how you’ll run future Rails commands. If you wanted to generate a model or run a migration, you would run them in the same way.

    Modify the Routes File

    Remove the get 'pages/home' line near the top of config/routes.rb and replace it with the following:

    root 'pages#home'

    If you go back to your browser, you should see the new home page we have set up.

    Adding a New Job

    Use the following to add a new job:

    docker compose run drkiq rails g job counter

    Modifying the Counter Job

    Next, replace the perform function in app/job/counter_job.rb to look like this:

    def perform(*args)
      21 + 21

    Modifying the Pages Controller

    Replace the home action in app/controllers/pages_controller.rb to look like this:

    def home
      @meaning_of_life = CounterJob.perform_now

    Modifying the Home View

    The next step is to replace the app/views/pages/home.html.erb file to look as follows:

    <h1>The meaning of life is <%= @meaning_of_life %></h1>

    Restart the Rails Application

    You need to restart the Rails server to pick up new jobs, so hit CTRL+C to stop everything, and then run docker compose up again.

    If you reload the website you should see the changes we made.

    Experimenting on Your Own

    Here are three things you should do to familiarize yourself with your new application:

    • Changing the h1 color to something other than black
    • Generating a model and then running a migration
    • Adding a new action and route to the application

    All of these things can be done without having to restart anything, so feel free to check out the changes after you have performed each one.

    Adding Some Tests

    We can add some testing code to our application. Having tests will help us detect failures and weed out bugs.

    Rails will search for test files in the test directory.

    Create a test for the CounterJob job. Create a file called test/job/counter_job_test.rb:

    require 'test_helper'
    class CounterJobTest < ActiveJob::TestCase
      test "returns 42" do
         assert_equal 42, CounterJob.perform_now

    Let’s add a second test for the Pages controller. Create a file called test/controllers/pages_controller_test.rb:

    require 'test_helper'
    class PagesControllerTest < ActionDispatch::IntegrationTest
      test "should get home" do
        get "/"
        assert_response :success

    Before running the tests, create a test database:

    $ docker compose run drkiq rake db:test:prepare

    To run the tests, execute:

    $ docker compose run drkiq rails test
    Finished in 4.850950s, 0.4123 runs/s, 0.4123 assertions/s.
    2 runs, 2 assertions, 0 failures, 0 errors, 0 skips

    Before continuing, ensure that all your code is checked in GitHub:

    $ git add -A 
    $ git commit -m "initial commit"
    $ git push origin master

    Continuous Integration for dockerizing Ruby

    With the help of Docker, we created a portable environment that we can share with other developers. In this section, we’ll learn how we can build Docker images to deploy to production.

    Continuous Integration (CI) is a software development practice that creates a strong feedback loop that encircles coding and testing. When we make a modification to the code, the CI system picks it up and runs it through a CI Pipeline. The pipeline builds and tests the code and we get an immediate result.


    We’ll need additional services to build and test the Docker images in a scalable way:

    • Docker Hub: create a free account using the Get Started button. Docker Hub provides unlimited public repositories for free.
    • Semaphore: head to Semaphore and sign up using the Sign up with GitHub button. Use your GitHub account to log in.

    Next, we have to tell Semaphore how to connect with your Docker Hub account:

    1. Go to your Semaphore account menu and select Settings
    1. Click on Secrets and then Create New Secret.
    2. Create a secret called “dockerhub” with the following details:
      • DOCKER_USERNAME: your Docker Hub username.
      • DOCKER_PASSWORD: type your Docker Hub password.
    1. Click on Save Secret.

    Production Images

    Our Docker images work very well for development but are not suitable for production. For one thing, our images are not portable, they don’t contain our application code.

    We’ll create new images that are independent and can be deployed anywhere.

    Create a file called Dockerfile.production with the following contents:

    # Dockerfile CI version
    FROM registry.semaphoreci.com/ruby:3.1
    # Default directory
    ENV INSTALL_PATH /opt/app
    RUN mkdir -p $INSTALL_PATH
    # Install Nodejs
    RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg -o /root/yarn-pubkey.gpg && apt-key add /root/yarn-pubkey.gpg
    RUN echo "deb https://dl.yarnpkg.com/debian/ stable main" > /etc/apt/sources.list.d/yarn.list
    RUN apt-get update && apt-get install -y --no-install-recommends nodejs yarn
    ENV INSTALL_PATH /opt/app
    RUN mkdir -p $INSTALL_PATH
    # Install gems
    COPY drkiq/ .
    RUN rm -rf node_modules vendor
    RUN gem install rails bundler
    RUN bundle install
    RUN yarn install
    CMD bundle exec unicorn -c config/unicorn.rb

    If you compare the development and production Dockerfiles, you’ll find that the main difference is that we’re pulling the Ruby image from registry.semaphoreci.com, a container registry provided by Semaphore which is faster than Docker Hub and which doesn’t count against your Docker download limits.

    Push the new Dockerfile to GitHub:

    $ git add Dockerfile.production
    $ git commit -m "add dockerfile"
    $ git push origin master

    Continuous Integration Pipeline

    You can set up a CI pipeline with a few clicks:

    • Open your Semaphore account.
    • On the left navigation menu, click on the + (plus sign) next to Projects:
    • Find your repository and click on Choose:
    • Select the Docker starter workflow. Click on Customize it first:

    Click on Continue to workflow setup. If prompted, choose I want to configure the pipeline from scratch.

    The Workflow Builder main components are:

    • Pipeline: A pipeline has a specific objective, e.g. building. Pipelines are made of blocks that are executed from left to right in an agent.
    • Agent: The agent is the virtual machine that powers the pipeline. We have three machine types to choose from. The machine runs an optimized Ubuntu 18.04 image with build tools for many languages.
    • Block: blocks group jobs that can be executed in parallel. Jobs in a block usually have similar commands and configurations. Once all jobs in a block complete, the next block begins.
    • Job: jobs define the commands that do the work. They inherit their configuration from their parent block.

    Build Block

    The build stage creates our Docker images:

    • Click on the Build block.
    • Open the Secrets section and check the dockerhub item. This will import your Docker Hub credentials to all job in the block.
    • Open the Prologue section and type the following commands in the box:
    echo "${DOCKER_PASSWORD}" | docker login -u "${DOCKER_USERNAME}" --password-stdin
    • Click on the build job, rename it to “Build drkiq”.
    • Type the following commands in the box:
    docker pull $DOCKER_USERNAME/dockerizing-ruby-drkiq:latest || true
    docker build -t $DOCKER_USERNAME/dockerizing-ruby-drkiq:latest --cache-from=$DOCKER_USERNAME/dockerizing-ruby-drkiq:latest -f Dockerfile.production .
    docker push $DOCKER_USERNAME/dockerizing-ruby-drkiq:latest

    Already, we’re learning so much about how a Pipeline works:

    • Prologue: the prologue is executed before each job in the block. Typically, it holds common set up commands.
    • Checkout: checkout clones the GitHub repository into the CI environment.
    • Docker login: connects the CI environment with your Docker Hub account.
    • Docker Pull/Push: copies the image from and to Docker Hub. Before building, we copy the last image so we can benefit from Docker’s cache optimization.

    To run the pipeline:

    • Click on Run the Workflow button.
    • Set the branch to master.
    • Click on Start.
    • The pipeline starts immediately:
    Building the main docker image

    When complete, head over your Docker Hub account, you should see a brand new image called dockerizing-ruby-drkiq:

    New image uploaded to repository

    Build Block Revisited

    We’ll modify the build block to create the Nginx image:

    • Click on Edit Workflow on the top-right corner.
    • Click on the Build block.
    • Click on + Add another job:
    The docker build job
    • Set the name of the job to “Build nginx”.
    • Type the following commands in the box:
    docker pull $DOCKER_USERNAME/dockerizing-ruby-nginx:latest || true
    docker build -t $DOCKER_USERNAME/dockerizing-ruby-nginx:latest --cache-from=$DOCKER_USERNAME/dockerizing-ruby-nginx:latest -f Dockerfile.nginx .
    docker push $DOCKER_USERNAME/dockerizing-ruby-nginx:latest
    • Click on Run the Workflow and Start.

    This time the pipeline builds our two images:

    Dockerizing jobs

    Running Tests

    A CI pipeline wouldn’t be complete without tests. We’ll add a test job to check that the images are working.

    The test block will:

    • Pull the images built in the previous block
    • Create the docker volumes
    • Initialize the database
    • Run the Rails tests using Docker Compose.

    First, lets create a testing only Docker Compose file called docker-compose.test.yml:

    version: "3.9"
        image: postgres:14.2
          POSTGRES_USER: drkiq
          POSTGRES_PASSWORD: test_db_password
          - '5432:5432'
          - drkiq-postgres:/var/lib/postgresql/data
        image: redis:7.0
          - '6379:6379'
          - drkiq-redis:/var/lib/redis/data
        image: $DOCKER_USERNAME/dockerizing-ruby-drkiq:latest
          - postgres
          - redis
          - '8010:8010'
          - .env
        image: $DOCKER_USERNAME/dockerizing-ruby-drkiq:latest
        command: bundle exec sidekiq 
          - postgres
          - redis
          - .env
        image: $DOCKER_USERNAME/dockerizing-ruby-nginx:latest
          - drkiq
          - '8020:8020'

    The development and test compose files are pretty similar. The only difference is that, in test we reference the image by name, we don’t build the image. We do this because we want to test the images that were uploaded to DockerHub, we don’t want to build new ones.

    Push the new file to GitHub:

    $ git pull origin master
    $ git add docker-compose.test.yml
    $ git commit -m "add test docker compose"
    $ git push  origin master

    To add a test block:

    • On Semaphore, click on Edit Workflow.
    • Click on the + Add Block dotted box to create a new block.
    • Set the name of the block to “Tests”
    • Open the Prologue section and type the following commands. The prologue holds the initialization commands we used earlier:
    cp env-example .env
    cat docker-compose.test.yml | envsubst | tee docker-compose.yml
    echo "${DOCKER_PASSWORD}" | docker login -u "${DOCKER_USERNAME}" --password-stdin
    docker pull $DOCKER_USERNAME/dockerizing-ruby-drkiq:latest || true
    docker-compose run drkiq rake db:reset
    docker-compose run drkiq rake db:migrate
    docker-compose run drkiq rake db:test:prepare
    • Open the Secrets section and check the dockerhub item.
    • Change the name of the job to “Rails Test”.
    • Type the following command in the job’s box:
    docker-compose run drkiq rails test
    Running tests on CI
    • Use the Run the Workflow and Start buttons.

    After a few seconds we should have the images tested:

    Dockerizing Ruby Pipeline

    Where to go next?

    Congratulations! You’ve finished dockerizing your Ruby on Rails application.

    Dockerizing your application is the first step towards portable and easy deployments. There are many ways of running your dockerized applications:

    • Hosted: if you have a server or a virtual machine, you can use Docker Compose to run your application.
    • PaaS: you can use a Platform as a Service such as Heroku to run your Docker containers. Check the tutorials below for more information.
    • Kubernetes: you can run your containers using an orchestration platform like Kubernetes. Kubernetes provides scalability, great flexibility and no-downtime upgrades. For more information check the tutorials below and read the Docker and Kubernetes introduction page.

    To learn how to deploy to Kubernetes check these tutorials:

    To learn about how to deploy to Heroku:

    9 thoughts on “Dockerizing a Ruby on Rails Application

    1. This is an awesome tutorial. I can now have my Ruby on Rails development environment dockerised! Thank you! 👏👏👏

    2. Sir can I try this in my windows machine?? Plz tell me. Is it will run in windows?
      Waiting for your response sir.
      Thank you

    3. That is a great topic. I just the whole thing using docker desktop with WSL on windows 11 machine and adding React commands to main rails Dockerfile
      gem ‘webpacker’
      RUN /bin/rails webpacker:install
      RUN /bin/rails webpacker:install:react

      with a style file in app/assets/stylesheets an error is raised:
      undefined method `silence’ for #
      I found an answer here
      It suggests replacing
      config.logger = ActiveSupport::TaggedLogging.new(Logger.new(STDOUT))

      config.logger = ActiveSupport::TaggedLogging.new(ActiveSupport::Logger.new(STDOUT))

      so that Logger get exposed through ActiveSupport to avoid this bug.

    4. In regards to running rails commands (such as bundle install), is it better to comment out the following in docker-compose.yml:
      – ./drkiq:/opt/app

      For example, if I install a new gem, the gem will not be installed locally

    5. For me the build block in SemaphoreCI kept failing due to a ruby version issue. I had Rails version: 7.0.4, and Ruby 3.1.2. The error said that Ruby 3.1.3 was being used, but my application specified 3.1.2.

      For the block to finally work, I had to remove the ruby version line in my gemfile, namely, “ruby 3.1.2”, and change “ruby-3.1.2” to “ruby-3.1.3” in the .ruby-version file. After that, the build was successful.

    6. For some reason, I started to get an error when running this command (in development):
      docker compose run drkiq rake db:migrate
      (The error arose the second time I came back to reset the database and then run the migrate command)

      If anyone comes across this, I found an alternative command to bypass the error:
      docker compose run drkiq bundle exec rails db:migrate

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Writen by:
    Hi, my name is Nick. I really enjoy working on open source projects and creating on-line courses to teach students what I've learned over the years while working as a consultant.
    Reviewed by:
    I picked up most of my skills during the years I worked at IBM. Was a DBA, developer, and cloud engineer for a time. After that, I went into freelancing, where I found the passion for writing. Now, I'm a full-time writer at Semaphore.