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

211–220 of 286 posts

Re: Docker's Second Death

#211

Post by vr46 »

pydry wrote: post #52
indymike wrote: post #41

Earlier quoted context omitted.

It depends on what that infrastructure is. Docker owes its existence to the OS not providing an adequate interface to create lighter containers than 00's style virtual machines. They chose to be imported and used as part of the stack by kubernetes instead of offering a better solution, which was clearly where kubernetes was headed. This one is less of a model question, than a market position question. Elastic, on the…

>Elastic on Amazon is a great gateway drug to Elasticco's offerings. Why is that? Is amazon not able to run it properly?

Can’t speak for the poster who wrote the parent post, but we’ve just evicted the AWS Elasticsearch stack from our platform. For something simple, it was a resource hog, configured badly out of the box, complex in all the wrong places, and limited in its offering and linkages to other AWS resources. Just my 2 cents of course.

Re: Docker's Second Death

#212

Post by jackthetab »

GordonS wrote: post #143
hacknat wrote: post #51

Earlier quoted context omitted.

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…

I'm aware of podman, which is more or less a drop-in replacement for Docker, but is there anything comparable to Docker Compose and Docker Swarm? I use Docker Swarm (technically "Swarm Mode") in production, and I'm really happy with it - it's so easy to configure and operate, but I am worried that it will no longer be maintained at some point.

You're not wrong to worry (scroll down to "What about Docker Swarm?")

https://www.mirantis.com/blog/mirantis-acquires-docker-enter...

Re: Docker's Second Death

#213

Post by zapita »

andrewguenther wrote: post #210
zapita wrote: post #166

Earlier quoted context omitted.

I’m talking about the lwn article. The post is by an ex-RH employee and clearly influenced by their experience at RH.

What is the claim here? That Red Hat are the ones being bullies and are misrepresenting the situation?

That clearly there has been a conflict between Red Hat and Docker employees in the past, and that when Red Hat employees tell their version of the story which happens to make them look good and the opposite side look bad, one should take that narrative with a grain of salt. Especially when one side is 100x larger and more powerful than the other by any metric: number of people, revenue, marketing and PR budget.

Are we really supposed to believe uncritically that Red Hat, a publicly traded company with billions of revenue and an army of engineers at their command, are being bullied by a startup of what, a couple hundred people?

I’m sure the people at Docker did behave badly in some way to piss off people at Red Hat, but whenever I dig into the underlying facts, it’s always something silly and sometimes ridiculous. I’ve seen a talk by a Red Engineer dedicated entirely to the topic of how mean Docker maintainers were to him. The actual offense was 1) refusing to merge certain PRs Red Hat deemed important, 2) a tweet by an individual maintainer’s personal twitter account making fun of Red Hat for sending low-quality patches. That’s the kind of ridiculous petty food fights this whole “Docker vs the world” drama is built on. I mean, who cares?

TLDR: the real story is probably more complicated than “everything was great then Docker was mean and then they failed because they were mean, the end” and best told by a less biased source.

Re: Docker's Second Death

#216

Post by crazysim »

Kwpolska wrote: post #169
Wowfunhappy wrote: post #112

Earlier quoted context omitted.

> 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,…

Docker for Windows is capable of running Linux containers (on top of WSL2 or a Docker-specific Hyper-V VM), and it can also run Windows containers. You can only pick one of those, but if you want to containerize Windows software, Docker can do this. (If you’re on Windows 10 Home, only the WSL2 backend is available.)

You can actually run both Windows and Linux containers at the same time. You don't need to pick "one of these". I think the flag to switch between them on the fly is "--platform".

Re: Docker's Second Death

#217

Post by topspin »

chillfox wrote: post #204
hacknat wrote: post #51

Earlier quoted context omitted.

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…

Red Hat removed docker prematurely, Podman is not ready to replace docker for all production cases yet. We have had to replace RHEL systems with Ubuntu to keep some of our applications running as they fail on Podman. A major problem is also that podman-compose is far from feature parity with docker-compose.

> We have had to replace RHEL systems with Ubuntu to keep some of our applications running as they fail on Podman.

I replaced Centos8 with Amazon Linux 2 ("amazon linux extras" provides a working docker installation) for exactly the same reason. I like the idea of podman and buildah and I wish them well, but for the time being I can't afford to debug the missing pieces and subtle failures.

Re: Docker's Second Death

#218

Post by topspin »

hiram112 wrote: post #154
yjftsjthsd-h wrote: post #145

Earlier quoted context omitted.

I'd like explicit layers (transactions, I guess?) - so instead of every command making a layer, I could write FROM alpine STARTLAYER RUN apk update RUN apk upgrade RUN apk add foo ENDLAYER and end up with a 2-layer image (alpine + my stuff) rather than the 4-layer image that docker would produce today.

Isn't this the same? RUN apk update && apk upgrade && apk add foo

Spend some time on docker hub and you'll find thousands of Dockerfiles with RUN . It's dysfunctional.

Re: Docker's Second Death

#220

Post by TuringNYC »

atombender wrote: post #179
yjftsjthsd-h wrote: post #151

Earlier quoted context omitted.

> It is literally less than 20 lines to define an ingress object. ...and this is your idea of easy? For something that should be as simple as "this path goes to this group" + "this group is these containers"?

Not sure what you think isn't easy about it: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: myingress spec: rules: - http: paths: - host: example.com path: / pathType: Prefix backend: service: name: test port: number: 80 Since everything except "spec" is common to all Kubernetes resources, this arguably isn't much different than an Nginx configuration file: upstream backend { server some-backend:80; }…

This is great, until I need to run two Jupyter+Pytorch instances (say I want to test two library versions side by side, a very common task).

...on docker, I can do this in 20sec:

"docker run .... -p 8888:8888"

"docker run .... -p 8888:8889"

Enter k8s. Jupyter does not appear to allow path prefix-based url schemes, so the above wont work. That means, you can use "/" and the default-host, and you're good for your first instance. But what about the next instance? Now you need two different domains somehow supported. Unclear how this works, because unclear whose "problem" it is. It isnt clearly an NGINX problem, or a Jupyter problem, or a k8s problem, but a problem nonetheless. NGINX docs on multiple distinct host based ingress is thinner than that for base usage cases.

I do appreciate your post, but I think my point is that solving 80% of the cases isn't sufficient to make the case for adhoc k8s-usage-by-default on desktop. I'm sure I can make the above work (e.g. for group or Prod usage), but to make that effort worth it, there has to be a reason to do it. When I have an alternative of running two "docker run" commands for adhoc usage, i'm not sure if it is.

Post reply on HN