Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A decade of Docker containers

cacm.acm.org

Post reply on HN
Print view View original

171–180 of 275 posts

Re: A decade of Docker containers

#171

Post by hsbauauvhabzb »

bmitch3020 wrote: post #137
__MatrixMan__ wrote: post #63

Earlier quoted context omitted.

There are some hurdles preventing that flow from achieving reproducible builds. As the bad guys get more sophisticated, it's going to become more and more important that one party can say "we trust this build hash" and a separate party to say "us too". That's not going to work if both parties get different hashes when they build the image, which won't happen as long as file modification timestamps (and other such haz…

Recent versions of buildkit have added support for SOURCE_DATE_EPOC. I've been making the images reproducible before that with my own tooling, regctl image mod [1] to backdate the timestamps. It's not just the timestamps you need to worry about. Tar needs to be consistent with the uid vs username, gzip compression depends on implementations and settings, and the json encoding can vary by implementation. And all this…

Does any of that matter if you’re not auditing the packages you install?

I’m more concerned about sources being poisoned over the build processes. Xz is a great example of this.

Re: A decade of Docker containers

#172

Post by atomicnumber3 »

NewJazz wrote: post #93
esseph wrote: post #80

Earlier quoted context omitted.

TBH I feel as if only docker belongs in that list. Guix and nix have users, sure, but not remotely like docker.

Yeah they are way better than docker for packaging

Why is docker used by far the most, then?

Re: A decade of Docker containers

#173

Post by eudamoniac »

I've been a professional in the industry for over a decade and I've still not found any meaningful benefit for learning or using containerization in the real world. I just install my dependencies with good old fashioned version managers (asdf) and I develop the project. I ignore all docker documentation, and everything works fine. When I try to use containers to develop, it's seemingly two dozen gotchas that sum up to my IDE needing endless configuration to function properly. I don't get it.

Re: A decade of Docker containers

#174

Post by justsomehnguy »

mrbluecoat wrote: post #4

> Docker repurposed SLIRP, a 1990s dial-up tool originally for Palm Pilots, to avoid triggering corporate firewall restrictions by translating container network traffic through host system calls instead of network bridging. Genuinely fascinating and clever solution!

Except it's the plain NAT which was named 'bridge' because there were no sysadmin around slap some sense into the authors. Slirp is for 'unprivileged network namespaces' which is for a 'rootless' variants of docker ie attaching a container network to the host without the need for the root-level privileges.

Re: A decade of Docker containers

#175

Post by netrem »

a_t48 wrote: post #150
netrem wrote: post #125

With ML and AI now being pushed into everything, images have ballooned in size. Just having torch as a dependency is some multiple gigabytes. I miss the times of aiming for 30MB images. Have others found this to be the case? Perhaps we're doing something wrong.

I’ve seen images that accidentally install tensorflow twice, too. It wouldn’t be so bad if large files were shared between layers but they aren’t. It’s bad enough that I’m building an alternative registry and snapshotter with file level dedupe to deal with it.

Sounds like it would be useful. Many common dev workflows started falling apart when it's not just tiny code files they need to deal with. In the python world, uv has helped massively, with pip we were seeing 30+ min build times on fairly simple images with torch

Re: A decade of Docker containers

#176

Post by scubbo »

eudamoniac wrote: post #173

I've been a professional in the industry for over a decade and I've still not found any meaningful benefit for learning or using containerization in the real world. I just install my dependencies with good old fashioned version managers (asdf) and I develop the project. I ignore all docker documentation, and everything works fine. When I try to use containers to develop, it's seemingly two dozen gotchas that sum up t…

Curious what you build/work on? If you're only shipping software library or tools, then yeah, your perspective makes sense - `asdf` or `mise` seem superior to `devcontainer`s. But I wouldn't want to deploy a web application without Dockerizing it.

Re: A decade of Docker containers

#177

Post by __MatrixMan__ »

hsbauauvhabzb wrote: post #171
bmitch3020 wrote: post #137

Earlier quoted context omitted.

Recent versions of buildkit have added support for SOURCE_DATE_EPOC. I've been making the images reproducible before that with my own tooling, regctl image mod [1] to backdate the timestamps. It's not just the timestamps you need to worry about. Tar needs to be consistent with the uid vs username, gzip compression depends on implementations and settings, and the json encoding can vary by implementation. And all this…

Does any of that matter if you’re not auditing the packages you install? I’m more concerned about sources being poisoned over the build processes. Xz is a great example of this.

Both are needed, but you get more bang for your buck focusing on build security than on audited sources. If the build is solid then it forces attackers to work in the open where all auditors can work together towards spoiling the attack.

If you flip it around and instead have magically audited source but a shaky build, then perhaps a diligent user can protect themself, but they do so by doing their own builds, which means they're unaware that the attack even exists. This allows the attacker to just keep trying until they compromise somebody who is less diligent.

Getting caught requires a user who analyses downloaded binaries in something like ghidra... who does that when it's much easier to just build them from sources instead? (answer: vanishingly few people). And even once the attacker is found out, they can just hide the same payload a bit differently, and the scanners will stop finding it again.

Also, "maybe the code itself is malicious" can only ever be solved the hard way, whereas we have a reasonable hope of someday providing an easy solution to the "maybe the build is malicious" problem.

Re: A decade of Docker containers

#179

Post by eudamoniac »

scubbo wrote: post #176
eudamoniac wrote: post #173

I've been a professional in the industry for over a decade and I've still not found any meaningful benefit for learning or using containerization in the real world. I just install my dependencies with good old fashioned version managers (asdf) and I develop the project. I ignore all docker documentation, and everything works fine. When I try to use containers to develop, it's seemingly two dozen gotchas that sum up t…

Curious what you build/work on? If you're only shipping software library or tools, then yeah, your perspective makes sense - `asdf` or `mise` seem superior to `devcontainer`s. But I wouldn't want to deploy a web application without Dockerizing it.

Mostly web applications actually. Most web stuff is not that complicated. Usually the deployment itself is from docker (ops insists) but I just do development without it and I've never had a problem. I understand in theory I could get mismatched versions of things from production and thereby introduce a bug; in practice this has never happened a single time.

Re: A decade of Docker containers

#180

Post by vatsachak »

poly2it wrote: post #148
muvlon wrote: post #128

Earlier quoted context omitted.

As a Nix evangelist, I have to say: Nix is really not capable of replacing languag-specific package managers. > running arbitrary commands to invoke language-specific package managers. This is exactly what we do in Nix. You see this everywhere in nixpkgs. What sets apart Nix from docker is not that it works well at a finer granularity, i.e. source-file-level, but that it has real hermeticity and thus reliable caching…

Well, arbitrary granularity is possible with Nix, but the build systems of today simply do not utilise it. I've for example written an experimental C build system for Nix which handles all compiler orchestration and it works great, you get minimal recompilations and free distributed builds. It would be awesome if something like this was actually available for major languages (Rust?). Let me know if you're working on…

crane

https://crane.dev/getting-started.html

Post reply on HN