Combining static tarball and default cli-plugins

[tonistiigi]

With docker/cli#3314 updates, there is an open question if we should do something with the static binary bundle. With that PR, in order to build with buildkit, buildx binary is needed. The packages already contain buildx, but the static tarball at https://download.docker.com/linux/static/stable/x86_64/ does not.

We should also take into account that more plugins like this will appear in the future. Compose rewrite in go is also a plugin, and Docker Desktop already ships with docker-scan with more coming in the future. The immediate concern for the 21.x release is buildx though.

The options are (comment if I missed any):

• Add the buildx to the current static tarball. It would be the 10th binary there. Probably the easiest solution.
• Create a special cli-plugins tarball. Currently containing buildx. Future additions would be added there.
• Create a cli tarball that contains cli and additional client-side binaries. This has been a requested outcome independently from this work to match the way packages are separated. If we want to do this eventually, then we might as well do these changes together now.
• Add static links from https://download.docker.com/linux/static to https://github.com/docker/buildx/releases https://github.com/docker/compose/releases and https://github.com/docker/scan-cli-plugin/releases . These already point to static binaries for all architectures and can be used directly when someone wants to curl a binary. We would not update these links with new docker releases.

There is also an option to not do anything and consider static binaries an advanced use case. When users can figure out how to download and configure them, they can figure out the same for other binaries as well.

Personally, I don't have a preference and would be ok with any of the options. We just need to make a conscious decision.

[crazy-max]

Looking at https://download.docker.com/linux/static/stable/x86_64/ it might make sense to have dedicated tarballs for plugins. Maybe one per-plugin:

• https://download.docker.com/linux/static/stable/x86_64/docker-buildx-0.7.1.tgz
• https://download.docker.com/mac/static/stable/x86_64/docker-buildx-0.7.1.tgz
• https://download.docker.com/win/static/stable/x86_64/docker-buildx-0.7.1.zip

[tiborvass]

@crazy-max As buildx becomes a required dependency on cli, I think it's better to put the buildx binary in the docker cli targz, otherwise it gives the false impression it's an optional extra.

[crazy-max]

@tiborvass Correct, maybe both? This way we could align our docs for "manual download": docker/docs#14092 (comment)

[wedi]

Thank you for tackling this @crazy-max and @thaJeztah

This issue is named

Combining static tarball and default cli-plugins

and you closed with the commit that adds buildx. Was this by accident or are there no plans anymore to align the plugins included in the static release with the installers that contain compose and docker-scan?

[thaJeztah]

The plan is to create separate tars for each; this allows the teams working on compose and scan to do releases (and publish them on download.docker.com) when they arrive; currently we're in a big "chicken-and-egg" situation where "releasing <plugin x>" or "there's a release of containerd" means "also need to do a new release of the CLI, and engine"