buildx

The metadata check is part of the builds image pull process. The step can resolve a `FROM repo/image:tag` reference to the content sha the tag points to, and then if required fetch the content. In any case, recent-ish (maybe 24+) versions of docker default to a "prefer local" mode in buildkit so a local cached entry will be returned first if possible before any remotes are resolved. Out of interest, what docker/buildx/buildkit versions were attempting the connection? We ran into this on some container builds that run offline last year some time and I'm wondering if it was due to some ancient docker, as that flag appears useless on current docker. - https://github.com/docker/buildx/blob/7b1ec7211d871dfba53b10...

This is great! I’ve been waiting a long time for this and it seems like more debug features are in the pipeline too: https://github.com/docker/buildx/issues/1104 Docs: https://docs.docker.com/engine/reference/commandline/buildx_...

and its "oh, you want multi-arch, do you?" friend. While prosecuting this <https://gitlab.com/gitlab-org/gitlab/-/issues/339567> I learned that they bundle binfmt into the buildkit docker image <https://github.com/moby/buildkit/blob/v0.12.5/Dockerfile#L11...> which itself is compiled against a static copy of qemu <https://github.com/tonistiigi/binfmt/blob/deploy/v6.2.0-26/D...> with various /proc/sys/fs/binfmt_misc wizardry <https://github.com/tonistiigi/binfmt/blob/deploy/v6.2.0-26/c...> We ended up switching to using multiarch/qemu-user-static:7.2.0-1 <https://hub.docker.com/layers/multiarch/qemu-user-static/7.2...> which also mutates binfmt_misc in buildx's context in order to exec the static copy of qemu in it but I find their shell script much more legible about what's going on: <https://github.com/multiarch/qemu-user-static/blob/v7.

You can! It's experimental but https://github.com/docker/buildx/pull/1168 Tracking for this: https://github.com/docker/buildx/issues/1104

I don't like the way docker buildx works at the moment. Hopefully it improves over time. My biggest complaint is that everything is baked into a single command instead of being discreet commands. So instead of: docker build... docker tag... docker push... it's: docker buildx build --tag... --push... Most CI systems do something similar and you end up with an awful, monolithic build step that's essentially 'build-and-test-and-tag-and-push'. It's the same on every platform too. GitHub Actions, GitLab CI, Drone CI, etc. all seem to do the same thing. What if I want to build in one environment that pushes and one environment that doesn't? In my experience it's much easier if 'push' can be a build step on it's own because the CI system will usually have conditional support for things like different environments. From wha

Just to follow up on my own question (though I appreciate the siblings): I found this article with some overview and example command lines: https://www.docker.com/blog/multi-arch-images/ . As best I can tell, you don't actually need a custom builder. You can just skip the `docker buildx create` and go straight to `docker buildx build` after one workaround below. I needed the workaround from this comment to make it work (to install qemu? not sure): https://github.com/docker/buildx/issues/495#issuecomment-754... Overall a very slick experience for going from zero to multiarch containers. Well done, Docker.

Docker's build system has been given a huge overhaul and does create a dependency tree. It is highly efficient and even does things like support mounts for caching package downloads, build artifacts, etc. See https://github.com/moby/buildkit. You can enable it today with `DOCKER_BUILDKIT=1 docker build ...` There is also buildx which is an experimental tool to replace `docker build` with a new CLI: https://github.com/docker/buildx

I highly recommend checking out https://github.com/docker/buildx . It’s still in tech preview but it’s an exciting look at the future of docker-build.