11–20 of 41 posts
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
[0] https://blog.linuxserver.io/2019/02/21/the-lsio-pipeline-pro...
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
Neat! I'd like to get some automated multi-arch image builds going too. I'll give GitHub Actions a go using your repo as reference.
Earlier quoted context omitted.
Neat! I'd like to get some automated multi-arch image builds going too. I'll give GitHub Actions a go using your repo as reference.
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…
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.
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…
Please go to NixOS.org. The Nix package manager, Nixpkgs package set, and NixOS distribution is exactly what you want.
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…
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.)
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.
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.