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

221–230 of 286 posts

Re: Docker's Second Death

#221

Post by heavyset_go »

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.

I use Swarm at home and for my projects because the cognitive and resource overhead is so low. It just works and it's easy to set up.

Re: Docker's Second Death

#222

Post by [deleted] »

hacknat wrote: post #157
mwcampbell wrote: post #149

Earlier quoted context omitted.

> There’s no need for them to live on. Maybe not, but considering how much they gave, I think we should want them to live on, and do what we can to help them. Do we really want to live in a world where a startup company makes as big an impact on the way we develop and deploy software as Docker did, only to have all possible business taken from it by bigger players?

I understand this sentiment, but a lot of the original team and the certainly the original founder aren’t even there anymore. Not to mention that a lot of Docker’s business missteps have been self inflicted wounds. There have been lots of great technologies that haven’t directly made their creators rich, but their good legacy usually/eventually catches up with them.

[deleted]

Re: Docker's Second Death

#223

Post by atombender »

TuringNYC wrote: post #220
atombender wrote: post #179

Earlier quoted context omitted.

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…

That's not what ingresses are for.

Your "docker run" example is equivalent to just accessing the Kubernetes services directly on their host names or IPs. For example, with Docker for Desktop, all services of type "LoadBalancer" will automatically get exposed on the host, just like with "docker run".

Ingresses are for setting up HTTP proxying of multiple services on a single host name.

Re: Docker's Second Death

#224

Post by fomine3 »

ampdepolymerase wrote: post #62
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…

A bigger issue is the fact that they were not able to become a unicorn despite having a tremendously popular product. It means there is no money in development tools innovation. This is not a good thing for the software community as it means all tooling innovation will only done and controlled by the FAANGs.

It seems that HashiCorp does their business well, what makes it?

Re: Docker's Second Death

#225

Post by zomglings »

dockershim is gone blah blah blah.

Tell me, how will the great majority of developers be creating images to run on kubernetes clusters? Not buildah or whatever. They will use docker build, I wager.

Docker will die eventually, yes. But not for a long time (>5 years) yet.

Re: Docker's Second Death

#227

Post by samatman »

mwcampbell wrote: post #206
hacknat wrote: post #157

Earlier quoted context omitted.

I understand this sentiment, but a lot of the original team and the certainly the original founder aren’t even there anymore. Not to mention that a lot of Docker’s business missteps have been self inflicted wounds. There have been lots of great technologies that haven’t directly made their creators rich, but their good legacy usually/eventually catches up with them.

> but their good legacy usually/eventually catches up with them. I think that's the just-world fallacy. [1] It's up to us to reward good work. So I guess I should go get a paid Docker Hub account. [1]: https://en.wikipedia.org/wiki/Just-world_hypothesis

So I agree with you about supporting good technology which you want to see survive.

I don't think the poster you're replying to was invoking a just world fallacy, however. I read it as saying that developers who build solid systems that people like tend to thrive, even if their business fails.

That appears to be true, and not because of karma, because top-tier developers are in very high demand. Demonstrating that you're one of those isn't the same thing as running a successful business.

Re: Docker's Second Death

#228

Post by OJFord »

nikisweeting wrote: post #203
user5994461 wrote: post #189

Earlier quoted context omitted.

Problem being, "depends_on" was removed in version 3, with no replacement in sight. I honestly don't understand why they'd remove that? why make a new configuration format just to remove critical options? what is the developer supposed to do instead? when will compose stop accepting the v2 format so we're definitely screwed for good? (yes the writing is on the wall). P.S. For readers who don't have context. Make a ba…

This is an application-level design flaw, not a flaw inherent to docker-compose. Regardless of whether you use docker or even if you use containers at all, your webapp should be able to restart if the connection to the database fails or is interrupted for any reason. You would have the same problem if you used supervisord for example. The general solution is to auto-retry the connection until it comes back up, or har…

Hm, yes, but to play devil's advocate - if you want compose for orchestration (I don't) then you want that dependence not so much for initial start up, but for triggering restarts on failure.

As it stands, AIUI, all it does is mean that dependency A comes up too (in some order) when you `up B`.

Re: Docker's Second Death

#229

Post by topspin »

yjftsjthsd-h wrote: post #145
enos_feedler wrote: post #114

Earlier quoted context omitted.

What kind of control are you looking for?

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.

You might investigate buildah. You can achieve precise control over layers. Also, buildah mount is awesome; direct access to a container file system from the host; COPY/ADD et al. are obviated.

Re: Docker's Second Death

#230

Post by tariqislam_ »

jacques_chester wrote: post #197
tariqislam_ wrote: post #190

Earlier quoted context omitted.

Author here. In the last part of my post, I do mention that Dockerfiles are probably the one thing that will outlast everything else from Docker. There's nothing really practical to replace that artifact at this time if you ask me. There are some tools to convert your docker-compose into the k8s resource model. I'd advise against switching local development to Kubernetes. Docker found a sweet spot there, as heavyweig…

> There's nothing really practical to replace that artifact at this time if you ask me. I am required by law to spruik Cloud Native Buildpacks. For most uses, I feel Dockerfiles are not necessary or desirable at this point. Disclosure: I've been around CNBs for a while for Pivotal and now VMware.

Haha, ok that's totally fair. Valid point. Thank you for bringing this up. I'd not considered them.
Post reply on HN