Docker-compose vs Docker compose

In the first blog, we have discussed what is docker compose, why we need docker compose and what are the benefits of docker compose. If you have not read that article, first go to my profile or click the link below and read that article.

Docker Compose

Now in this article we will see problems or limitations in docker compose and we will see how these problems have been solved in the updated versions of docker compose. We will see the differences between docker compose v1 and v2. Basically, we will find out that which new features v2 provides that v1 does not.

docker compose v1 vs v2

So here are the topics we will cover in this article:

1) Limitations in docker compose v1

2) Benefits of docker compose v2

3) which should you use ?

4) Yaml file changes

5) How to install docker compose v2 ?

6) GitHub repository

1) Limitations in docker compose v1

i) Project names:

The way Compose v1 handles project names is one of its drawbacks. Compose adds the project name to the service name of each container when you run docker-compose up -d. This makes sure that all of the containers are put in one group.
The project name in version 1 is got from the name of your working directory. By altering the COMPOSE_PROJECT_NAME environment variable, a different name can be selected manually.

2) Benefits of docker compose v2

i) Fast Delivery of New Features Within the Docker CLI

In docker compose v2, we have many new useful features which we do not see in v1:

a) It provide support for GPU machines. If the Docker host has GPU devices and the Docker Daemon is configured correctly, Compose services can specify GPU device reservations.

b) It also provide profiles support. By selectively enabling services, profiles let you to modify your Compose application model for different contexts and usages.

c) You may now check complete list of your Compose apps with the docker compose ls command.

d) You can copy files and folders between your service container and your local filesystem using the docker compose cp command.

These functionalities are distributed using the Docker CLI. The CLI updates are immediately applied to each Docker Desktop, which lessens your administrative strain.

ii) Seamless Path to Production

What if you could quickly put together a project and execute it within your AWS, ECS, or Azure ACI environment? By using new Cloud Integrations in Compose V2, you can do this.

Deploying Docker Compose applications to the cloud is now considerably simpler if you use ACI or ECS for production and Docker Compose for local development. By simply changing the Docker context, you may “compose up” an application on cloud platforms and run it on Amazon ECS or Microsoft ACI.

This is possible due to the V2 Compose specification. Platform independent multi-container applications can be defined using the Compose specification. The specifications can be used by other programs to run and validate these files.

iii) Creating a Homogenous Docker Ecosystem in Go

We all know that unlike other Docker ecosystem, Docker Compose V1 was written in Python before Compose V2. Compose V2, on the other hand, is written in Go. The CLI, Moby, and other Go-based projects’ code can all be converted into Go. We won’t need to develop any new features or bug fixes in Python after Docker Compose switches to Go.

We can now integrate a fix from the Docker CLI more easily with Compose. Accordingly, we can quickly deliver more value across our tooling. We can also easily add updates to Compose from other Docker tools, like BuildKit.

To preserve well-tested behavior while running both Docker and Docker Compose, we now utilize the same code for the run and exec commands in both Compose and the Docker CLI. The consistency between them makes it simpler for engineers to transition between them, even down to the log output.

iv) Easier Update-and-Dependency Management with Compose Binaries

We were previously unable to provide a static binary, but with Go, we can. This is due to Python’s lack of an integrated compiler. Due to this, we were compelled to use pyinstaller to provide binaries for popular operating systems (Linux, macOS, and Windows). V1 relies on the PyPI (via pip install) on more heterogeneous platforms, which makes managing dependencies more difficult. Numerous dependency combinations might already be installed on your system.

Finally, natively running things is considerably faster!

v) Run Commands Without a Compose File

Not to mention, container labels enable you to rebuild data from your YAML files. By simply adding -project-name to the command line, this functionality enables you to manage an active project and use commands like docker compose start/stop/pause/down/ps/exec… without using the original Compose file and environment variable. Simply use -project-name to select an existing project name that you’ve previously defined (-p).

For instance, you wouldn’t need to be in the project’s folder or have your Compose file in the current directory to use the following command:

$ docker compose --project-name myproject down

vi) project names

We saw the problem of project names in v1. By including a CLI flag to set the project name, version 2 makes this easier. To ignore the working directory name without changing the environment, add — project-name or -p. You can start several instances of a container stack or merge containers from different working directories into one stack by manually defining the project name.

You can list all of your system’s Compose stacks using a new v2 functionality. A table of project names and their statuses is provided by the docker compose ls command (running or stopped). This is a supplement to the docker compose ps command, which displays a stack’s statuses for each container.

Docker compose cp is now supported by Compose v2. You can copy files into and out of your containers with this command, which functions similarly to docker cp:

docker cp my-container local-file.txt /path/to/container/file.txt

3) which should you use ?

Version 2 has some advantages over Version 1 and is actively updated, therefore I definitely prefer it. V2 provides many extra features (discussed above) that v1 does not. So i will recommend you v2 of docker compose.

4) Yaml file changes

Version numbers for files created with the version 2 syntax must be displayed at the document’s root. The services key must have a declaration for each service.

Networks and named volumes can both be declared using the volumes and networks keys, respectively.

Note

Make sure to provide both the major and minor numbers when choosing the Compose file version to use. If no minor version is specified, 0 is used instead of the most recent minor version by default. Features included in later versions won’t be supported as a result. For instance:

version: “2”

version: “2.0”

Simple example:

version: "2.4"
services:
  web:
    build: .
    ports:
     - "8000:5000"
    volumes:
     - .:/code
  redis:
    image: redis

A more extended example, defining volumes and networks:

version: "2.4"
services:
  web:
    build: .
    ports:
     - "8000:5000"
    volumes:
     - .:/code
    networks:
      - front-tier
      - back-tier
  redis:
    image: redis
    volumes:
      - redis-data:/var/lib/redis
    networks:
      - back-tier
volumes:
  redis-data:
    driver: local
networks:
  front-tier:
    driver: bridge
  back-tier:
    driver: bridge

Several other options were added to support networking, such as:

• aliases
• The depends_on option can be used in place of links to indicate dependencies between services and startup order.

version: "2.4"
services:
  web:
    build: .
    depends_on:
      - db
      - redis
  redis:
    image: redis
  db:
    image: postgres

• ipv4_address, ipv6_address

Variable substitution also was added in Version 2.

5) How to install docker compose v2 ?

Compose v2 is a binary, just as v2, therefore it could theoretically be copied to /usr/local/bin without any further steps. The binary needs to be copied into the plugin folder in order for the call to function as a plugin when using docker compose (i.e., spaces rather than minus). This is $HOME/.docker/cli-plugins for your local user; if you wish to install globally, use one of the other three of the following four folders:

• /usr/local/lib/docker/cli-plugins
• /usr/local/libexec/docker/cli-plugins
• /usr/lib/docker/cli-plugins
• /usr/libexec/docker/cli-plugins

Depending on whether you want to install system-wide or for your current user, you first create the desired folder. Then look for the latest stable version on the Compose release page. In my case, the 64-bit edition of the Raspberry Pi OS is installed on a Raspberry Pi 4, so I choose AARCH64 for the 64-bit ARM architecture. Depending on the hardware and software used, you can alternatively use ARMv7 or ARMv6. The binary is then downloaded and moved to the plugin folder. We change the name to docker-compose .

mkdir -p ~/.docker/cli-plugins
wget https://github.com/docker/compose/releases/download/v2.3.3/docker-compose-linux-aarch64
mv docker-compose-linux-aarch64 ~/.docker/cli-plugins/docker-compose

Now you can test the call as a plugin (with spaces instead of minus):

$ docker compose version
Docker Compose version v2.3.3

I would choose this installation technique since it is the official Docker recommended installation method for V2. You can use Compose with minus as in version 1 if you still like to relocate the binary to /usr/local/bin. It’s unclear though whether Docker will continue to offer full-featured support for this.

6) GitHub repository

Here are some important code files related docker compose V2.

GitHub - SikandarZaman20rk/Docker-compose-V2

References:

Docker Compose v1 vs. v2: Welche Version sollte ich benutzen? Worin liegen die Unterschiede?

Docker-compose.yml: from V1 to V2

What's New In Docker Compose v2?

Compose file versions and upgrading