Support and Document Both docker-compose and docker compose (Plugin) in IOTstack

[NossieUK]

On Raspberry Pi OS Bookworm, both docker-compose and docker compose are available. With Debian Trixie, only docker compose will be supported.

Requests:

Clearly document the difference between the two tools, and which is default on each OS version.

Add a setup check to show which tool is installed and active.

Would this be a big change or something that only impacts startup?

[Paraphraser]

I think you might have misunderstood the situation. Right now (on Bullseye and Bookworm, and probably on Buster too) if you use the "convenience script" (which both the IOTstack "install" script and PiBuilder do), you get docker and docker compose.

Only the plugin.

No docker-compose command.

Right now!

It's been that way for years.

However, both the IOTstack "install" script and PiBuilder also create a symbolic link so that docker-compose points to the compose plugin:

• install.sh
• `04_setup.sh

There is no reason why that scheme can't continue. There are just so many examples on the web that use docker-compose that it is, as the old and slightly gauche saying has it, pushing excrement uphill with a pointed stick to pretend otherwise.

Edit: For context, when I say "years", plugin support arrived on Oct 1st, 2021.

[Paraphraser]

And, just to make sure I hadn't shot my mouth off, I spun-up Trixie as a Proxmox guest. There was one issue in the PiBuilder 03 script where I had to remove software-properties-common from the list (can't remember what that does).

The 04 script didn't like the Python stuff so that's something I will have to get to the bottom of.

But I was able to iotstack_restore a backup from my live system and it all just worked.

In particular, docker-compose taking the stack up, docker compose taking it down again.

[NossieUK]

I am so sorry Phil - I appear to have wasted your time without doing my own research

I upgraded to Trixie as a test on one of my systems and the iotstack stopped working - I immediately assumed it was a new thing in Trixie - however I never tried to reinstall the iotstack script

Although I have now managed to break the virtual environment trying to test - so trixie must have broke something upgrading from bookworm \o/

apologies again though - thanks.

[Paraphraser]

No, not wasted. I always learn a lot from questions like this. I now know about that dependency in the 03 script. I also know the Python side of things is going to involve a bit of work.

[NossieUK]

thanks again .. strangely I could only get it to work after running this

sudo rm /usr/local/bin/docker-compose echo -e '#!/bin/bash\nexec docker compose "$@"' | sudo tee /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose

[Paraphraser]

so trixie must have broke something upgrading from bookworm

That's a definite possibility. My primary IoT systems are Raspberry Pis which are all currently running Bullseye. When I first started on the Pi path, 32-bit Buster was all the rage. When I upgraded to Bullseye, I rebuilt each system from scratch. I was following advice which said upgrading in situ is possible but not recommended.

Recently I've started to think about upgrading those IoT systems to Bookworm. I've never run anything other than Bookworm on Proxmox-VE so I'm quite happy with it and, other than finding the time, there's no reason not to upgrade. I took a test Pi which was running Bullseye and did an upgrade in situ to see what would happen. It looks like it is working but I keep finding things that aren't as I expect, beginning with NetworkManager not being there.

Thus I'm adding my voice to the people who say "possible but not recommended" and I'll take the time to rebuild my own systems from scratch.

thanks again .. strangely I could only get it to work after running this

Well, that makes no sense at all. This is from the Trixie system I spun up on Proxmox-VE the other day:

Putting both of these things together, I'm starting to wonder if your system has a much longer history and if, perhaps, you had some ancient versions of docker and/or docker-compose installed at one point.

docker-compose has been through three iterations (that I'm aware of). It started as a compiled binary, then became a Python script, then back to a compiled binary again.

On anything up to Bookworm (and possibly Trixie) if you do something like:

$ sudo apt install docker docker-compose

you get the 1st-gen docker-compose and that forces a permanent downgrade of docker, after which apt won't update either docker or docker-compose ever again. Unfortunately, examples installing docker-compose using apt are fairly common and they are wrong.

Now, PiBuilder has some scripts to deal with this. If any containers are running, you need to stop them. Then:

$ ~/PiBuilder/boot/scripts/helpers/uninstall_docker.sh
$ ~/PiBuilder/boot/scripts/helpers/uninstall_docker-compose.sh
$ sudo reboot
$ ~/PiBuilder/boot/scripts/04_setup.sh

The first script is fairly straightforward. It just does what the name implies.

The second script goes after all possible docker-compose iterations (compiled, Python, compiled) and clobbers them.

The reboot gets rid of dross that prevents a clean re-install.

The 04 script does a proper install of docker using the "convenience script" which brings in docker-compose-plugin, after which the symlink is set up.

The 04 script does a logout at the end (because it alters group membership) so you need to login again.

I've just run through that sequence on my Trixie system and it works.

---

Another possibility, I suppose, is your PATH is set in a way which I haven't considered. Have you tried:

$ which -a docker-compose

If you get more than one hit then that might explain some of what you are seeing. I would, however, not expect your approach of creating a bash script would have cured the problem because it would still be in the same relative position in your PATH.