Dockerize a Rails App with MySQL and Sidekiq

Dockerising an application is creating an isolated environment with containers for different moving parts in an application which makes the development and deployment easier and you don’t have to repeat yourself everytime when you need to deploy it locally for development or in production. It’s one command away and it’s that’s easy when you dockerize it. Dockerising is fun and tricky in the beginning when you define volumes for containers and working out an architecture that’ll suit your application. Okay, let’s just stop the talking and dive right into it. I’ll first start with the introduction to Docker and what you’ll need to dockerize an application. I take up a Rails App for this blog post but you can dockerize literally anything.

The prerequisites are to install Docker and make sure it’s running. Install Ruby & Rails. Don’t worry we’re not gonna deal with ruby.

”Hey, Docker. Who are you?”

I’m not gonna describe it to you. I’ll ask Docker to do that part. It’ll be so good if he does that by himself. So here he is.

“Hey! I’m a tool designed to make it easier to create, deploy, and run applications by using containers. A container is a part of me. A container is a standard unit of software that packages up the code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries, and settings. By doing so, thanks to my container, you can rest assured that the application will run on any other Linux machine regardless of any customized settings that machine might have that could differ from the machine used for writing and testing the code. The important thing to note is that I’m Open source and you can contribute to making me better. See how awesome I’m! :D”

So, how was his introduction? Okay, Let’s move to the other aspects in detail. Let’s talk about Docker images and Containers.

Volumes, Docker Images & Containers

Volumes are the preferred mechanism for persisting data generated by and used by Docker containers. While bind mounts are dependent on the directory structure of the host machine, volumes are completely managed by Docker.

Docker containers are based on Docker images. A Docker image is a binary that includes all of the requirements for running a single Docker container, as well as metadata describing its needs and capabilities. You can think of it as a packaging technology. Docker containers only have access to resources defined in the image, unless you give the container additional access when creating it.

Dockerfile and docker-compose.yml

A Dockerfile is used to build an image. A Compose file is used to deploy a container from an image.

If you’re using a public image, such as Nginx or MySQL, then there’s no need for a Dockerfile since you don’t need to build it yourself - it’s already built and accessible via Docker Hub, so your Compose file can just pull it from there.

You usually don’t need a Dockerfile unless you’re creating a custom container image from scratch, or customizing a public image for some reason.

So, we’ll need Dockerfile to build our custom images for the web-app, sidekiq for our ruby application. Since we have pre-built images for MySQL, Ruby, and Redis, we’ll just pull the image from Docker Hub. We’ll talk in detail about everything.

We’re half-way through and let’s get started in dockerizing a rails application.

rails new app_name

As we discussed earlier, we’ll work on a rails application. Let’s create a new application with the command rails new rails-mysql-docker where rails-mysql-docker is the name of the project. This will create a scaffold and once it’s complete, open the folder in a code editor. Now, let’s get the basics done. We’ll install the MySQL gem as we’ll be using MySQL as the database and sidekiq for background processing. At the later point of the blog, we’ll talk about sidekiq. Now, add the required gems to the Gemfile and run bundle install in the command line.

Now, I assume that you’ve installed Docker on your computer and made sure that it’s up and running. We now created a rails app and installed mysql gem in it.

”It’s Docker Time!!”

We’ll now be writing the Dockerfile and the docker-compose.yml file. As I said previously, A Dockerfile is used to build an image. A Compose file is used to deploy a container from an image. We’ll first write the Dockerfile. The Dockerfile contains commands that need to be executed while building the image. That may include system libraries and other stuff. Create a file named Dockerfile at the root of the project and add the following to it.

1
FROM ruby:2.5-alpine
2

3
RUN apk update && apk upgrade && apk add ruby ruby-json ruby-io-console ruby-bundler ruby-irb ruby-bigdecimal tzdata postgresql-dev && apk add nodejs && apk add curl-dev ruby-dev build-base libffi-dev && apk add build-base libxslt-dev libxml2-dev ruby-rdoc mysql-dev sqlite-dev
4

5
RUN mkdir /app
6
WORKDIR /app
7

8
COPY Gemfile Gemfile.lock ./
9
RUN gem install ovirt-engine-sdk -v '4.3.0' --source 'https://rubygems.org/'
10
RUN bundle install --binstubs
11

12
COPY . .
13

14
EXPOSE 3000
15

16
ENTRYPOINT ["sh", "./config/docker/startup.sh"]

The above Dockerfile contains some commands that are run to build a Docker image. We’ll now break out the above docker file.

1
FROM ruby:2.5-alpine

We’re asking it to use the base image ruby for the 2.5-alpine distribution.

1
RUN apk update && apk upgrade && \
2
apk add ruby ruby-json ruby-io-console ruby-bundler ruby-irb ruby-bigdecimal tzdata && \
3
apk add nodejs && \
4
apk add curl-dev ruby-dev build-base libffi-dev && \
5
apk add build-base libxslt-dev libxml2-dev ruby-rdoc mysql-dev sqlite-dev

This will install the required system libraries. The above has some extra libraries which are not quite needed for a small rails application.

1
RUN mkdir /app
2
WORKDIR /app

We now run a mkdir command which is used to create a new directory. The WORKDIR line specifies a new default directory within the image’s file system which is the app directory.

1
COPY Gemfile Gemfile.lock ./
2

3
RUN bundle install --binstubs
4

5
COPY . .

Now, copy the Gemfile, lock file and the current directory and run bundle install. When you use COPY it will copy the files from the local source, in this case . meaning the files in the current directory, to the location defined by WORKDIR. In the above example, the second. refers to the current directory in the working directory within the image.

1
EXPOSE 3000
2

3
ENTRYPOINT ["sh", "./config/docker/startup.sh"]

This will export the port 3000 and run a startup.sh shell script. We use some shell scripts to build the application. We’ll talk about it more in some time.

An ENTRYPOINT allows you to configure a container that will run as an executable. In our case, it will run startup.sh that will build our app.

We also don’t want unwanted files inside a container. Take git tracking for example. We don’t need it to run our app. Thus, it is not needed. So, we create a .dockerignore file that contains the following,

1
.dockerignore
2
.git
3
logs/
4
tmp/

docker-compose.yml

The Compose file is a YAML file which defines services, networks, and volumes. It usually helps us defining the containers and, volumes with ENV variables. We’ll break out every container.

1
version: "3.7"
2
services:
3
 db:
4
   image: "mysql:5.7"
5
   environment:
6
     MYSQL_ROOT_PASSWORD: root
7
     MYSQL_USERNAME: root
8
     MYSQL_PASSWORD: root
9
   ports:
10
      - "3307:3306"
11
 redis:
12
   image: "redis:4.0-alpine"
13
   command: redis-server
14
   volumes:
15
      - "redis:/data"
16

17
 website:
18
   depends_on:
19
      - "db"
20
      - "redis"
21
   build: .
22
   ports:
23
      - "3000:3000"
24
   environment:
25
     DB_USERNAME: root
26
     DB_PASSWORD: root
27
     DB_DATABASE: sample
28
     DB_PORT: 3306
29
     DB_HOST: db
30
     RAILS_ENV: production
31
     RAILS_MAX_THREADS: 5
32
   volumes:
33
      - ".:/app"
34
      - "./config/docker/database.yml:/app/config/database.yml"
35

36
 sidekiq:
37
   depends_on:
38
      - "db"
39
      - "redis"
40
   build: .
41
   command: sidekiq -C config/sidekiq.yml
42
   volumes:
43
      - ".:/app"
44
   environment:
45
     REDIS_URL: redis://redis:6379/0
46

47
volumes:
48
 redis:
49
 db:

“Breaking it up is better than breakup”. Ok, I get it. It’s so dumb. Now we’ll break out our docker-compose.yml.

In the docker-compose.yml file, the version depends on the docker release. There is a table in the docker documentation that maps different version with their respective docker releases. The services are what that makes up your application. It consists of all the services that will be built as different containers that act as the organs of your application. We’ll have about 4 services namely - db, redis, website, sidekiq.

1
db:
2
  image: "mysql:5.7"
3
  environment:
4
    MYSQL_ROOT_PASSWORD: root
5
    MYSQL_USERNAME: root
6
    MYSQL_PASSWORD: root
7
  ports:
8
    - "3307:3306"

This container is for installing our MySQL and running it as a container. We pull an already built image mysql:5.7 from docker hub. We also pass the required environment variables. Ports mentioned in docker-compose.yml will be shared among different services started by the docker-compose. Ports will be exposed to the host machine to a random port or a given port.

1
redis:
2
  image: "redis:4.0-alpine"
3
  command: redis-server
4
  volumes:
5
    - "redis:/data"

Same as MySql, we pull a redis image from docker hub. Compose includes the ability to attach volumes to any service that has persistent storage requirements. We’ll have volumes to contain our persistent data like the above. The command will run after the container is built. Docker will create the volume for you in the /var/lib/docker/volumes folder. This volume persists as long as you are not typing docker-compose down -v.

1
website:
2
  depends_on:
3
    - "db"
4
    - "redis"
5
  build: .
6
  ports:
7
    - "3000:3000"
8
  environment:
9
    DB_USERNAME: root
10
    DB_PASSWORD: root
11
    DB_DATABASE: sample
12
    DB_PORT: 3306
13
    DB_HOST: db
14
    RAILS_ENV: production
15
    RAILS_MAX_THREADS: 5
16
  volumes:
17
    - ".:/app"
18
    - "./config/docker/database.yml:/app/config/database.yml"

The website service is where our rails application resides. docker-compose up will start services in dependency order as defined with depends_on. In the following example, db and redis will be started before the website. The build key tells to build with the docker-compose.yml present in the current directory.

1
sidekiq:
2
  depends_on:
3
    - "db"
4
    - "redis"
5
  build: .
6
  command: sidekiq -C config/sidekiq.yml
7
  volumes:
8
    - ".:/app"
9
  environment:
10
    REDIS_URL: redis://redis:6379/0

Sidekiq is a simple, efficient background processing for Ruby. Sidekiq uses threads to handle many jobs in the same process simultaneously. It does not require Rails but will integrate tightly with Rails to make background processing dead simple. A rails app will definitely need redis and sidekiq for background processing.

Docker Utility Folder

We’ll have a docker utility folder inside config that’ll contain a database.yml which will be later mounted into the config folder that’ll be used by the application. We’ll have four shell scripts.

startup.sh

If you remember the Dockerfile (If not, you can scroll back though :p), we would’ve referred startup.sh in our ENTRYPOINT. Yes, you guessed it right. We’re nearly at the end of the tutorial.

1
#! /bin/sh
2

3
# Wait for DB services
4
sh ./config/docker/wait-for-services.sh
5

6
# Prepare DB (Migrate - If not? Create db & Migrate)
7
sh ./config/docker/prepare-db.sh
8

9
# Pre-comple app assets
10
sh ./config/docker/asset-pre-compile.sh
11

12
# Start Application
13
bundle exec puma -C config/puma.rb

This script will run three more scripts and starts our application. We’ll discuss that below.

wait-for-services.sh

This script polls and waits for the MySQL to be up and running with the help of the host and the port it is running.

1
#! /bin/sh
2

3
# Wait for MySQL
4
until nc -z -v -w30 $DB_HOST $DB_PORT; do
5
 echo 'Waiting for MySQL...'
6
 sleep 1
7
done
8
echo "MySQL is up and running!"

prepare-db.sh

This script handles the database migrations for the application. It’ll create the database and migrate if the migrations failed in the first try.

1
#! /bin/sh
2

3
# If the database exists, migrate. Otherwise setup (create and migrate)
4
bundle exec rake db:migrate 2>/dev/null || bundle exec rake db:create db:migrate
5
echo "Done!"

asset-pre-compile.sh

We use rake assets:precompile to precompile our assets before pushing code to production. This command precompiles assets and places them under the public/assets directory in our Rails application.

1
#! /bin/sh
2

3
# Precompile assets for production
4
bundle exec rake assets:precompile
5

6
echo "Assets Pre-compiled!"

database.yml

As said before we’ll have the database configurations in our docker folder which will then be mounted into the config folder that’ll be then used by the rails application.

1
default: &default
2
 adapter: mysql2
3
 encoding: utf8mb4
4
 collation: utf8mb4_bin
5
 reconnect: false
6
 pool: 50
7
 username: <%= ENV['DB_USERNAME'] %>
8
 password: <%= ENV['DB_PASSWORD'] %>
9
 port: <%= ENV['DB_PORT'] %>
10
 host: <%= ENV['DB_HOST'] %>
11
 socket: /var/run/mysqld/mysqlx.sock
12

13
development:
14
 <<: *default
15
 database: <%= ENV['DB_DATABASE'] %>_development
16

17
production:
18
 <<: *default
19
 database: <%= ENV['DB_DATABASE'] %>

#ItsDone

Now, all we need to do is run docker-compose up -d. The -d is Detached mode which will run the containers in the background. The app will be built with all the containers and you can view the containers with docker ps -a. You can also find the GitHub Repo or follow me on Twitter for some retweet spam. In my next article, we’ll talk about CI/CD with Jenkins . Until next time, have this Gif for free.