41–50 of 95 posts
HDD : Hype Driven Development. "Yeah, we should just give up on Docker and rebuild all the container ecosystem using IBM technology."
Automatic failover during hardware failure, no need to program anything special. HA without the need for having to do any work.
Earlier quoted context omitted.
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.
Systemd not being a daemon doesn't make any sense; both it and SysV are init systems which are by necessity daemonized processes.
I personally like keeping my root partition to a minimal and ever since docker came into the picture I keep running into spacing issues. So the allure for me to switch isn't technical but for peace of mind storing images in userspace
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 de…
Yes, this works, and we've been doing it for a long time, since well before containers became a thing. When you're running services at any significant scale you can't have clients connecting to hard coded host addresses. The only way to get durability and scalability is to place the service behind a load balancer, have the clients find the load balancer through a stable DNS record, and have the load balancer direct traffic to healthy instances of the service. That's essentially what you have described above, without any containerisms.
What do containers add to this picture? Nothing. Containers themselves have almost nothing to do with networking and how traffic gets to your services, beyond establishing a net namespace, a veth pair, and a bridge to connect the pair to the host interface. That's just basic plumbing, not traffic management. Containers are about process isolation, not networking.
The networking problem for containers is addressed by container orchestration platforms like kubernetes, or compose/swarm. From a networking perspective what orchestrators bring to the table is basically an abstraction layer over the underlying provider resources for creating and tearing down all the stuff that implements the client->load balancer->service pattern.
Perhaps it might have been worth the extra time to get to the bottom of it instead of switching and, in the end, not noticing any big differences?
Also, I noticed there was an ad at the end of the post for the book Docker in Practice. Ironic placement.
> 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 know a lot of people in school who have to use a generally well regarded technology, but hate it because they had to use it in a class. For example, they might see someone on github and go “oh is that github? I hate using git” when in reality they had to use it in a group project with 4 other people who have never used it, and had no understanding of branches, merging, etc.
I have seen the same thing with LaTeX, Python, and Vim.
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 de…
I had some legacy code that was being repurposed and I couldn't touch the production environment, not even to build again.
I could have tried building new VMs, but in the end I defined the build process with a Dockerfile. Environment variables, compilers, external dependencies, all of it done when you ran "docker build". There was a small script to orchestrate that and copy out the results too.
The build environment was consistent, it was easy to tweak, and I could build for centos 6, centos 7, and suse 12 on any machines. That let me use my test box to implement and test any environment changes before it moved to production. It also let the primary developers build their own versions of it whenever they had made a change that needed testing.
It's not at all like any of the use-cases I read about, but it made my life so much easier.
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…
Earlier quoted context omitted.
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…
No, some container went rogue, and in the process dragged the Docker daemon which annoyed him PLUS he'd learnt that it was possible to run containers rootless and daemonless SO he changed his setup. Please RTFA.