Using Docker Compose for Ruby Development
Tags: ruby, docker, development
Published: 2017-06-12 23:52:13

---
title: "Using Docker Compose for Ruby Development"
published: true
description: To provide an example of how you might move to containerized development, I built a simple todo API with Ruby on Rails and PostgreSQL using Docker Compose for development, testing, and eventually in my CI/CD pipeline.
tags: ruby, docker, development
cover_image: https://1npo9l3lml0zvr6w62acc3t1-wpengine.netdna-ssl.com/wp-content/uploads/2017/05/Heading_Using-Docker-Compose-for-Ruby-Development.jpg
---

> This post was originally published on the [Codeship Blog](https://blog.codeship.com/using-docker-compose-for-ruby-development/) and is posted here with the author's permission.

Docker is an amazing tool for developers. It allows us to build and replicate images on any host, removing the inconsistencies of dev environments and reducing onboarding timelines considerably.

To provide an example of how you might move to containerized development, I built a simple `todo` API with Ruby on Rails and PostgreSQL using [Docker Compose](https://docs.docker.com/compose/) for development, testing, and eventually in my CI/CD pipeline.

In a two-part series, I will cover the development and pipeline creation steps. In this post, I will cover the first part: developing and testing with Docker Compose.

## Requirements for This Tutorial

This tutorial requires you to have a few items before you can get started.

*   Install [Docker Community Edition](https://store.docker.com/search?type=edition&offering=community)
*   Install [Docker Compose](https://docs.docker.com/compose/install/)
*   Download [Todo app example - Non- Docker branch](https://github.com/codeship-library/ruby-rails-todoapp/archive/non-docker.zip)

The todo app here is essentially a stand-in, and you could replace it with your own application. Some of the setup here is specific for this application, and the needs of your application may not be covered, but it should be a good starting point for you to get the concepts needed to Dockerize your own applications.

Once you have everything set up, you can move on to the next section.

## Creating the Dockerfile

At the foundation of any Dockerized application, you will find a [`Dockerfile`](https://docs.docker.com/engine/reference/builder/). The `Dockerfile` contains all of the instructions used to build out the application image. You can set this up by installing Ruby and all of its dependencies. However, the Docker ecosystem has an image repository with a [Ruby](https://store.docker.com/images/0f900dcb-7e32-45e4-b095-6dfa2f5b597b?tab=description) image already created and ready to use.

In the root directory of the application, create a new `Dockerfile`.

```bash
/> touch Dockerfile
```

Open the newly created `Dockerfile` in your favorite editor. The first instruction, [`FROM`](https://docs.docker.com/engine/reference/builder/#from), will tell Docker to use the prebuilt Ruby image. There are several choices, but this project uses the `ruby:2.4.0-alpine` image. For more details about why I'm using `alpine` here over the other options, you can read [this post](https://blog.codeship.com/alpine-based-docker-images-make-difference-real-world-apps/).

```bash
FROM ruby:2.4.0-alpine
```

If you run `docker build .`, you will see something similar to the following:

```bash
Step 1/1 : FROM ruby:2.4.0-alpine
2.4.0-alpine: Pulling from library/ruby
709515475419: Pull complete
7fb3cefb04d0: Pull complete
c05571fbf599: Pull complete
02f8fc71784d: Pull complete
f419b347345c: Pull complete
Digest: sha256:49cd3c5e577ff2898fa7ff82271f4ccf1054d12adc7f7a6595da87b35f9f3972
Status: Downloaded newer image for ruby:2.4.0-alpine
 ---> 18dbdfdbe6bd
Successfully built 18dbdfdbe6bd
```

With only one instruction in the Dockerfile, this doesn't do too much, but it does show you the build process without too much happening. At this point, you now have an image created, and running `docker images` will show you the images you have available:

```bash
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ruby                2.4.0-alpine        18dbdfdbe6bd        5 weeks ago         60.8 MB
```

The `Dockerfile` needs more instructions to build out the application. Currently it’s only creating an image with Ruby installed, but we still need our application code to run inside the container. Let's add some more instructions to do this and build this image again.

This particular Docker file uses [`RUN`](https://docs.docker.com/engine/reference/builder/#run), [`COPY`](https://docs.docker.com/engine/reference/builder/#copy), and [`WORKDIR`](https://docs.docker.com/engine/reference/builder/#workdir). You can read more about those on Docker's reference page to get a deeper understanding.

Let's add the instructions to the `Dockerfile` now:

```bash
FROM ruby:2.4.0-alpine

RUN apk update && apk add nodejs build-base libxml2-dev libxslt-dev postgresql postgresql-dev
RUN mkdir /app
WORKDIR /app

COPY Gemfile ./Gemfile
COPY Gemfile.lock ./Gemfile.lock

RUN bundle install -j 20
COPY . .
```

Here is what is happening:

*   Update `apk` packages and then install a few additional requirements for Rails
*   Make the directory `/app`
*   Set the working directory to `/app`
*   Copy `Gemfile` and `Gemfile.lock`
*   Run bundle install with 20 concurrent workers
*   Copy all the files from the project's root to `/app`

You can now run `docker build .` again and see the results:

```bash
Sending build context to Docker daemon 284.7 kB
Step 1/8 : FROM ruby:2.4.0-alpine
 ---> 18dbdfdbe6bd
Step 2/8 : RUN apk update && apk add nodejs build-base libxml2-dev libxslt-dev postgresql postgresql-dev
 ---> Running in 4b3fb288b182
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
v3.4.6-109-g6ab23d6 [http://dl-cdn.alpinelinux.org/alpine/v3.4/main]
v3.4.6-83-g67e50bc [http://dl-cdn.alpinelinux.org/alpine/v3.4/community]
OK: 5973 distinct packages available

## APK packages installed ##

Executing busybox-1.24.2-r13.trigger
OK: 221 MiB in 60 packages
 ---> 3c6e4955df84
Removing intermediate container 4b3fb288b182
Step 3/8 : RUN mkdir /app
 ---> Running in 4adabffb85ba
 ---> 33417cb15b58
Removing intermediate container 4adabffb85ba
Step 4/8 : WORKDIR /app
 ---> 51aa10a6cc98
Removing intermediate container 3df0cb7f8a3f
Step 5/8 : COPY Gemfile ./Gemfile
 ---> 36f744d9ef97
Removing intermediate container 1aad134620c7
Step 6/8 : COPY Gemfile.lock ./Gemfile.lock
 ---> 4ecf00a75513
Removing intermediate container 5fa016426543
Step 7/8 : RUN bundle install -j 20
 ---> Running in f15edb779ff4

## Gems Installed ##

Bundle complete! 16 Gemfile dependencies, 70 gems now installed.
Bundled gems are installed into /usr/local/bundle.
 ---> e78a78f6e485
Removing intermediate container f15edb779ff4
Step 8/8 : COPY . .
 ---> f4178bf3a235
Removing intermediate container 4cfe9df1be1f
Successfully built f4178bf3a235
```

You have now successfully created the application image using Docker. Currently however, our app won't do much since we still need a database, and we want to connect everything together. This is where Docker Compose will help us out.

## Docker Compose Services

Now that you know how to create an image with a `Dockerfile`, let's create an application as a service and connect it to a database. Then we can run some setup commands and be on our way to creating that new todo list.

Create the file `docker-compose.yml`:

```bash
/> touch docker-compose.yml
```

The [Docker Compose file](https://docs.docker.com/compose/compose-file/compose-file-v2/) will define and run the containers based on a configuration file. We are using [compose file version 2](https://docs.docker.com/compose/compose-file/compose-file-v2/) syntax, and you can read up on it on Docker's site.

An important concept to understand is that Docker Compose works at “runtime.” Up until now, we have been building images using `docker build .` -- this is “buildtime.” This is especially important when we add things like `volumes` and `command` because they will override what is set up at “buildtime.”

For example, the `app` directory will be created during the build. We then map that directory to the host machine, and the host machine `app` code will be used during “runtime.” This allows us to make changes locally, and those are then accessible in the container.

Open your `docker-compose.yml` file in your editor, and copy paste the following lines:

```yaml
version: '2'
services:
  web:
    build: .
    command: bundle exec rails s -b 0.0.0.0
    volumes:
      - .:/app
    ports:
      - "3000:3000"
    depends_on:
      - postgres
    environment:
      DATABASE_URL: postgres://todoapp@postgres/todos
  postgres:
    image: postgres:9.6.2-alpine
    environment:
      POSTGRES_USER: todoapp
      POSTGRES_DB: todos
```

This will take a bit to unpack, but let's break it down by service.

### The web service

The first directive in the web service is to `build` the image based on our `Dockerfile`. This will recreate the image we used before, but it will now be named according to the project we are in, `name`. After that, we are giving the service some specific instructions on how it should operate:

*   `command: bundle exec rails s -b 0.0.0.0` - Once the image is built, and the container is running, the `bundle exec rails s -b 0.0.0.0` command will start the application.
*   `volumes:` - This section will mount paths between the host and the container.
*   `.:/app/` - This will mount the root directory to our working directory in the container.
*   `environment:` - The application itself expects the environment variable `DATABASE_URL` to run. This is set in `./config/database.yml`.
*   `ports:` - This will publish the container's port, in this case `3000`, to the host as port `3000`.

The `DATABASE_URL` is the connection string. `postgres://todoapp@postgres/todos` connects using the `todoapp` user, on the host `postgres`, using the database `todos`.

### The Postgres service

Like the Ruby image we used, the Docker Store has a prebuilt image for [PostgreSQL](https://store.docker.com/images/022689bf-dfd8-408f-9e1c-19acac32e57b?tab=description). Instead of using a `build` directive, we can use the name of the image, and Docker will grab that image for us and use it. In this case, we are using `postgres:9.6.2-alpine`. We could leave it like that, but it has `environment` variables to let us customize it a bit.

*   `environment:` - This particular image accepts a couple environment variables so we can customize things to our needs.
*   `POSTGRES_USER: todoapp` - This creates the user `todoapp` as the default user for PostgreSQL.
*   `POSTGRES_DB: todos` - This will create the default database as `todos`.

## Running The Application

Now that we have our services defined, we can build the application using `docker-compose up`. This will show the images being built and eventually starting. After the initial build, you will see the names of the containers being created.

```bash
Pulling postgres (postgres:9.6.2-alpine)
9.6.2-alpine: Pulling from library/postgres
627beaf3eaaf: Pull complete
e351d01eba53: Pull complete
cbc11f1629f1: Pull complete
2931b310bc1e: Pull complete
2996796a1321: Pull complete
ebdf8bbd1a35: Pull complete
47255f8e1bca: Pull complete
4945582dcf7d: Pull complete
92139846ff88: Pull complete
Digest: sha256:7f3a59bc91a4c80c9a3ff0430ec012f7ce82f906ab0a2d7176fcbbf24ea9f893
Status: Downloaded newer image for postgres:9.6.2-alpine
Building web
...
Creating rubyrailstodoapp_postgres_1
Creating rubyrailstodoapp_web_1
...
web_1       | => Booting Puma
web_1       | => Rails 5.0.2 application starting in development on http://0.0.0.0:3000
web_1       | => Run `rails server -h` for more startup options
web_1       | Puma starting in single mode...
web_1       | * Version 3.8.2 (ruby 2.4.0-p0), codename: Sassy Salamander
web_1       | * Min threads: 5, max threads: 5
web_1       | * Environment: development
web_1       | * Listening on tcp://0.0.0.0:3000
web_1       | Use Ctrl-C to stop
```

At this point, the application is running, and you will see log output in the console. You can also run the services as a background process, using `docker-compose up -d`. During development, I prefer to run without `-d` and create a second terminal window to run other commands. If you want to run it as a background process and view the logs, you can run `docker-compose logs`.

At a new command prompt, you can run `docker-compose ps` to view your running containers. You should see something like the following:

```bash
         Name                          Command               State           Ports
---------------------------------------------------------------------------------------------
rubyrailstodoapp_postgres_1   docker-entrypoint.sh postgres    Up      5432/tcp
rubyrailstodoapp_web_1        bundle exec rails s -b 0.0.0.0   Up      0.0.0.0:3000->3000/tcp
```

This will tell you the name of the services, the command used to start it, its current state, and the ports. Notice `rubyrailstodoapp_web_1` has listed the port as `0.0.0.0:3000->3000/tcp`. This tells us that you can access the application using `localhost:3000/todos` on the host machine.

### Migrate the database schema

A small but important step not to overlook is the schema migration for the database. Compose comes with an [`exec`](https://docs.docker.com/compose/reference/exec/) command that will execute a one-off command on a running container. The typical function to migrate schemas is `bundle exec rake db:migrate`. We can run that on the web service using `docker-compose exec`.

```bash
/> docker-compose exec web bundle exec rake db:migrate

== 20170321180544 CreateTodos: migrating ======================================
-- create_table(:todos)
   -> 0.0220s
== 20170321180544 CreateTodos: migrated (0.0221s) =============================
```

Now we can try out the API:

```bash
/> curl localhost:3000/todos

[]
```

The schema and all of the data in the container will persist as long as the `postgres:9.6.2-alpine` image is not removed. Eventually, however, it would be good to check how your app will build with a clean setup. You can run `docker-compose down`, which will clear things that are built and let you see what is happening with a fresh start.

Feel free to check out the source code, play around a bit, and see how things go for you.

## Testing the Application

The application itself includes some integration tests built using [`rspec`](http://rspec.info/). There are various ways to go about testing with Docker, including creating `Dockerfile.test` and `docker-compose.test.yml` files specific for the test environment. That's a bit beyond the current scope of this article, but I want to show you how to run the tests using the current setup.

The current containers are running using the project name `rubyrailstodoapp`. This is a default from the directory name. If we attempt to run commands, it will use the same project, and containers will restart. This is what we don't want.

Instead, we will use a different project name to run the application, isolating the tests into their own environment. Since containers are ephemeral (short-lived), running your tests in a separate set of containers makes certain that your app is behaving exactly as it should in a clean environment.

In your terminal, run the following command:

```bash
/> docker-compose -p tests run -p 3000 --rm web bundle exec rspec
...............

Finished in 1.9 seconds (files took 5.29 seconds to load)
15 examples, 0 failures
```

The `docker-compose` command accepts several [options](https://docs.docker.com/compose/reference/overview/), followed by a command. In this case, you are using `-p tests` to run the services under the `tests` project name. The command being used is [`run`](https://docs.docker.com/compose/reference/run/), which will execute a one-time command against a service.

Since the `docker-compose.yml` file specifies a port, we use `-p 3000` to create a random port to prevent port collision. The `--rm` option will remove the containers when we stop the containers. Finally, we are running in the `web` service `bundle exec rspec`.

## Conclusion

At this point, you should have a solid start using Docker Compose for local app development. In the next part of this series about using Docker Compose for Ruby development, I will cover integration and deployments of this application using Codeship.

Is your team using Docker in its development workflow? If so, I would love to hear about what you are doing and what benefits you see as a result.