31–40 of 41 posts
As an aside, is this the new pipe curl to sudo bash? docker run --rm --privileged docker/binfmt:66f9012c56a8316f9244ffd7622d7c21c1f6f28d
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.
Earlier quoted context omitted.
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.
Sure you can - first pull, then there's many tools to help you. For example https://github.com/larsks/undocker/
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.
As an aside, is this the new pipe curl to sudo bash? docker run --rm --privileged docker/binfmt:66f9012c56a8316f9244ffd7622d7c21c1f6f28d
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.
Earlier quoted context omitted.
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.
Sure you can - first pull, then there's many tools to help you. For example https://github.com/larsks/undocker/
Earlier quoted context omitted.
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…
Concur. Docker the runtime is unnecessary, but the day I started with Dockerfiles was the day I stopped building my chroots with Makefiles.
Earlier quoted context omitted.
What functionality are you missing?
Being built on standardized container technology. Also support for Windows builds would be nice.
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
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…
This is kind of what skaffold does. Check it out if you haven't.
Earlier quoted context omitted.
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…
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.
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.
Earlier quoted context omitted.
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 th…