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

271–280 of 286 posts

Re: Docker's Second Death

#271

Post by TuringNYC »

atombender wrote: post #223
TuringNYC wrote: post #220

Earlier quoted context omitted.

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.

Firstly, I totally agree. Secondly, but it speaks to my initial objection. Not everything can easily be thrown into an adhoc desktop kubernetes setup and it does not make sense for everything -- especially when you have a simple, almost instantaneous alternative way to do it -- docker cli+daemon

Re: Docker's Second Death

#272

Post by TheColorYellow »

wisty wrote: post #144
ampdepolymerase wrote: post #62

Earlier quoted context omitted.

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.

There's no money in backends unless you have a great enterprise sales team. SAS, Matlab, Oracle, Arc, there's lots of really boring backend systems with plenty of FOSS alternatives but you need sales. If the customer is the developer, then they might ask their manager for a text editor with a nice UI. If the customer is the whole enterprise, then someone needs to wine and dine the CEO to get that $10,000 per core con…

This is a really interesting point. I work in backend enterprise software (as a consumer more than a provider).

Surely the critical success component at scale is more than just "wining and dining". I truly wonder how Oracle has managed to do it for all these years...

Re: Docker's Second Death

#273

Post by chumboslice »

justicezyx wrote: post #251

I am quite saddened by the article's tone: "technical debt of docker" ouch that's hurtful to Solomon and Sam... I personally always take the view that docker, by all accounts, blew off a potential once in decade chance of becoming the next VMware, because of its own arrogance and incompetence. But, I am very much disgusted by the community's misplaced hate towards docker, and the equally misguided euphemism towards t…

I don't think technical debt is an insult. Docker is a fully-fledged platform, 90% of which is not in use in any Kubernetes cluster. It's bloat. That Swarm and everything else was baked into the platform along with the runtime makes it technical debt for those that necessarily have to support it.

I don't think anyone hates docker. But there is an issue of hubris here.

Re: Docker's Second Death

#274

Post by jsmith45 »

hinkley wrote: post #241
ecliptik wrote: post #239

Earlier quoted context omitted.

Have your tried multi-stage builds? We use them almost everywhere to slim down images to only have what they need in production. https://docs.docker.com/develop/develop-images/multistage-bu...

Yeah we asked for transactions and they gave us this... thing. It’s cute, and useful, but in the end it brings back the primary problem that Docker actually solves: absolutely getting all of the files your code needs to run into the package, and the right version. Multistage builds require you to airlift files out of one image into another. Accurately. If cherry-picking is the best option on offer by docker, there ar…

The real purpose for multi-stage builds is for compiled languages.

If you have some service written in say C++/Java/C#/Go, then building it in one container (that has the build tools) and copying the build result to another that only has the stuff actually needed at runtime makes good sense. That is much easier and saner than trying to uninstall all the build time components after using them.

It is not like for desktop software we install the build tool, build, and then uninstall build tools. Instead we grab the relevant build outputs and package them into an archive or installer.

But as a solution for clearing out cruft like package manager caches, etc, yeah multi-stage build is not really optimal.

Being able to write the executed steps in a natural way, and then specify at the end to compare everything to come specified previous layer, and create a layer that just has the differences would be really useful.

They could even still cache the intermediate layers as part of the build caching process if they wanted, so long as they are not included in final image as pushed to a repository.

Docker does have a super cut down version of this with its experimental `--squash` option, but that only makes sure there is a single new layer for the output of the whole dockerfile run. You cannot use this if you for some reason want exactly 2 new layers. This limitation is probably acceptable in a lot of cases. However this option is not supported in the buildkit based backend yet.

Re: Docker's Second Death

#275

Post by jsmith45 »

jcelerier wrote: post #260
AsyncAwait wrote: post #42

Earlier quoted context omitted.

Yes. The image standard for containers is called OCI and there are several ways to use them outside of Docker.

but, where does it pull them from ? who's hosting the images ?

They default to docker compatibility, so if you specify 'busybox' it will pull your default registry, which defaults to dockerhub. If you specify 'k8s.gcr.io/etcd-amd64', then it will try to pull from google cloud registry.

You can redirect such urls to a different registry if you prefer, by using the containerd mirrors configuration.

Re: Docker's Second Death

#276

Post by koffiezet »

zapita wrote: post #213
andrewguenther wrote: post #210

Earlier quoted context omitted.

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

Yeah I followed Docker from the very beginning, and this was also what I remembered.

The biggest incident, if I remember well, was related to the layerfs stuff, which was supported by Ubuntu, but which RH refused to include. Instead they pretty arrogantly pushed to merge a PR which was breaking other stuff in Docker, and were pissed when the maintainers refused to. That whole thing obviously rubbed people working on Docker the wrong way, which was the beginning of the pretty sour relationship.

After that I don't think there was a lot of goodwill from Docker towards RH, probably causing a lot more issues..

Re: Docker's Second Death

#277

Post by wisty »

TheColorYellow wrote: post #272
wisty wrote: post #144

Earlier quoted context omitted.

There's no money in backends unless you have a great enterprise sales team. SAS, Matlab, Oracle, Arc, there's lots of really boring backend systems with plenty of FOSS alternatives but you need sales. If the customer is the developer, then they might ask their manager for a text editor with a nice UI. If the customer is the whole enterprise, then someone needs to wine and dine the CEO to get that $10,000 per core con…

This is a really interesting point. I work in backend enterprise software (as a consumer more than a provider). Surely the critical success component at scale is more than just "wining and dining". I truly wonder how Oracle has managed to do it for all these years...

There's also developer education (see mongo db), support, tooling, ecosystems ...

Re: Docker's Second Death

#278

Post by justicezyx »

chumboslice wrote: post #273
justicezyx wrote: post #251

I am quite saddened by the article's tone: "technical debt of docker" ouch that's hurtful to Solomon and Sam... I personally always take the view that docker, by all accounts, blew off a potential once in decade chance of becoming the next VMware, because of its own arrogance and incompetence. But, I am very much disgusted by the community's misplaced hate towards docker, and the equally misguided euphemism towards t…

I don't think technical debt is an insult. Docker is a fully-fledged platform, 90% of which is not in use in any Kubernetes cluster. It's bloat. That Swarm and everything else was baked into the platform along with the runtime makes it technical debt for those that necessarily have to support it. I don't think anyone hates docker. But there is an issue of hubris here.

Then it should be called technical debt of dockershim, right? I don't want to nitpicking, but the tone of the article is definitely negative. And the whole community are not showing the respect to docker as a whole and brand.

Re: Docker's Second Death

#279

Post by freedomben »

geerlingguy wrote: post #269
freedomben wrote: post #150

Earlier quoted context omitted.

Agreed, podman needs better support for mac. It works fine under Windows WSL2 currently, see: https://www.redhat.com/sysadmin/podman-windows-wsl2 The Podman team is working on it but it's not quite there yet. Podman now has an API so at a minimum the whole opaque VM thing should be usable here soon. podman-machine and boot2podman already work for some people, although they didn't work for me. I have a dream of using…

A lot of people seem to think 'running under WSL2' is equivalent to 'works on Windows', but they're just not the same thing. That's like saying 'it runs in a VM on my Mac'.

Thanks for sharing because this is interesting to me. I would not have guessed that. When I use WSL2 it's mostly transparent to me so I don't think about the implementation.

Do you consider "Docker" to be "works on Windows?"

Re: Docker's Second Death

#280

Post by mrskitch »

alexellisuk wrote: post #44
mrskitch wrote: post #16

Earlier quoted context omitted.

My own opinion: I think there is as a marketplace. Years ago when I started browserless.io, I wanted to find a way to sell access to the core image of ours. Docker kinda has/had a marketplace, where you can buy access to curated and secure images, but it didn’t get any support or news on it. Because of this we went the open-code route and just sold licenses. Too bad because I’d much rather have had a marketplace to d…

Open code or core? OpenFaaS has been a struggle even since it was started, even with a large community and many commercial end-users, none pay for support, services or sponsor. Most of the time saying that Open Source isn't sustainable results in some smarty dropping Elastic or some other massive VC-backed company in like GitLab. It's not helpful.

I suppose it's open core. Open Source is hard because you have to separate people from their money even though the code is "free." I'm not saying it's _the_ answer, but browserless.io isn't VC backed, and it certainly makes more money than most of the Patreon/sponsor models. I understand that it's not just a library, but a full-blown service, which makes it easier to market and sell.

Have you considered a hosted product? I have no idea what your audience is like, but that seems to be where we've had a lot of success. Happy to chat anytime as well: joel at browserless dot io.

Post reply on HN