Create buildx image

[crazy-max]

Fixes #647

Could be used like this:

FROM docker
COPY --from=docker/buildx:latest /buildx /usr/libexec/docker/cli-plugins/docker-buildx

e.g. https://hub.docker.com/r/crazymax/buildx/tags?page=1&ordering=last_updated

cc @chris-crone

Signed-off-by: CrazyMax crazy-max@users.noreply.github.com

[tonistiigi]

As this is not a runnable image it might lead to even more confusion. Maybe if it was under a different name that makes it more clear. But logically it should just be inside the docker image(or image that contains both).

[crazy-max]

As this is not a runnable image it might lead to even more confusion. Maybe if it was under a different name that makes it more clear.

Agree, changed to docker/buildx-bin if it makes sense.

But logically it should just be inside the docker image(or image that contains both).

I think we can start with a dedicated non-runnable buildx image for now and could be included later in the official docker image using COPY --from? See also docker-library/docker#243.

[tonistiigi]

SGTM

@AkihiroSuda @chris-crone

[chris-crone]

SGTM as buildx can be used standalone. I agree with @tonistiigi that we should have everything in the docker image and that should be most people's default.

[maniator]

As this is not a runnable image it might lead to even more confusion. Maybe if it was under a different name that makes it more clear. But logically it should just be inside the docker image(or image that contains both).

Agreed

[maniator]

SGTM as buildx can be used standalone. I agree with @tonistiigi that we should have everything in the docker image and that should be most people's default.

Cant we do something like I did here? https://hub.docker.com/r/maniator/dind-buildx

[crazy-max]

@chris-crone has created the secrets. SGTM to merge.

[tonistiigi]

As this is not a runnable image it might lead to even more confusion. Maybe if it was under a different name that makes it more clear. But logically it should just be inside the docker image(or image that contains both).

I'm starting to change my mind about this one. It might be kind of useful to have it for working with remote instances or testing out various versions with docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock docker/buildx . That image should be on top of alpine and, contain ca-certificates etc. We also need to improve the ux. We can inject environment variable into container so that if image gets run without a correct endpoint it would show messages about the docker flags that need to be exposed (eg. docker socket or if context is empty then volume for that or same for credentials). I guess same could be possible when image runs in k8s pod but because k8s API is authenticated I don't think it is as common as docker.sock.

Would be cool if docker run --privileged docker/buildx would also work without any docker socket or remote address. I guess with process driver #21 . We do ship daemonless buildctl script with moby/buildkit but that is buildctl and doesn't have a good ux. Maybe a special tag that contains buildkit binaries already so they don't need to be pulled on each invocation.

That doesn't change that buildx should be included in docker image.