Docker: Orchestration

Note (2026): This article uses docker-compose v1 syntax. In modern Compose files, define services under services: according to the Compose Specification, and use Docker networks instead of links: containers on the same network can reach each other by name automatically. The docker-compose command has been replaced by docker compose.

What Is Orchestration?

Orchestration is the coordination of interaction between several containers. In principle, nothing prevents us from creating a container in which all the necessary processes are running at once, but this approach lacks flexibility when scaling, changing architecture, and also creates security problems, because in this case the processes are not isolated in any way and can affect one another without limits. Orchestration, on the other hand, allows us to build information systems from small container bricks, each of which is responsible for only one task, while communication happens through network ports and shared directories. If necessary, containers in such an “orchestra” can be replaced with others: for example, to check how the application works on another database version.

Installing Docker Compose

You can read about installing Docker Compose on different operating systems on the official project site: https://docs.docker.com/compose/

Configuring Orchestration

To manage orchestration parameters, a configuration file is used that describes in detail both the launch parameters of individual containers and all the relationships between them. By default, the config is called docker-compose.yml and looks something like this:

yaml

fpm:
  build: ./fpm/
  links:
    - db
    - mc
  volumes:
    - ./www:/var/www
db:
  build: ./db/
  volumes:
    - ./db:/var/lib/mysql
  ports:
    - 3306:3306
mc:
  build: ./mc/
  ports:
    - 8080:1080
nginx:
  build: ./nginx/
  links:
    - fpm
  ports:
    - 80:80
    - 443:443
  volumes:
    - ./www:/var/www

The example shows an environment for a simple PHP/MySQL application intended for testing and development.

build is a relative path to the folder containing the Dockerfile. It allows the container to be rebuilt. Its alternative is image, which specifies the image name. For one node, you can specify either a build or a ready image, but not both together.
links are direct connections between containers in the bundle. For example, the fpm container will be able to access the db container directly using the host “db.” This address can be used anywhere, because it is a record in /etc/hosts left by Docker when starting the containers and pointing to the current db container.
volumes mount host directories into the container file system. Several containers can share access to a directory. For example, in the example, both Nginx and Fpm have access to the project root directory.
ports redirect host ports to container ports. In fact, the ports do not have to match. Nothing prevents directing container port 80 to host port 8080, or the other way around. You can also specify the network interface on which the host port will “listen.” For example, 127.0.0.1:80:80.

And so on. The parameters are in many ways similar to those used when starting a container through docker run. Details can be read on the official site.

Building Containers

bash

# stop containers if they were already built earlier
sudo docker-compose stop

# remove containers if they were already built earlier and stopped
sudo docker-compose rm

# build
sudo docker-compose build

Starting Containers

When the d option is specified, the utility will run in the background.