Docker-compose 2.0

[Akira]

Well, I know it's a little early to jump onto the 2.0 bandwagon, however I attempted to run my normal update for docker-compose:

version=$(curl -s https://api.github.com/repos/docker/compose/releases/latest | jq -r .tag_name) && sudo curl -L "https://github.com/docker/compose/releases/download/${version}/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

If I try to run docker-compose after that I get:
/usr/local/bin/docker-compose: line 1: Not: command not found
When roll back to 1.29.2 it all works perfectly again.

Any ideas as to what I'm doing wrong? (Other than trying to keep software completely up to date ofc).

 

[one-eyed-king]

The problem is a different one than you think:
cat /usr/local/bin/docker-compose

$(uname -m) will render x86_64, which was correct up to 1.x releases.
In 2.0 they switched the last part of the filename to amd64.

 

[Akira]

@one-eyed-king so if I'm understanding things correctly it now becomes:

version=$(curl -s https://api.github.com/repos/docker/compose/releases/latest | jq -r .tag_name) && sudo curl -L "https://github.com/docker/compose/releases/download/${version}/docker-compose-$(uname -s)-amd64" -o /usr/local/bin/docker-compose

Which works,
However now I get:

/volume2/docker/compose$ docker-compose up -d
unknown shorthand flag: 'd' in -d
See 'docker --help'.

docker-compose up
also fails as does
docker compose up
There is obviously information following about various commands which I've cut to save space.
Looks like I need to do further digging.

OK looks like I may have found it... It's now a CLI plugin:

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

and
docker compose up -d now works!!!
Although first run recreated ALL of my containers.

So, my new bash aliases are:

alias doccomup='version=$(curl -s https://api.github.com/repos/docker/compose/releases/latest | jq -r .tag_name) && sudo curl -L "https://github.com/docker/compose/releases/download/${version}/docker-compose-$(uname -s)-amd64" -o ~/.docker/cli-plugins/docker-compose'

to update docker-compose and:

alias dcpup='docker compose pull && docker compose up -d && docker system prune'

To update all my default containers and cleanup after.

 

[one-eyed-king]

You are almost there ^^

Now you replaced $(uname -s)-$(uname -m) with amd64, whereas you only need to replace $(uname -m) with amd64 (like mentioned in my previous post)

I hope you are not just doing guesswork, and instead checked the github release page to actualy see what filenames are used.

 

[Akira]

@one-eyed-king it was simply me removing too much information, not had enough coffee yet.
I believe I now have it all working, it would be helpful if what I've done could be double checked by someone with better knowledge so it may help others.
I have to say I do like the changes in v2 (at least thus far) the process has far more information attached, e.g. time taken and what each container is doing at any given stage.

 

[one-eyed-king]

Docker compose is a cli plugin now? From the inplace update of your previous post, it seems it is now.

Docker recently introduced docker compose (as in subcommand of the docker cli), which aims for cloud provider deployments, whereas docker-compose is the the single node orchestrator most people require and use.

I will validate and verify your approach later. One thing to note is that the output filename requires the folder to be pre-created for a successful download.

Since you managed to deploy your compose files with it, it seems the limitation of cloud provider deployments is not true anymore. Exciting change, finaly docker compose and docker stack deployments are handeld the same way. To be honest, docker-compose was adopted by docker and does not allign with the rest of their tooling... everything else has been written in go, while docker-compose based on python.

 

[one-eyed-king]

lgtm if you add the mkdir in the beginning and chmod part at the end:

Run as root or user (if your user is allowed to access the docker.sock)

alias doccomup='mkdir -p ~/.docker/cli-plugins/ && version=$(curl -s https://api.github.com/repos/docker/compose/releases/latest | jq -r .tag_name) && curl -L "https://github.com/docker/compose/releases/download/${version}/docker-compose-$(uname -s)-amd64" -o ~/.docker/cli-plugins/docker-compose && chmod +x ~/.docker/cli-plugins/docker-compose'

 

[Akira]

Cool, thank you @one-eyed-king.

 

[Akira]

FYI they've now changed it back.. So
the amd64 goes back to $(uname -m)

 

[one-eyed-king]

awesome. So appearently someone use the wrong tool chain to build the artifacts. Hurray.

At least it's predictable again