Live data from Hacker News

Goodbye Docker: Purging Is Such Sweet Sorrow

zwischenzugs.com

21–30 of 95 posts

Re: Goodbye Docker: Purging Is Such Sweet Sorrow

#21

Docker is the Myspace of container engines. It's stupidly unreliable, at least on MacOs. I've resorted to running system prune every week or so to keep it from getting totally out of control. Reminds me of NPM and rm-rfing node_modules on every build. I can't wait till something comes along to replace it.

> Docker is the Myspace of container engines. It's stupidly unreliable, at least on MacOs. I've resorted to running system prune every week or so to keep it from getting totally out of control.

Well Docker for Mac is really just binding the CLI towards the daemon, that is running in a Linux VM. But the integration is far from optimal.

Re: Goodbye Docker: Purging Is Such Sweet Sorrow

#22

> was likely due to a script that had got out of hand starting up too many containers. So there wasn't any actual problem with Docker, it was the OP's own problem that they "solved" by switching container platforms instead of just fixing their own buggy script?

I facepalmed when I read that... This is an all too common problem in development and it's made me very skeptical of coworkers at times who use it "X technology doesn't work or X is garbage" as a justification to switch technologies or spend time prototyping several alternatives. I'm not gonna say Docker is a perfect tool by any stretch either.

> I facepalmed when I read that...

I encourage you to read the entire article, so you understand what was his actual thought process deciding to replace docker, and the pros of the new solution.

Re: Goodbye Docker: Purging Is Such Sweet Sorrow

#23
post #14

> was likely due to a script that had got out of hand starting up too many containers. So there wasn't any actual problem with Docker, it was the OP's own problem that they "solved" by switching container platforms instead of just fixing their own buggy script?

>Anyway, I didn’t necessarily blame Docker for it, but it did add force to an argument I’d heard before: Why does Docker need a daemon at all?

I am similarly confused as to why docker needs a daemon. For what's provided in the API, I don't see the need...it could all happen in the client.

Contrast with LXD. It has a daemon as well, but it tracks containers and state across multiple hosts, so the need is obvious. The single host LXC doesn't have a daemon.

Re: Goodbye Docker: Purging Is Such Sweet Sorrow

#25
post #14

> was likely due to a script that had got out of hand starting up too many containers. So there wasn't any actual problem with Docker, it was the OP's own problem that they "solved" by switching container platforms instead of just fixing their own buggy script?

>Anyway, I didn’t necessarily blame Docker for it, but it did add force to an argument I’d heard before: Why does Docker need a daemon at all?

Well for one, it can restart the container when it fails or on boot up. I don’t see how having no process minder improves anything, you could argue systemd shouldn’t be a daemon too and sysv init scripts are better too.

Re: Goodbye Docker: Purging Is Such Sweet Sorrow

#27

> was likely due to a script that had got out of hand starting up too many containers. So there wasn't any actual problem with Docker, it was the OP's own problem that they "solved" by switching container platforms instead of just fixing their own buggy script?

I facepalmed when I read that... This is an all too common problem in development and it's made me very skeptical of coworkers at times who use it "X technology doesn't work or X is garbage" as a justification to switch technologies or spend time prototyping several alternatives. I'm not gonna say Docker is a perfect tool by any stretch either.

I think it's valid, if I'm understanding the context.

OP seems to run a lot of infrastructure on his "home servers" not because he directly needs it but as a learning/playground environment.

So here he's chosen to learn about some new tools rather than track-down and fix a misbehaving script. That seems reasonable to me.

(Though, I'm inferring here. If that's really was his thinking was, he could have stated it clearly and prevented the confusion.)

Re: Goodbye Docker: Purging Is Such Sweet Sorrow

#28

> podman pull downloads get all layers in parallel, in contrast to Docker’s. Hmm? I could have sworn docker pulled multiple layers at once the last time I used it.

Docker pulls three layers at a time, not all of them.

It pulls as many as it's configured to pull.

And yes, in your case that would be "all of them" if there's no more than 3 layers in the container and only one is being pulled.

Re: Goodbye Docker: Purging Is Such Sweet Sorrow

#29
post #8

Earlier quoted context omitted.

It was on his home servers and he got a valid point regarding redundant daemon in docker. So I don't understand why you facepalm because its not your business what he runs at home or how he rocks his boat.

I'm facepalming because he literally went through all the effort to replace Docker without fixing the underlying problem which is his script. At a minimum it means he doesn't understand how his own code works which is going to be problematic if your career involves coding. The "it's none of your business" argument falls flat the moment you decide to broadcast to the entire world what you're doing and then get it onto…

You should read articles without assuming Hacker News is the intended audience. They usually aren't submitted by the author.

Re: Goodbye Docker: Purging Is Such Sweet Sorrow

#30
I’ve managed to resist the hype and still not ever used docker for anything ...

I still really struggle to understand what the practical benefits to this kind of containerization actually are ...

It seems like people reach for it because they want to have some kind of “compile target” into which they can stick “all the things” their application needs to run — which is supposed to then help them “deploy” into their development environment or onto their production infrastructure in a way that serves the goal that the applications within the image should behave the “same way” in either location ... but does anything about this kind of container abstraction actually help with doing this? Don’t you still inevitably end up having to manage assumptions about the differences between these environments in order to make this work in practice (oh if you are in development environment make sure you don’t actually submit payment to stripe, if you are deploying to this cloud provider make sure you get secrets from instead of ...) ...?

Do you actually get any good abstractions out of the container which empower better solutions to deployment challenges? “I don’t have to think about which hosts the (random) http client used in my application is configured to talk to because I can just magically retarget it at the container level by manipulating networking configuration” — is that a thing — does it actually work? To my understanding the extent to which you _can_ do that requires you to write your application a certain way with a crazy service discovery layer like istio — and you’ve got to make sure you build your application completely to use service discovery fabric ... but if you built your application to use a service discovery fabric do you gain anything extra by also using docker at that point ...?

And what about the impact to developer ergonomics? Is it easy and smooth to use debuggers to quickly edit code running in an image ...? Do people regularly run production docker images locally to debug production application issues ...? Are there solutions that allow one to say, attach to a remote qa testers chrome instance and then automatically attach debugger to the set of production containers handling the requests associated with that browser ...?

Those are the kind of features I want ... I’m not sure exactly if the containerization abstraction model would really help me get there or just create another set of configuration knobs that _also_ have to be correctly aligned for me to get the right environment specific behaviors out of my application ...

Post reply on HN