Local development and test setup using docker

Previously…

In my last post I demonstrated using ASP.NET 5 MVC6 WebApi in docker.

This was relatively trivial to set up but it begs the question “Why is this useful in my daily routine”.

Setting the scene

Picture yourself in a cross functional team. The application that is being worked upon has an api and a user interface (UI). As a UI developer I may not care how awesome the backend service is and they certainly shouldn’t have to know how to build or set it up, nope, I just need to be able to consume it!

Docker Compose to the rescue

From the docker site:

“Docker Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a Compose file to configure your application’s services. Then, using a single command, you create and start all the services from your configuration.”

This sounds like it may be the thing. In theory we could build and run the whole application without needing to know the complexities of any of the containers.

To see this in action I have set up a simple git repository it contains everything for my chuck fact application. First go get the repository:

  git clone git@github.com:nptomlin/chuck-with-html.git

This has downloaded everything that is required to run the Chuck Fact application. The top level directory looks like this:

  chuck-with-html/
  ├── site/
  ├── api/
  ├── proxy/
  └── docker-compose.yml

It contains:

A site directory A static html site that consumes the chuck fact api and the Dockerfile to serve this in an nginx docker instance.

An api directory The C# api source for chuck facts and a Dockerfile to build and run it.

A proxy directory Nginx configuration and Dockerfile to create a reverse proxy that sits in front of the site and the api and forwards requests to them.

A docker-compose.yml The YAML file describing the containers that are required to run our application and how they fit together.

Running

Running the application is as simple as:

  docker-compose up -d

This builds and runs the docker containers in detached mode. Now if we open a browser and navigate to http://127.0.0.1/ we will see our Chuck Fact user interface. Clicking get fact retrieves a Fact from the Chuck Fact Api.

To stop the application:

  docker-compose down

How is this configured

We can take a look at the docker-compose.yml to see how the containers are configured.

  api:
    build: ./api

  site:
    build: ./site

  proxy:
    build: ./proxy
    links:
      - site
      - api
    ports:
      - "80:80"

api builds and runs a container using the Dockerfile in the api directory.
site builds and runs a container using the Dockerfile in the site directory
proxy builds and runs a container using the Dockerfile in the proxy directory it links to site and api instances and exposes itself on port 80.

The most interesting bit of this is probably the proxy as it sets up the reverse proxy which ties our application together. This is a simple NGINX container which is configured to forward calls to / to the site container and calls to /api/ to the api container.

And for testing production images…

The docker-compose-prod.yml describes the production environment, it will run pre built “production” images from the docker hub. All that is needed to run the production application on my machine is.

  docker-compose -f docker-compose-prod.yml up -d

What it does not do

My set-up isn’t ready to deploy to production in its current state for a number of reasons for instance, it doesn’t handle load balancing or allow the scaling of containers, but that wasn’t the purpose of this post.