This reminds me of how some vagrant images run scripts. Maybe all of them. I started using vagrant a month ago and recently noticed that the official debian/buster64 image wants to run a script with sudo.
Yet 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.
Except you cannot even look at the contents of the file being piped beforehand and hope that the same file is downloaded when you actually pipe it. It's more like running setup.exe using the administrator account.
I've been leveraging docker buildx to create multi architecture images for a few months. It's quite nice and simple, and I've been able to even automate the multiarch builds with GitHub Actions. See an example repo of mine here: https://github.com/jmb12686/docker-cadvisor
Here's another repo of mine doing (essentially) the same thing, multi arch image build using GitHub Actions. There is a bit more documentation in this repo regarding local builds though: https://github.com/jmb12686/node-exporter
I wish there was something like Bazel, Buck, Pants, or Please built on top of docker/crio.
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.
The docker build cache alone feels like magic for long (from scratch) builds. It feels tedious breaking out individual steps but I’ve yet to regret the extra effort.
In other contexts, Cow snapshots such as those provided by LVM or ZFS etc can provide similar effect by naming the snapshot after the hash of the code to execute to build it
Well, if one of your criteria is to build in docker you should use a docker. I mean if one of my requirement was that program should be written in Python I would write it in Python.
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.
I just took a look at Skaffold. I don't think this is what I want. Skaffold does not look like the right solution of a monorepo with code gen, dependencies, and complex build processes. It looks like it's the right tool for a bunch of folders containing Dockerfiles and build contexts.
The original purpose of most computer programmers was to write a program that would solve an immediate technical problem or a business requirement. The programmer was not concerned with the "technical" (though still important) question: What architecture is this CPU going to use? The first time a programmer encountered the question, his reaction was to try to compile a program that would run on the CPU.
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.
Interesting article but I can’t understand why cross compilation is dismissed.
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.
Cross compiling is a lot more difficult to set up. Emulation let's you use much of the target system's tools as is. Cross compiling means you have to build all of those tools for the host system.
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.
I've honestly never had a problem cross-compiling for the Raspberry Pi. I learned my lesson back when it first came out; I needed a new ntpd and it took 24 hours to build on the Pi. I then realized the settings were wrong and spent about 20 minutes setting up the cross-compilation machinery on my x86 Linux box instead of waiting another day. "apt-get install crossbuild-essential-armhf" and some configuration and your build is done in seconds. Well worth it.
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.)
Finding the right parameters to cross compile each dependency you need is tedious. Sure some packages are easy to cross compile but it's much easier to set up an emulated build environment and then compile everything normally.
A Makefile tracks a dependency tree and rebuilds what has changed. Docker has a dependency list and has to rebuild everything following any change. Seems to me like we've gone backwards.
I have used docker with qemu syscall emulation to build various projects for foreign architectures. I really wanted to cross-compile, but the build tools chosen by those projects made it infeasibly difficult.
Anyone know how to get smaller docker images? I thought if I had all the previous layers in the docker registry that an upload would just be the size of the diff of the new layer, but this seems to never work.
Some docker registries isolate the layer cache per account to prevent cache poisoning attacks and data leaks. This means you might only take advantage of the registry caching if you have already pushed the first version of a tagged image.
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.
GCR boasts it has a global layer cache. Also, this is a thing that should only ever effect your very first push. You should only be seeing it twice if:
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).
Unfortunately, choice 2 sounds like us. I was looking for some way to short-circuit that (by maybe shipping the repo already loaded) as the product runs in the customer's cloud, and the images are built on their machines.
If that's the case you could give them a pre-built copy of your containers (assuming your builds take a very long time this might be worth it).
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.
If you can get all of your images on the same machine to use the same base, you’ll get somewhere. Being careful of layer order, using a script to run the most disk-intensive layers also helps.
I’m having okay luck with alpine base images right now, but app versions are less flexible.
