A decade of Docker containers • Hacker News Board

Re: A decade of Docker containers

#101

Post by Hackbraten » Sat, Mar 07, 2026, 8:35 PM UTC

esseph wrote: post #82

Hackbraten wrote: post #54

Earlier quoted context omitted.

> Not to mention better utilization of hardware When compared to a VM, yes. But shipping a separate userspace for each small app is still bloat. You can reuse software packages and runtime environments across apps. From an I/O, storage, and memory utilization point of view, it feels baffling to me that containers are so popular.

> From an I/O, storage, and memory utilization point of view, it feels baffling to me that containers are so popular. Why? It's not virtualization, it's containerization. It's using the host kennel. Containers are fast.

I was referring to the userspace runtime stack, not the kernel. What I criticize is that multiple containers that share a single host usually overdo it with filesystem isolation. Hundreds of MBs of libraries and tools needlessly duplicated, even though they could just as well have used distro packages and deployed their apps as system-level packages and systemd unit files with `DynamicUser=`.

You can hardly call this efficient hardware utilization.

Re: A decade of Docker containers

#102

Post by kgwgk » Sat, Mar 07, 2026, 8:37 PM UTC

avsm wrote: post #62

throwawaypath wrote: post #50

Earlier quoted context omitted.

>massive block devices assembled using Vagrant and Packer has thankfully been avoided... Funny comment considering lightweight/micro-VMs built with tools like Packer are what some in the industry are moving towards.

And those lightweight VM base images are possible because Docker applied a downward pressure on OS base image sizes! Alpine Linux doesn't get enough credit for this; in addition to being a great base image, it was also the first distro to prioritise fast and small image creation (Gentoo and Arch were small, but not fast to create).

Maybe in that alternative future of massive block devices some downward pressure on image sizes would have been applied just the same.

Re: A decade of Docker containers

#103

Post by yunwal » Sat, Mar 07, 2026, 8:40 PM UTC

phplovesong wrote: post #66

bmitch3020 wrote: post #26

I've seen countless attempts to replace "docker build" and Dockerfile. They often want to give tighter control to the build, sometimes tightly binding to a package manager. But the Dockerfile has continued because of its flexibility. Starting from a known filesystem/distribution, copying some files in, and then running arbitrary commands within that filesystem mirrored so nicely what operations has been doing for a l…

You can pretty much replace "docker build" with "go build". But as long as people want to use scripting languages (like php, python etc) i guess docker is the neccessary evil.

> You can pretty much replace "docker build" with "go build".

Interesting. How does go build my python app?

Re: A decade of Docker containers

#104

Post by avsm » Sat, Mar 07, 2026, 8:43 PM UTC

kgwgk wrote: post #102

avsm wrote: post #62

Earlier quoted context omitted.

And those lightweight VM base images are possible because Docker applied a downward pressure on OS base image sizes! Alpine Linux doesn't get enough credit for this; in addition to being a great base image, it was also the first distro to prioritise fast and small image creation (Gentoo and Arch were small, but not fast to create).

Maybe in that alternative future of massive block devices some downward pressure on image sizes would have been applied just the same.

It's not as easy; a block device has to be bootable and so usually bundles a kernel (large). And because the filesystem inside is opaque, you can't do layering like Docker does easily via overlayfs and friends. libguestfs does a heroic job of making VM images easier to manipulate from code, but it's an uphill battle...

Re: A decade of Docker containers

#105

Post by tzs » Sat, Mar 07, 2026, 8:44 PM UTC

I've not done serious networking stuff for over two decades, and never in as complex an environment as that in the article, so the networking part of the article went pretty much over my head.

What I want to do when running a Docker container on Mac is to be able to have the container have an IP address separate from the Mac's IP address that applications on the Mac see. No port mapping: if the container has a web server on port 80 I want to access it at container_ip:80, not 127.0.0.1:2000 or something that gets mapped to container port 80.

On Linux I'd just used Docker bridged networking and I believe that would work, but on Mac that just bridges to the Linux VM running under the hypervisor rather than to the Mac.

Is there some officially recommended and supported way to do this?

For a while I did it by running WireGuard on the Linux VM to tunnel between that and the Mac, with forwarding enabled on the Linux VM [1]. That worked great for quite a while, but then stopped and I could not figure out why. Then it worked again. Then it stopped.

I then switched to this [2] which also uses WireGuard but in a much more automated fashion. It worked for quite a while, but also then had some problems with Docker updates sometimes breaking it.

It would be great if Docker on Mac came with something like this built in.

[1] https://news.ycombinator.com/item?id=33665178

[2] https://github.com/chipmk/docker-mac-net-connect

Re: A decade of Docker containers

#106

Post by diroussel » Sat, Mar 07, 2026, 8:50 PM UTC

arcanemachiner wrote: post #35

Normal_gaussian wrote: post #15

Earlier quoted context omitted.

Exactly. "so I hung the radiator out the window" vibes.

I am trying to decipher the meaning of your comment, to no avail.

So you’ve never improvised an air conditioning system from a spare bilge pump, a propane tank and a cast iron radiator?

Sir, this is a hacker news.

Re: A decade of Docker containers

#107

Post by callamdelaney » Sat, Mar 07, 2026, 8:50 PM UTC

The fact that docker still, in 2026, will completely overwrite iptables rules silently to expose containers to external requests is, frankly, fucking stupid.

Re: A decade of Docker containers

#108

Post by andrewmcwatters » Sat, Mar 07, 2026, 8:59 PM UTC

the__alchemist wrote: post #3

I'm optimistic we will succeed in efforts to simplify linux application / dependency compatibility instead of relying on abstractions that which work around them.

[dead]

Re: A decade of Docker containers

#109

Post by pixelmonkey » Sat, Mar 07, 2026, 8:59 PM UTC

The math of “a decade” seemed wrong to me, since I remembered Docker debuting in 2013 at PyCon US Santa Clara.

Then I found an HN comment I wrote a few years ago that confirmed this:

“[...] I remember that day pretty clearly because in the same lightning talk session, Solomon Hykes introduced the Python community to docker, while still working on dotCloud. This is what I think might have been the earliest public and recorded tech talk on the subject:”

YouTube link: https://youtu.be/1vui-LupKJI?t=1579

Note: starts at t=1579, which is 26:19.

Just being pedantic though. That’s about 13 years ago. The lightning talk is fun as a bit of computing history.

(Edit: as I was digging through the paper, they do cite this YouTube presentation, or a copy of it anyway, in the footnotes. And they refer to a 2013 release. Perhaps there was a multi-year delay between the paper being submitted to ACM with this title and it being published. Again, just being pedantic!)

Re: A decade of Docker containers

#110

Post by zbentley » Sat, Mar 07, 2026, 9:06 PM UTC

esseph wrote: post #64

zbentley wrote: post #33

Earlier quoted context omitted.

> the Dockerfile has continued because of its flexibility I wish we had standardized on something other than shell commands, though. Puppet or terraform or something more declarative would have been such a better alternative to “everyone cargo cults ‘RUN apt-get upgrade’ onto the top of their dockerfiles”. Like, the layer/stage/caching behavior is fine. I just wish the actual execution parts had been standardized usi…

The more you try and abstract from the OS, the more problems you're going to run into.

Bash is pretty darn abstracted from the OS, though. Puppet vs Bash is more about abstraction relative to the goal.

If your dockerfile says “ensure package X is installed at version Y” that’s a lot clearer (and also more easy to make performant/cached and deterministic) than “apt-get update; apt-get install $transitive-at-specific-version; apt-get install $the-thing-you-need-atspecific-version”. I’m not thrilled at how distro-locked the shell version makes you, and how easy it is for accidental transitive changes to occur too.

But neither of those approaches is at a particularly low abstraction level relative to the OS itself; files and system calls are more or less hidden away in both package-manager-via-bash and puppet/terraform/whatever.