Docker has decided to sunset v1 of Compose so we need to update our docker stuff. Sitecore is working at their end to bring all the required support. Let’s take a look at what actions we as developers need to take in order to migrate to v2 smoothly.
What is Docker Compose?
Docker Compose simplifies the management of multiple containers, enabling them to collaborate effectively. It’s particularly useful when developing applications using the microservices model. By leveraging Docker Compose, you can divide your application code into separate, self-contained services that interact via web requests.
Essentially, Docker Compose extends the functionality of Docker, allowing for streamlined management of more intricate applications. Furthermore, even for single-container scenarios, Docker Compose offers advantages over using a standalone Dockerfile. It enables the definition of container-specific settings such as volume mounts, port mappings, and environment variables through the use of docker-compose YAML files. This approach ensures tool-independent configuration, making it easier to maintain and deploy your application.
V1 vs V2
Unlike Compose v1, Compose v2 integrates into the Docker CLI platform and the recommended command-line syntax is docker compose.
There are currently two applications for working with Docker Compose.
docker-compose– this is the original standalone Docker orchestration application.docker compose– is the second option is a newer project that integrates Compose with the main Docker project. It is essentially a v2 branch of the docker/compose repository.
Initially introduced to Docker Desktop users, Linux Docker users might not have even encountered this command. Currently, the original Python project called docker-compose (also known as v1 in the docker/compose repository) has been deprecated, and development has shifted to v2.
Here’s the total overview of how v2 compares against v1:
Which version I got?
You can check the active version by running a command:
docker-compose version --short
Make sure you execute docker–compose with a dash in between, as the v2 command of docker CLI only supports version two, regardless of current setting. For example, here is the prompt I am getting on v2 disabled:
Switching between versions is a matter of a single checkbox, followed by a restart:
Migrating to version 2
Migration itself is not a much-complicated set of activities. First and most, since we now call docker compose without a dash in between, this change should be reflected along all the PowerShell scripts that call it, such as up.ps1 and down.ps1.
Another change would be to insure double backslashes for the paths provided as an entrypoint:
entrypoint: powershell.exe -Command "& C:\\tools\\entrypoints\\iis\\Development.ps1"
Another change relates to the syntax of scaling containers, where required. Instead of stating scale: <COUNT> at the service level, we replace it with deploy parameter and its child node replicas: <COUNT> so that it looks like this:
# A Windows-based nodejs base image
nodejs:
deploy:
replicas: 0
There is also a more verbose official guide on upgrading from V1 to V2 available from the Docker docs portal.
Memory allocation
With Hyper-V isolation mode there is a memory allocation limitation of 1GB per container in the build stage. That is clearly not enough for some heavyweight cases, so previously one could simply force allocating more RAM by passing it as a parameter to the builder:
docker-compose build --memory 4096m
Now this parameter is no longer in use and is being ignored. Hopefully, Docker addresses the issue created by my fellow friend Peter Nazarov, at least they responded and hopefully, this parameter will be back in future releases of Docker Desktop.
XM Cloud starter kits
The only way to spin up a local development is by using Docker containers, and therefore it also should be updated to use v2 of Docker Compose. Everything described above stays also valid for XM Cloud starter kits.
