Alternative to Kubernetes: Docker Compose

The Application Docker Compose

Compose is a tool for using and running multi-container Docker applications. With Compose, you can define a YAML file to configure application services.

In fact, in the YAML file, it is possible to define multiple Docker containers under the " services " hat, both starting from Dockerfile and from ready-made images.

It is not applicable in all cases. If the project is a simple application that does not require the use of third-party services, then for its deployment, you can limit yourself only to Docker. Docker Compose is recommended for use in the design of complex software products that include many processes and services.

It will be possible to create and start all the services defined in the file with a single command. It is, in practice, a process divided into three phases:

1. configuration of the application environment with or without Dockerfile;
2. definition of the necessary services within the file docker-compose.yml;
3. execution of the command docker-compose up that will start the execution of the application.

Features

The main features of Docker Compose that make it useful are:

• Many isolated environments on a single host
• Preserve volume data when containers are built
• Only rebuild containers that have changed
• Variables and moving a composition between environments

How Docker Compose Work

Let's imagine we want to pull up WordPress, which needs MySQL. Inside a folder called wordpress-docker, we create a file called docker-compose.yml with this content (present on GitHub ):

version: '3.7'

services:
 db:
 build: ./mysql
 image: poc / mysql-for-wordpress
 volumes:
 - db_data: / var / lib / mysql
 restart: always
 environment:
 MYSQL_ROOT_PASSWORD: somewordpress
 MYSQL_DATABASE: wordpress
 MYSQL_USER: wordpress
 MYSQL_PASSWORD: wordpress

 wordpress:
 depends_on:
 - db
 image: wordpress: latest
 ports:
 - "8000: 80"
 restart: always
 environment:
 WORDPRESS_DB_HOST: db: 3306
 WORDPRESS_DB_USER: wordpress
 WORDPRESS_DB_PASSWORD: wordpress
 WORDPRESS_DB_NAME: wordpress
volumes:
 db_data: { }

 In this case, we made customization (not that it was needed, it is only for educational purposes), through Dockerfile, of the MySQL container, while we took the default one for WordPress. Note the value of WORDPRESS_DB_HOST " db: 3306 ": the reference to the database container is resolved with the name of the associated service.

Docker Compose, however, is not natively available when installing Docker, but is a separate tool, written in Python, which must be installed independently and automates certain operations of the Docker daemon. It has its own CLI, accessible through the docker-compose command, which greatly simplifies the "group management" of the services listed in the YAML file.

To start all the services, just run:

$> docker-compose up -d

Where with -d you avoid getting stuck to the system out of the containers started. What happens now? Control of the console is returned to us only after these operations:

Creating network "wordpress-docker_default" with the default driver 

Creating volume "wordpress-docker_db_data" with the default driver 

Building db 

Step 1/2: FROM mysql: 5.7 

 ---> 98455b9624a9 

Step 2/2: COPY * .cnf / etc / mysql /conf.d/ 

 ---> 52440b13db7c 



Successfully built 52440b13db7c 

Successfully tagged poc / mysql-for-wordpress: latest 

WARNING: Image for service db was built because it did not already exist. To rebuild this image, you must use `docker-compose build` or` docker-compose up --build.` 

Creating wordpress-docker_db_1 ... done 

Creating wordpress-docker_wordpress_1 ... done

• A network is created that links the two containers and isolates them from everything else. The name is curious: it is the name of the folder where the docker-compose.yml (called wordpress-docker remember?) To which "default" is attached.
• The volume "db_data" is created, always with the prefix wordpress-docker.
• The modified image of the database is created, called poc / mysql-for-wordpress, through the Dockerfile present in the MySQL folder.
• The containers of the "db" and "WordPress" services are started, exactly in this order, because of the dependencies. In this case, in addition to the usual WordPress-docker prefix, we note a number, after which the name of the service follows: this is the first instance of the service.

The first thing that catches the eye is that the name of the folder containing the YAML file is used as a " namespace " for the nomenclature of the resources created: this approach is interesting because it allows you to relaunch the same stack of services from different folders without creating conflicts.

All these operations are synchronous with the CLI: until the containers are started, we will not be able to regain control of the console. The compose CLI is interesting because it allows you to check the containers in groups:

$> docker-compose ps 



       Name Command State Ports 

---------------------------------------- -------------------------------------------------- - 

wordpress-docker_db_1 docker-entrypoint.sh mysqld Up 3306 / tcp, 33060 / tcp 

wordpress-docker_wordpress_1 docker-entrypoint.sh apach ... Up 0.0.0.0:8000->80/tcp

Displays the status of the containers and their mapped ports (if any). It is also possible to control only one, called with the name of the service:

$> docker-compose stop wordpress 

Stopping wordpress-docker_wordpress_1... done 



$> docker-compose start wordpress 

Starting Wordpress... done

If you re-run the start command of all the services ( up ), Compose will check for us if there are new versions of the images and possibly start them  (with dependencies in cascade). Changing the image of the database; then, WordPress will also be restarted:

$> docker-compose up -d 

Recreating wordpress-docker_db_1 ... done 

Recreating wordpress-docker_wordpress_1 ... done

Summing Up

So far, we have seen that Compose is perfect for managing the build and runtime cycle of multiple services together, why should we need anything else?

It's perfect for software development support: we can practically create and build the infrastructure we need on our development machine! In my opinion, Compose begins to stay tight in two cases:

• when services need to run on multiple machines, Compose can not control this situation. The network created between the instantiated services is a subnet of the same host, pure isolation based on iptables: there is no concept of "cluster of nodes." We cannot, therefore, run WordPress on one machine and MySQL on another managed by Compose because they would not "see" each other at the network level: the Compose of the two machines would have nothing in common. The only way to make them communicate would be to expose the ports on the respective hosts and to make the services talk through the hostnames, but all the dynamism offered by Docker is lost.
• If you try to scale a service (obviously on the same host because you can't do otherwise) that has a port binding on the host, scaling will be prevented because the first instance already occupies the port! In fact, let's try to scale WordPress:

$> docker-compose up -d --scale wordpress = 2   

 

WARNING: The "wordpress" service specifies a port on the host. If multiple containers for this service are created on a single host, the port will clash.  

Starting wordpress-docker_wordpress_1 ... done   

Creating wordpress-docker_wordpress_2 ... error   

ERROR: for wordpress-docker_wordpress_2 Cannot start service wordpress: driver failed programming external connectivity on endpoint wordpress-docker_wordpress_2 (f19636f06cfcf461c0d175a182fa3c8f0f0f0f0f0f0f0f0f0f0f0f0f0fcf0fcf0fcf0fcf0fcf0fcf0fcf0fcf0fcf0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0bh0 besides0 but about. port is already allocated

Wanting to scale the database, however, this would work because it has no binding:

$> docker-compose up -d --scale db = 2 

Starting wordpress-docker_db_1 ... done 

Creating wordpress-docker_db_2 ... done 

wordpress-docker_wordpress_1 is up-to-date

• Even if the result is that 2 instances of MySQL on the same volume can only do damage :), so better avoid!

When you need to control multiple services on multiple machines, and maybe scale them, more is needed, at least docker swarm is needed. Let's destroy all containers, including volumes:

$> docker-compose down -v 

Stopping wordpress-docker_wordpress_1 ... done 

Stopping wordpress-docker_db_1 ... done 

Removing wordpress-docker_wordpress_1 ... done 

Removing wordpress-docker_db_1 ... done 

Removing network wordpress-docker_default 

Removing volume wordpress-docker_db_data

Conclusion

Docker is an important tool for every modern developer, as the basis of hardware application virtualization. This technology has wide functionality and capabilities for process control. Docker allows not only to deploy containers but also to quickly scale their instances, work with multi-container applications (Docker Compose).

Docker is characterized by a fairly simple syntax. Therefore, it is quite easy to learn for both experienced IT specialists and beginners. The software is compatible with all versions of Linux and Windows operating systems, so the scope of Docker is practically unlimited.