How to install docker-compose v2 on Linux

[rfay]

Description

I'm trying to allow DDEV to use docker-compose v2 and don't have the resources for a whole set of tests on every macOS variant... but I thought it would be nice to run all the tests using docker-compose v2 on Linux (where it hasn't been introduced yet to my knowledge?)

I followed the linux instructions in https://github.com/docker/compose-cli/blob/main/INSTALL.md but that doesn't do anything I can detect (curl -L https://raw.githubusercontent.com/docker/compose-cli/main/scripts/install/install_linux.sh | sh) (and doesn't enable the docker compose command either).

How can I use docker-compose v2 on Linux?

[ibnesayeed]

As per https://docs.docker.com/compose/cli-command/#install-on-linux

$ mkdir -p ~/.docker/cli-plugins/
$ curl -SL https://github.com/docker/compose-cli/releases/download/v2.0.0-rc.1/docker-compose-linux-amd64 -o ~/.docker/cli-plugins/docker-compose
$ chmod +x ~/.docker/cli-plugins/docker-compose

Note: The version number may change, obviously!

[rfay]

Hmm, after taking those actions on Ubuntu 20.04 I see:

docker-compose --version
docker-compose version 1.28.5, build c4eb3a1f

I do see that docker compose then becomes a thing, but docker-compose is unaffected AFAICT.

Also, would be good to maintain the INSTALL.md

[ibnesayeed]

... but docker-compose is unaffected AFAICT.

Yes, that's a separate tool and can co-exist (for now).

[rfay]

The question here is "How to install docker-compose v2 on Linux"

Hundreds or thousands of tools wrap docker-compose. An installation technique to make compose-cli be "docker-compose" is essential for those tools.

[thaJeztah]

Let me copy my comment from docker/docker-ce-packaging#553 (comment)

On linux, we could document creating an alias;

alias docker-compose="docker compose"

or to set it automatically for new sessions (for Bash)

echo 'alias docker-compose="docker compose"' >> ~/.bashrc

Or zsh:

echo 'alias docker-compose="docker compose"' >> ~/.zshrc

If you take the .bashrc or zshrc approach, that file needs to be "reloaded" to take effect for the current shell, by sourcing it;

source ~/.bashrc

source ~/.zshrc

[rfay]

So there are a number of problems with this approach.

1. It requires changing the full environment of an unknown user.
2. It assumes that we know that a user uses bash
3. It assumes a logged in user.

I really recommend a more robust wrapper that will let tools in the Linux world move forward. All it takes is a simple script or binary that replaces the original docker-compose.

[thaJeztah]

A separate "compatibility package" could be possible, but if docker-compose v1 is not deprecated, it should not come by default.

For Docker Desktop, the installation is somewhat more "opinionated", but for a Linux server install, things are more involved. Docker itself has not shipped docker-compose .deb or .rpm packages, but some Linux distributions have. While we (once stable) would like to see users migrate to v2, the v2 and v1 versions do not have to conflict (both can be used, and it's possible users have a reason to use the python version).

Adding the wrapper to the default package means we will have to add a Conflicts: or Deprecates: annotation to the .rpm or .deb packages, which means the package cannot be installed without uninstalling any existing docker-compose (which could be a distro package).

Things become more involved if the user has docker-compose installed from a binary or through pip, because the .deb or .rpm package managers will not be aware of that binary to be present.

So yes, possibly a "compatibility" package could be created (although it would be just a script doing the same as an alias). That package would be an optional install (user to opt-in), and that package could Conflict with distro packages (that we know of), but would probably not resolve the "manual" and "pip" installs. For those, "document how to migrate from v1 to v2" would (I think) be the only solution.

So even with the above, I don't think we can resolve the "It requires changing the full environment of an unknown user." situation. It will be difficult / impossible to make any assumptions about a user's configuration.

[rfay]

So even with the above, I don't think we can resolve the "It requires changing the full environment of an unknown user." situation. It will be difficult / impossible to make any assumptions about a user's configuration.

What I'm saying is you can't use shell workarounds to solve this problem. You have to use a binary wrapper or something. Shell workarounds are fine for individual users trying to solve particular problems, but they don't solve a migration problem for an important tool that is deployed in thousands of different contexts.

[thaJeztah]

I don't see why a shell script wouldn't work

$ cat /usr/bin/wait

#!/bin/sh
builtin wait "$@"

$ cat /usr/bin/gunzip | grep exec
exec gzip -d "$@"

[rfay]

Of course I'm talking about a docker-compose equivalent distributed in a standard way by the Docker organization.

[ndeloof]

Compose v2 is a CLI plugin, just download it from the release page under ~/.docker/cli-plugins/docker-compose. Install script is for the Compose CLI ("Cloud Integrations") which require a more complex setup.

see https://github.com/docker/compose-cli#compose-v2-aka-local-docker-compose for more details. We plan to move compose v2 into a separate repository ASAP to avoid confusion with this installation process

[ndeloof]

Also see https://docs.docker.com/compose/cli-command/#install-on-linux

[mat007]

@ndeloof yes but then you can’t use docker-compose anymore, you need to type docker compose .
I think what @rfay is asking for is a linux version of the switch/shim that Desktop ships.

[ndeloof]

@mat007 makes sense. Unfortunately this codebase has been designed to support canary testing, but we could extract the core redirection logic into a public component as part of compose.v2 codebase

[rfay]

The shortest-term view is I'd like to be able to run all ddev tests against compose v2 on Linux... because github actions is there and free. That's just to see if we can finally get compose v2 compatible and not have to embargo it.

But the long term view is... surely you don't want Linux users of docker-compose to stay on v1 because you've never provided a migration path? It seems like docker-compose on linux deserves first-class status. And yes, I know that supposedly everybody can just start using docker compose IF you package that, which you're not yet if I understand. But since every user of docker-compose has usages with docker-compose wired into it, that migration may never take place and all linux will stay on v1.