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

121–130 of 286 posts

Re: Docker's Second Death

#121

Post by majewsky »

pjmlp wrote: post #108
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…

Not necessarily, I am yet to bother using it, and know plenty of environments where Docker still is a foreign word. Containers should be about security not cloning local development environment.

Sandboxes are about security. Containers are about deployment tooling. Some containers happen to include/use sandboxing techniques.

Re: Docker's Second Death

#122

Post by FartyMcFarter »

pjmlp wrote: post #108
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…

Not necessarily, I am yet to bother using it, and know plenty of environments where Docker still is a foreign word. Containers should be about security not cloning local development environment.

> Containers should be about security not cloning local development environment.

Why not? One way to use containers is as a light-weight virtual machine without a kernel, which can be pretty useful.

Re: Docker's Second Death

#123

Post by nikisweeting »

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

Earlier quoted context omitted.

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?

I think you've been using it long enough that you forgot how much of a hurdle learning an extremely high-surface-area piece of tech is. The individual abstractions may be simple once you understand them in hindsight, but making an application developer that normally does not work with cluster management learn 100 new abstractions is not "easy".

Re: Docker's Second Death

#124

Post by zapita »

pm90 wrote: post #81
zapita wrote: post #45

I don’t understand all the drama. I remember when everyone complained that docker was too monolithic and controlled by one company. In response they spun out a spec (OCI), an implementation of that spec (runc), then their entire freaking runtime (containerd). They focused on making Docker more of a developer tool with Docker for Mac and Windows. Kubernetes continues to use OCI, runc and containerd - so basically the…

I agree with you. Fact: Docker is insanely popular with devs but Docker Inc. is struggling as a company. Devs have invested a lot on the platform and entire production systems and deployment pipelines use it. k8s announces "we're no longer supporting docker shim!" and what most devs heard is "k8s is moving off from docker (which we know has been struggling for a while)! Fuuuuuccckkkk what do we need to do??" and pani…

I think that’s an accurate summary.

Re: Docker's Second Death

#125

Post by cercatrova »

pbiggar wrote: post #110
cercatrova wrote: post #9

Earlier quoted context omitted.

Really, there is none. After reading through so many of these types of threads, I'm convinced there is no sustainable business model for open source infrastructure. The best bet would be to build proprietary paid services on top of the open source infrastructure. See Laravel's projects.

Fully agree. I'm going to keep your post in mind when I write about the business model of darklang.

Hopefully it goes well, I heard about the downsizing and the OCaml to F# transition.

Re: Docker's Second Death

#126

Post by freedomben »

andrewguenther wrote: post #21
axaxs wrote: post #8

Earlier quoted context omitted.

Any good source/summary of the above? I guess I'm out of the loop, but attacking a company as trusted as Red Hat seems a bad idea.

It's difficult to dig up old drama when "Docker" is in your Google search, but this article gives a peek: https://lwn.net/Articles/676831/

Thanks for this link. That's terrific info.

Re: Docker's Second Death

#127

Post by wmf »

solatic wrote: post #75

The writing for Docker for Mac is on the wall. It depends on a Linux VM, for which there is no business case to spend atrociously large amounts of resources to adapt for x86 container images to run on M1 ARM Macs. For the life of me, I don't understand why Microsoft doesn't acquire Docker. Tighten the integration between Docker for Windows and WSL2, use Docker Hub to slowly push container authors onto managed Azure c…

Docker can run x86 images (slowly) on ARM using QEMU which is already working.

Re: Docker's Second Death

#128

Post by heavyset_go »

hacknat wrote: post #51
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…

There’s no need for them to live on. There are open source alternatives that mimic Docker exactly. In fact on Fedora[1] the “docker” cli command is actually buildah and podman (you actually can’t install Docker on Fedora anymore - I genuinely haven’t noticed a difference). The commands are exactly the same right down to the command starting with the word “docker”. I don’t wish them ill, but literally everything has b…

podman claims to be a drop-in replacement for Docker, yet when I tried to treat it as one, I ran into bugs and a lack of feature parity.

Re: Docker's Second Death

#130

Post by TuringNYC »

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…

The challenge especially once you get to requiring Ingress Controllers is they are not a core part of Kubernetes, but third party. So you have NGINX, Kong, Traefik -- over a half dozen in total.

Not all are fully featured in their open source form, so in some cases you need to purchase the tool to do something like url-rewrite. In some cases, the solution exists, but is something contributed via community (better than none, great in theory, but brittle given the pace of platform change.)

Further, once you actually try to spend time on it, you find there is little to no documentation on topics such as url-rewrite.

It is all interesting, but then you realize you actually have deadlines -- and now you've spent half the day on futzing around with annotation permutations (since there are few/no docs) and you have not actually started working on the actual task of tuning a model on PyTorch...that is when you drop down to just 'docker run...'

It is all worth learning, and doing, but only if you need to. If I need to make something -- in this story Jupyter+PyTorch -- work for many people and be elastic and scalable, then sure, i'll go thru the effort. But if I need a throw-away instance for the day, then it is not worth doing.

Post reply on HN