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

Docker's Second Death

tariqislam.com

Post reply on HN
Print view View original

111–120 of 286 posts

Re: Docker's Second Death

#111

Post by joana035 »

0xFACEFEED wrote: post #101
joana035 wrote: post #60

Earlier quoted context omitted.

> But Kubernetes is super complicated I find quite cute that in 2020 people are still echoing this to the extent that now I have to answer questions like "explain what kubernetes is" during job interviews. To me seems that a bigger group of people get jealous about a smaller group getting new tools. Then this "stuff x is complicated" propaganda is passed on through the industry like the plague.

k8s is complicated (have you seen the docs on node affinity and taints? come on). i've seen several cases where a group of k8s experts pitched the infra as easy to configure/maintain and 12 months later they're being crushed by the weight of all k8s abstractions. i don't blame you. k8s is great job security ;) for now.

> have you seen the docs on node affinity and taints?

Yes, pretty neat and easy way to tag your nodes and tell where your workload will run.

What is the deal?

Re: Docker's Second Death

#112

Post by Wowfunhappy »

musicale wrote: post #93
raesene9 wrote: post #48

To me this article conflates the removal of a piece of legacy hard-coding (dockershim) with the overall death of Docker. That removal doesn't mean that Docker won't be used as part of Kubernetes clusters any more, Docker/Mirantis have committed to creating a CRI plugin for Docker. But realistically Docker the product is primarily a developer tool and I don't see that going away. Docker for Windows/Mac is the easiest…

> Docker for Windows/Mac is the easiest way to use containers This is depressing. Even more depressing is that macOS still doesn't seem to have native containers. (Correct me if I'm wrong - perhaps the sandboxing system can be used as a container system including virtual network interfaces attached to process groups?) Docker images depend on Linux which means "Docker" on macOS runs in a Linux VM. Presumably docker fo…

> Docker images depend on Linux which means "Docker" on macOS runs in a Linux VM. Presumably docker for Windows could use WSL.

WSL2 is also a VM. Docker is in truth Linux-only software, and "Docker" on any other platform is a polished interface for spinning up a Linux VM and running the real version of Docker there.

I don't think this is such a bad thing. What non-Linux Docker really provides is a nice UI.

On my Mac, I switched from doing a lot of development in VMWare Fusion to using docker-machine (set up to still use VMWare under the hood). With docker-machine especially, it's quite obvious that I'm still just using a VM, but it all feels a lot more seamless than when I was running a bunch of commands to start up VMWare, SSH in, and sync my local files.

----------

† I can't use Docker Desktop because I insist on running an old version of OS X.

Re: Docker's Second Death

#113

Post by dang »

ffghhhg wrote: post #64

Give it 3-4 years until some fashionista posts about the “death” of kubernetes. Workers and their cults.

Could you please not create accounts to break HN's guidelines with? We're trying for something a little different than internet default here.

https://news.ycombinator.com/newsguidelines.html

Re: Docker's Second Death

#114

Post by enos_feedler »

brainzap wrote: post #83
hmottestad wrote: post #12

I enjoyed the following: > Though it [Docker] does live on strongly within CI/CD ecosystems and, ostensibly, the inner loop of development thanks to the de facto standard Dockerfile. Docker will still live on for both Windows and Mac developers. As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Docker is still…

I wish we could replace Dockerfiles already with a format that allows for fine grained layer control.

What kind of control are you looking for?

Re: Docker's Second Death

#115

Post by nickjj »

hmottestad wrote: post #12

I enjoyed the following: > Though it [Docker] does live on strongly within CI/CD ecosystems and, ostensibly, the inner loop of development thanks to the de facto standard Dockerfile. Docker will still live on for both Windows and Mac developers. As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Docker is still…

> As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive.

Not everyone needs an over the top Kubernetes cluster in production. I'm plenty happy using Docker Compose in production and foresee myself continuing to use it as long as Docker maintains it. There's even a WIP issue on their roadmap[0] to rewrite Docker Compose with Go to make it more consistent with their main CLI. Looks like full steam ahead to me rather than death.

It's really nice having the same Dockerfile + docker-compose.yml get used in dev + ci and prod. There's no surprises and no massive amount of complexity.

[0]: https://github.com/docker/roadmap/issues/15

Re: Docker's Second Death

#116

Post by wmf »

andrewguenther wrote: post #7

Docker Inc's antagonistic attitude towards Red Hat and personal attacks on their engineers was the beginning of the end for them. The people who really headlined those attacks are now gone, but the damage was done. Docker made it clear from the beginning they had no desire to be part of a community and now the community is leaving them behind. Good riddance.

Docker Inc put themselves in an impossible situation because they wanted Docker to be a standard and also be a massively profitable monopoly but they didn't have enough moat to pull it off. Red Hat and Google saw the monopolization coming and aggressively commoditized Docker for the good of the community but also for their own benefit.

Now the last battle is over Docker Hub.

Re: Docker's Second Death

#117

Post by nikisweeting »

pm90 wrote: post #95
viraptor wrote: post #63

Earlier quoted context omitted.

What features do you find missing in compose?

https://docs.docker.com/compose/startup-order/ I see that they now recommend some workarounds to fix this issue, where I want to ensure that dependencies are running before spinning up my app. Usually, this is in the context of integration tests. The inability to support this "natively" makes the integration tests somewhat flaky and unreliable.

Docker-compose v2.4 is arguably much better than v3.0, and in a lot of ways they are really separate specs, not a "newer version" of an old spec. Compose v3 exists to push you towards swarm, whereas compose v2 exists to make docker-compose a complete mini cluster management tool, and succeeds at it in my experience.

We continue to use v2.4 in all our projects today because it allows you do easily do things like define startup order with healthchecks, as well as limit cpu, memory, etc. without having to spin up a whole swarm cluster.

Re: Docker's Second Death

#118

Post by enos_feedler »

TuringNYC wrote: post #65

The article and some of the comments are a strange take. There is a place for docker. There is a place for Kubernetes. They dont have much overlap in my mind. If I want to run an elastic production system with many components, and scale each component independently, i'd use Kubernetes. ...But if I want to run a Jupyter+PyTorch stack easily w/o wasting half a day on CUDA library dependency issues, I would use Docker w…

The overlap is in compatibility and consistency of the "units of programming" they can both run natively. I think of docker as the REPL for cloud computing.

Re: Docker's Second Death

#119

Post by joana035 »

matsemann wrote: post #103
joana035 wrote: post #84

Earlier quoted context omitted.

> 2. Ingress Controller hell > 2b. Ingress Controller route/path/url annotation hell... Sorry, but that is no hard at all and I can't imagine why you compare it to "hell". It is literally less than 20 lines to define an ingress object.

Sometimes I've spent hours on a single config line, so having to write 20 of some unknown thing sounds scary. And it's irrelevant for what he is trying to do, which is to run something locally. With docker that's one command, vs having to set up all the other stuff as well. I've been very fan of using docker for all our dev stuff. To run something locally before it meant having correct version of lots of stuff, and p…

Well, looks like some fundamental knowledge is missing here, that why everything looks like "hell" or is "scary".

I wonder how many lines from this "./setup.sh" could have been avoided by trying a bit harder to understand how the ingress object works.

I no longer see lazyness as a good trait in programing.

Re: Docker's Second Death

#120

Post by TuringNYC »

stingraycharles wrote: post #92
TuringNYC wrote: post #65

The article and some of the comments are a strange take. There is a place for docker. There is a place for Kubernetes. They dont have much overlap in my mind. If I want to run an elastic production system with many components, and scale each component independently, i'd use Kubernetes. ...But if I want to run a Jupyter+PyTorch stack easily w/o wasting half a day on CUDA library dependency issues, I would use Docker w…

Of course but you’re forgetting that Docker is a commercial organization as well. If not for large scale container orchestration in the cloud, how can they add value that’s worth paying considerable $ for?

I think whether Docker adds value (1) and how to capture the value (2) are separate questions. This response was the value it adds. I think it adds a tremendous amount of value, and widespread academic and corporate usage speaks to that.

To your point, they also need to capture that value, because it would be a pity to lose Docker. I cover that in the thread of how they profit with one idea: https://news.ycombinator.com/item?id=25326062

There are other potential ideas -- marketplaces, indemnification services, security services. I hope they figure something out.

Post reply on HN