Build and push docker/docker-compose images upon release

[nicksieger]

What I did

Add release-image bake target and bin-image ci workflow for pushing docker/docker-compose image.

Related issue

(not mandatory) A picture of a cute animal, if possible in relation with what you did

[nicksieger]

The base image is go/alpine, with docker and git installed in it. Anything else that we think should go in here?

[thaJeztah]

I notice we're installing docker from alpine's apk repositories, which are builds of docker built by alpine. Perhaps that's ok for testing, but we definitely should not ship those as part of images for end-users.

Having a "runnable" compose image with docker installed basically replicates the official docker:cli image; see docker-library/docker#369

[nicksieger]

Good point, I think basing compose off the official docker cli image would be a lot better.

[nicksieger]

Oh, nevermind! Compose is in the latest docker:*-cli images. Then I'll see if we can use that.

[crazy-max]

Don't think it makes sense to create a runnable image for compose. An artifact image with base scratch and the binary like buildx is enough imo. See also docker/buildx#656. This way user can choose whatever base they want like the docker one:

FROM docker
COPY --from=docker/compose-bin /docker-compose /usr/libexec/docker/cli-plugins/
RUN docker compose version

Also update docs to show how to use it inside an image. See https://github.com/docker/buildx#dockerfile.

About hub slug might be better to have smth like buildx I think: docker/compose-bin. And makes clear in repo description that this is a non-runnable image: https://hub.docker.com/r/docker/buildx-bin.

[thaJeztah]

About hub slug might be better to have smth like buildx I think: docker/compose-bin. And makes clear in repo description that this is a non-runnable image: https://hub.docker.com/r/docker/buildx-bin.

👆 good point to use a different name for the image, as there's the existing "compose" image, which was a bit of a hack to run compose as container instead of installing (to be used in combination with this script: https://github.com/docker/compose/blob/1.29.2/script/run/run.sh) and users may expect it to be a replacement for that.

[laurazard]

We want to have a runnable docker/docker-compose image is so we can run it in a container for the dev-envs compose stack workflows, as opposed to the current scenario where code is being copied into the host and running compose from there.

An artifact image like you're suggesting could be useful for users to build upon, but I believe it still makes sense for us to have a runnable image (and we'd still want to have one regardless to move the above mentioned workflow from the host -> containers).

[thaJeztah]

compose is now part of the docker, so the best option for that is the official docker:cli image I mentioned above.

[thaJeztah]

Let me also /cc @tianon for help with that image; I know the current images for "cli" contain the daemon as well; this should change soon for the next engine release, but perhaps we can already update for the current release.

[tianon]

I know the current images for "cli" contain the daemon as well; this should change soon for the next engine release, but perhaps we can already update for the current release.

This was fixed in docker-library/docker#369! 😄

(and Compose v2 has been part of the images since docker-library/docker#361, both as docker compose and as docker-compose, and it should stay aggressively up-to-date with the latest releases 👍)

[nicksieger]

(and Compose v2 has been part of the images since docker-library/docker#361, both as docker compose and as docker-compose, and it should stay aggressively up-to-date with the latest releases 👍)

Excellent, thanks @tianon