docker run --rm --privileged docker/binfmt:66f9012c56a8316f9244ffd7622d7c21c1f6f28dYet the generic/debian10 and centos/7 images I otherwise use require no such privilege escalation to function.
It seems unnecessary and dangerous, I refuse to use such images if possible. But I did also setup a sudoers config to allow only the NFS commands that they need, just in case.
Point being that all these new tools we're using involve a lot of trust. Many of them can be treated just like curl piping to bash.
[0] https://blog.linuxserver.io/2019/02/21/the-lsio-pipeline-pro...
The docker build cache, and dockerizarion of tools, has made building, testing, and deploying software so much simpler. Unfortunately the next step in build systems (in my opinion) still has the mentality that people want to have mutable state on their host systems.
I hope someone extends BuildKit into a system like Bazel. All rules can be executed in containers, all software and deps can be managed in build contexts, you automatically get distributed test runners/builds/cache by talking to multiple docker daemons, etc.
I used to think of this process as a sort of reverse engineering exercise. To figure out what a CPU was doing, you needed to understand the architecture of the CPUs used by the people who were designing it. It was as though you were trying to reverse engineer a car engine using a hand-held computer; to understand how the engine worked you needed to understand how the car engine.
It could have been improved by some performance benchmarks showing cross compilation performance in comparison with this emulation based solution. I find it hard to believe it makes sense to emulate when native performance is available.
For example, with the RaspberryPi I can grab a Raspbain image, add binfmt and qemu on my host and with a few small changes to the image chroot in to a ready made build environment for the Pi that's faster and more convenient than compiling on the Pi. Setting up a cross compile environment for the Pi is much harder.
Docker is totally unnecessary BTW.
Modern languages are even easier. I can build a Go binary for the Raspberry Pi by setting one or two environment variables; "GOARCH=arm GOOS=linux go build ./whatever". Wonderful.
The Raspberry Pi has improved since the original. I recently needed llvm compiled from source and it only took on the order of hours on a Pi 4. (GCC was unusable, though; uses too much memory. Had to use clang from the package manager to build a new LLVM. The efficiency was impressive.)
If you want to get extremely small docker images you might also want to take a look at Google's distroless images and using mutlistage builds.
Are there ones that don't that you know of? This will be for an intranet registry, so the isolation doesn't buy much.
Thanks! re:the other suggestions, I will look into those.
I’m having okay luck with alpine base images right now, but app versions are less flexible.
You can also pull via the sha rather than the tag, which gives you significant extra assurance.
docker pull docker/binfmt@sha256:5a9ad88945dff7dc1af2ef7c351fe3dd9f7c874eb2c912c202ced088d21c178a
Once you've confirmed you're happy with the script, I don't believe there is any issue with automating this.
docker run --rm --privileged docker/binfmt:@sha256:5a9ad88945dff7dc1af2ef7c351fe3dd9f7c874eb2c912c202ced088d21c178a
In theory, the underlying container cannot be changed, which is what most of the issues with piping curl into bash is.
If you need to create Docker or OCI image you can use nixpkgs functions[1][2]
As for Windows, yeah, it's not natively supported, I see there's an issue opened, but no idea when a support would be added.
There's also this[3] not sure if suitable for what you need. My understanding is that it allows building for Windows targets on Linux.
[1] https://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools
1. None of your image layers are the same between builds (ADD as one of the first instructions for instance)
2. You are distributing your code to many people and they are building them into entirely separate accounts. (you send me your code and I build, tag, and push it to my dockerhub account).
There's two commands: `docker save` and `docker load`. It tars the history, layers, etc into a single file. You can further compress it for distribution. I've had a lot of luck with it.
Your client would then download your source, `docker load` your prebuilt copies to warm their cache, make their modifications, and further builds would be much faster.
They'd still pay that first penalty for pushing to their internal registry but that shouldn't take too long since that's essentially just a file copy.