A decade of Docker containers • Hacker News Board

Re: A decade of Docker containers

#221

Post by JodieBenitez » Sun, Mar 08, 2026, 11:13 AM UTC

tripledry wrote: post #212

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…

What's a good alternative if I want to self host and convenience? I have some hobby sites I host on a VM and currently I use docker-compose mainly because it's so "easy" to just ssh into the machine and run something like "git pull && docker-compose up" and I can have whatever services + reverse proxy running. If I were to sum up the requirements it would be to run one command, either it succeeds or fails in it's ent…

I have some hobby sites I host on a raspberry pi and currently I use make mainly because it's so "easy" to just ssh into the machine and run something like "pip install thing.whl && sudo systemctl restart thing" and I can have whatever services + reverse proxy running.

Re: A decade of Docker containers

#222

Post by computerfriend » Sun, Mar 08, 2026, 11:41 AM UTC

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…

I'm not sure if I was just holding it wrong, but I couldn't create images reproducibly using Docker. (I could get this working with Podman/buildah however.)

Re: A decade of Docker containers

#223

Post by paddle_work » Sun, Mar 08, 2026, 12:01 PM UTC

[dead]

Re: A decade of Docker containers

#224

Post by phplovesong » Sun, Mar 08, 2026, 12:17 PM UTC

avsm wrote: post #81

phplovesong wrote: post #71

We have shipped unikernels for the last decade. Zero sec issues so far. I highly recommend looking into the unikernel space for a docker alternative. MirageOS being a good start.

cool! What services have you shipped as unikernels? Docker doesn't have to be an alternative; it can help with the build/run pipeline for them too: https://www.youtube.com/watch?v=CkfXHBb-M4A (Dockercon 2015!)

Mostly finance stuff, and all the sensitive stuff that comes with it.

But the main benefit is the attack surface is greatly reduced when running a unikernel. Also we use way less resources and get really good perf.

Re: A decade of Docker containers

#225

Post by phplovesong » Sun, Mar 08, 2026, 12:20 PM UTC

well_ackshually wrote: post #113

phplovesong wrote: post #66

Earlier quoted context omitted.

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". I'll tell that to my CI runner, how easy is it for Go to download the Android SDK and to run Gradle? Can I also `go sonarqube` and `go run-my-pullrequest-verifications` ? Or are you also going to tell me that I can replace that with a shitty set of github actions ? I'll also tell Microsoft they should update the C# definition to mark it down as a scripting…

My point was that 90% of "dockerized" stuff is just scripting langs

Re: A decade of Docker containers

#226

Post by poly2it » Sun, Mar 08, 2026, 12:30 PM UTC

vatsachak wrote: post #180

poly2it wrote: post #148

Earlier quoted context omitted.

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

I use crane, but it does not have arbitrary granularity. The end goal would be something which handled all builds in Nix.

Re: A decade of Docker containers

#227

Post by poly2it » Sun, Mar 08, 2026, 12:38 PM UTC

nh2 wrote: post #186

poly2it wrote: post #148

Earlier quoted context omitted.

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…

A problem with that is that Nix is slow. On my nixos-rebuild, building a simple config file for in /etc takes much longer than a common gcc invocation to compile a C file. I suspect that is due to something in Nix's Linux sandbox setup being slow, or at least I remember some issue discussions around that; I think the worst part of that got improved but it's still quite slow today. Because of that, it's much faster to…

What if you set up a sandbox pool? Maybe I'm rambling, I haven't read much Nix source code, but that should allow for only a couple of milliseconds of latency on these types of builds. I have considered forking Nix to make this work, but in my testing with my experimental build system, I never experienced much latency in builds. The trick to reduce latency in development builds is to forcibly disable the network lookups which normally happen before Nix starts building a derivation:

    preferLocalBuild = true;
    allowSubstitutes = false;

Set these in each derivation. The most impactful thing you could do in a Nix fork according to my testing in this case is to build derivations preemptively while you are fetching substitutes and caches simultaneously, instead of doing it in order.

If you are interested in seeing my experiment, it's open on your favourite forge:

https://github.com/poly2it/kein

Re: A decade of Docker containers

#228

Post by neop1x » Sun, Mar 08, 2026, 12:53 PM UTC

No mention of OpenVZ or LXC

Re: A decade of Docker containers

#229

Post by matrss » Sun, Mar 08, 2026, 1:07 PM UTC

osigurdson wrote: post #169

matrss wrote: post #84

Earlier quoted context omitted.

You have to differentiate container images, and "runtime" containers. You can have the former without the latter, and vice versa. They are entirely orthogonal things. E.g. systemd exposes a lot of resource control as well as sandboxing options, to the point that I would argue that systemd services can be very similar to "traditional" runtime containers, without any image involved.

Well, I did mention "or use cgroups" above.

And what I've said is that there are more options. You don't have to use cgroups directly, there are other tools abstracting over them (e.g. systemd) that aren't also container runtimes.

Re: A decade of Docker containers

#230

Post by throwaway_2494 » Sun, Mar 08, 2026, 1:18 PM UTC

Back in the day when it came out, I gotta admit, Docker sort of got my my nerves as yet another thing coming to 'disrupt' how things are done.

(Half assed NOSQL 'databases' with poorly thought out storage models, everything having to be a microservice, turning every function call into a fallible RPC call etc...)

But I've come to appreciate it more, and i use it regularly now. I appreciate its relative simplicity.

But as in life, hell is other people's containers. My own I can at least try to keep them simple and minimal.

But I have seen many use the kitchen sink approach, giving me the feeling that even the developer don't seem to know how they arrived at their deployment anymore.

But this all seems quaint today. With LLMs, now we can look forward to a flood of code the developers haven't even looked at, but which is widely believed to work...