Orchestrate Containers for Development with Docker Compose

DZone 's Guide to

Orchestrate Containers for Development with Docker Compose

I’ll look at how we can use Docker Compose in detail. Specifically, I’ll focus on how to orchestrate containers in development.

· Cloud Zone ·
Free Resource

The powerful concept of microservices is gradually changing the industry. Large monolithic services are slowly giving way to swarms of small and autonomous microservices that work together. The process is accompanied by another market trend: containerization. Together, they help us build systems of unprecedented resilience.

Containerization changes not only the architecture of services, but also the structure of environments used to create them. Now, when software is distributed in containers, developers have full freedom to decide what applications they need. As a result, even complex environments like CI servers with database backends and analytical infrastructure can be instantiated within seconds. Software development becomes easier and more effective.

The changes naturally cause new problems. For instance, as a developer, how can I easily recreate a microservice architecture on my development machine? And how can I be sure that it remains unchanged as it propagates through aContinuous Delivery process? And finally, how can I be sure that a complex build & test environment can be reproduced easily?

Introducing Docker Compose

The answer to these questions is Docker Compose, “a tool for defining and running complex applications with Docker. With Compose, you define a multi-container application in a single file, then spin your application up in a single command which does everything that needs to be done to get it running.” (https://docs.docker.com/compose/).

All of that can be done by Docker Compose in the scope of a single host. In that sense, its concept is very similar to Kubernetes pods. For multi-host deployment, you should use more advanced solutions, like Apache Mesos or a completeGoogle Kubernetes architecture.


The main function of Docker Compose is the creation of microservice architecture, meaning the containers and the links between them. But the tool is capable of much more:

  • Building images (if an appropriate Dockerfile is provided)
docker-compose build
  • Scaling containers running a given service
docker-compose scale SERVICE=3
  • Healing, i.e., re-running containers that have stopped
docker-compose up --no-recreate

All this functionality is available through the docker-compose utility, which has a very similar set of commands to what is offered by docker:

build    Build or rebuild services 
help     Get help on a command 
kill     Kill containers 
logs     View output from containers 
port     Print the public port for a port binding 
ps       List containers 
pull     Pulls service images 
rm       Remove stopped containers 
run      Run a one-off command 
scale    Set number of containers for a service 
start    Start services 
stop     Stop services 
restart  Restart services 
up       Create and start containers

They are not only similar, but they also behave like docker counterparts. The only difference is that they affect the entire multi-container architecture defined in thedocker-compose.yml configuration file and not just a single container.

You’ll notice some docker commands are not present in docker-compose. Those are the ones that don’t make sense in the context of a completely multi-container setup. For instance:

  • Commands for image manipulation (e.g.savesearchimagesimportexport,taghistory)
  • User-interactive (e.g.attachexec‘run -i’loginwait)

A command that is worth your attention is the docker-compose up command. It is a shorthand form of docker-compose build && docker-compose run.

Docker Compose Workflow

There are three steps to using Docker Compose:

  1. Define each service in a Dockerfile.
  2. Define the services and their relation to each other in the docker-compose.ymlfile.
  3. Use docker-compose up to start the system.

I’ll show you the workflow in action using two real-life examples. First, I’ll demonstrate basic syntax of docker-compose.yml and how to link containers. The second example will show you how to manage an application’s configuration data across development and testing environments.

Example 1: Basic Structure

The syntax of the docker-compose.yml file closely reflects the underlying Docker operations. To demonstrate this, I’ll build a container from Redis Commandersources and connect it to the Redis database.

Implementation (source)

Let’s create a project with the following structure:

├── commander 
│ └── Dockerfile 
└── docker-compose.yml

Now let’s follow the workflow. Define the Dockerfile that builds Redis Commander (see source), and then create docker-compose.yml.

  image: redis:3 
  restart: always

  build: commander 
    - backend:redis  
    - 8081:8081 
    - VAR1=value 
  restart: always

Now execute:

docker-compose up -d

After that, point your browser to http://localhost:8081/. You should see the user interface of Redis Commander that’s connected to database.


  • The command docker-compose up -d has the same effect as the following sequence of commands:
docker build -t commander commander
docker run -d --name frontend -e VAR1=value -p 8081:8081
   --link backend:redis commander
  • Each service needs to point to an image or build directory; all other keywords (linksportsenvironmentrestart) correspond to docker options.
  • docker-compose up -d builds images if needed.
  • docker-compose ps shows running containers.
$ docker-compose ps
     Name               State               Ports
example1_backend_1       Up               6379/tcp   
example1_frontend_1 ...  Up     >8081/tcp
  • docker-compose stop && docker-compose rm -v stops and removes all containers

Example 2: Configuration Pack

Now let’s deploy an application to two different environments — development and testing — in such a way that it would use different configuration depending on the target environment.

Implementation (source)

One of our possible options is to wrap all environment-specific files into separate containers and inject them into the environment if needed.

Our project will have the following structure:

├── common 
│ └── docker-compose.yml 
├── development 
│ ├── content 
│ │ ├── Dockerfile 
│ │ └── index.html 
│ └── docker-compose.yml 
└── testing 
├── content 
│ ├── Dockerfile 
│ └── index.html 
└── docker-compose.yml

And again let’s follow the workflow.

First let’s create Dockerfiles ({development,testing}/content/Dockerfile) that wrap environment-specific content in containers. In this case, just to illustrate the mechanism, containers will contain only an index.html file with an environment-specific message (e.g., “You are in development!”).

FROM tianon/true

VOLUME ["/usr/share/nginx/html/"] 
ADD index.html /usr/share/nginx/html/

Note that because we don’t need an operating system, the images are built on top of the smallest fully functional image: tianon/true. The image is originally builtFROM scratch and contains only /true binary.

Now let’s create docker-compose.yml files. common/docker-compose.ymlcontains shared services of application. In this case, it’s just one service: nginxserver with the definition of port mappings:

  image: nginx 
    - 8082:80

The definition will be used through inheritance.

Each environment needs its own docker-compose.yml file (development/docker-compose.yml and testing/docker-compose.yml) that injects the correct configuration pack.

    file: ../common/docker-compose.yml 
    service: web 
    - content

  build: content

Executing the following commands:

cd development 
docker-compose up -d

Point a browser to http://localhost:8082/. You should be able to see the “You are in development!” message. You can activate testing environment setup by executing:

docker-compose stop 
cd ../testing 
docker-compose up -d

When you reload the browser, you should see the “You are in testing!” message.


  • web service inherits from common/docker-compose.yml. Its original definition is extended by the volumes_from directive that maps volumes from contentcontainer. This is how the application gets access to environment-specific configuration.
  • After start, content container executes the true command and immediately exits, but its data remain exposed to the web container, which stays active.


Docker Compose is not yet (as of May 2015) recommended by Docker for production use. But its simplicity, and the fact that an entire configuration can be stored and versioned along with your project, makes it a very helpful utility for development. For more information, refer to official documentation athttps://docs.docker.com/compose

container, docker compose

Published at DZone with permission of Moritz Plassnig , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}