Simplifying local dev setup with Docker Compose
Tags: node, docker
Published: 2020-08-26 02:30:31

---
title: Simplifying local dev setup with Docker Compose
published: true
date: 2020-06-23 00:00:00 UTC
tags: nodejs,docker
canonical_url: https://www.coreycleary.me/simplifying-local-dev-setup-with-docker-compose
---

<em><strong>Originally published at <a href="https://www.coreycleary.me/simplifying-local-dev-setup-with-docker-compose">coreycleary.me</a></strong>. This is a cross-post from my content blog. I publish new content every week or two, and you can <a href="https://www.coreycleary.me/about/">sign up to my newsletter</a> if you'd like to receive my articles directly to your inbox! I also regularly send cheatsheets and other freebies.</em>

If you've ever had to deal with setting up a Node.js project in which you had to install a bunch of things - like MySQL/Postgres, Redis, etc. - and then run some setup scripts _just_ to be able to get the project running locally on your machine...

...then you've likely experienced the pain of losing half a day - at least - to solely just getting set up.

This is especially frustrating and anxiety-inducing if you're new to the team and want to start contributing right away, not waste time in the maze of steps you have to run, or waste time having to ask the team every 5 minutes how to get over the next install hurdle.

What's worse is, as the project evolves, you might need to install more things, you might have more complex setup scripts, and (worst of all IMO) documentation for that setup might become out of date.

Rather than having to install a bunch of things - or figure out what you need to install in the first place in the case of bad documentation - there's a much easier way that can get you up and running in as little as one or two commands.

## Enter Docker Compose

Docker Compose gives us the ability to define install dependencies - like databases and other software - and run them within containers that your "main" code can interact with.

In order to best explain how to use Compose - and how to convert an existing project with local install steps, scripts, etc - I'll use an example of a demo repo I wrote awhile back (that accompanied [this post on designing reliable queues](https://www.coreycleary.me/understand-how-to-approach-designing-queues-in-node)).

When I originally built that project, it was using "the old way", without Compose.

But I recently re-wrote it to use Compose for creating Redis and Postgres containers, and to be able to run the tests against those containers (using Compose is also really good for having local test databases).

## New world and old world

First, let's look at [how the project was setup](https://github.com/coreyc/queue-example/tree/without-docker-compose#queue-example) using "the old way":

- first install Homebrew
- then install Postgres
- then create a "root" database
- then define the schema
- then run a script to **install** Redis
- then run a script to **start** Postgres
- then run a script to **start** Redis

That's a lot of steps...

Now, let's take a look at the steps involved using Docker Compose: `docker-compose up`

...and that's it.

## How were we able to accomplish this?

Let's look at how I converted this project over to using Compose.

#### Postgres

Instead of having to **install Postgres** (and Homebrew, if you didn't already have it installed), and then **define our database and schema**, using Compose that becomes:

```yaml
version: '3.7'
services:
  db_queue:
    image: postgres:9.6.17
    container_name: db_queue
    environment:
      POSTGRES_DB: library
      POSTGRES_USER: root
      POSTGRES_PASSWORD: password
    volumes:
      - ./init.sql:/docker-entrypoint-initdb.d/init.sql
      - db-data:/var/lib/postgresql/data
    ports:
      - 5432:5432

volumes:
  db-data:
```

_Note that the above is contained in the docker-compose.yml file in the root of our project._

_Second note: you'll need to have Docker installed on your machine in order to use Docker and Docker Compose_.

We define our "install dependencies" within the `services` section, in this case, Postgres.

Then we define the basic environment variables that Postgres needs to startup the database. In the old world, where we were creating the database from the command line via psql, here we just define it under `POSTGRES_DB`.

The service's `volumes` section uses an initialize script (more on this in a second) and defines a database volume that gets "mounted" alongside the container. And we define that volume name using the "root" `volumes` section, in this case using the name `db-data`.

The reason we do that is so that if we bring down the "stack" using `docker-compose down`, it won't clear the schema definitions + data stored in the database. Note, if we _want_ to delete that information and bring it _totally_ down, we can use the command `docker-compose down -v`, using the `-v` flag for "volume".

The init.sql (used to create the table schema as the container boots up) still needs to be created, but instead of you having to manually define the schema, the SQL script just gets leveraged by Compose instead. In other words, its automatic rather than manual, and removes a step for us.

And here's what that init.sql script looks like:

```sql
CREATE TABLE books (book_number int, isbn text)
```

Lastly, we map the container port to the host machine port (the host machine being your machine itself), so that you can access the container _from_ your machine. That's done in the service's `ports` section.

#### Redis

For Redis, it's even simpler. In that same `services` section, we do:

```yaml
redis_queue:
  image: redis:5.0.6
  container_name: redis_queue
  ports:
    - 6379:6379
```

Define the Docker Redis image to use, give the container a name, and map the ports. Simple.

Compared to the old world, where we had to [run a script](https://github.com/coreyc/queue-example/blob/without-docker-compose/setup-redis.sh) to `wget` to install Redis and build that code using `make`, then start Redis using a **separate** [script](https://github.com/coreyc/queue-example/blob/without-docker-compose/start-redis.sh), the Compose way is much easier.

## Leveraging the Compose containers

Real quick, here's the entire `docker-compose.yml` file in its entirety:

```yaml
version: '3.7'
services:
  redis_queue:
    image: redis:5.0.6
    container_name: redis_queue
    ports:
      - 6379:6379
  db_queue:
    image: postgres:9.6.17
    container_name: db_queue
    environment:
      POSTGRES_DB: library
      POSTGRES_USER: root
      POSTGRES_PASSWORD: password
    volumes:
      - ./init.sql:/docker-entrypoint-initdb.d/init.sql
      - db-data:/var/lib/postgresql/data
    ports:
      - 5432:5432

volumes:
  db-data:
```

Like I mentioned before, all we need to do to start the "stack" is to run `docker-compose up`, and Docker will use the Compose file and services defined therein to spin up the containers.

Because we have the container ports mapped to the local machine, we can run the unit/integration tests using `npm test` - nothing different we need to do.

You can also run the code against the containers, not just the tests. Simple.

## Wrapping up

If you're continuously bumping up against problems running your project locally, strongly consider using Docker Compose for this instead.

It makes defining a local "stack" for local development a lot simpler and more headache-free then installing a bunch of stuff on your machine. And in this post we've really only scratched the surface of what you can do. It can make your developer life SO much easier.

Love JavaScript but still getting tripped up by local dev, architecture, testing, etc? I publish articles on JavaScript and Node every 1-2 weeks, so if you want to receive all new articles directly to your inbox, <a href="https://www.coreycleary.me/about/">here's that link again</a> to subscribe to my newsletter!