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

241–250 of 286 posts

Re: Docker's Second Death

#241

Post by hinkley »

ecliptik wrote: post #239
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.

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 are plenty of other tools that can do that.

Collapsing layers is about seeing that an image provides a set of services at point A, and another set at point B, and that nothing in between represents an interim state of any substantial value. For most images, this is one or two layers that relate to either the main payload, or one particularly volatile dependency.

Re: Docker's Second Death

#242

Post by revskill »

GordonS wrote: post #136
nickjj wrote: post #115

Earlier quoted context omitted.

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

I use Docker Swarm (basically multi-node Compose) in production, and am also really happy with it. It's an order of magnitude simpler than k8s, and perfect for small-medium scale deployments. In terms of configuring your stack, you use regular Compose files, with a few enhancements available (such as better support for secrets). I love it!

What's your solution to the problem of shared disk between hosts ?

Re: Docker's Second Death

#243

Post by 0xbadcafebee »

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…

Containers aren't really a thing. That's the more troubling bit.

Docker containers are an amalgamation of features, tweaks, and functions which combine together into one experience. There is no kernel concept of a container. There are cgroups, namespaces, capabilities, chroots, CoW Overlay VFS, bind mounts, firewalls, virtual networking... And a whole lot of custom crap Docker provides. You have to have a lot of custom glue to make it all work. You need "a Docker".

Every attempt to make a replacement for Docker falls short because of how many things it has to touch to make things easy to use. To replace it all (since it's not an OS primitive) requires product development, which is expensive and complicated, and probably not vendor-compatible with Docker anyway. So you might as well just have people run Docker.

Containers fundamentally change the concepts used to maintain and operate applications in OSes. I think eventually they will become core features, but it's going to take a while. Someone's going to need to start sending in some pretty big patch sets one piece at a time, such as kernel drivers for all the various features. OCI also needs a lot more help before we can run a container everywhere, and it will undoubtedly involve some virtualization layers we don't yet use as part of containers, which will add more complexity.

Re: Docker's Second Death

#244

Post by lmeyerov »

That this was written by a (ex?) Red Hat employee makes a lot of sense. We burned significant time in the last 2 weeks because RHEL 8 intentionally makes it very hard to `dnf install docker-ce` (even though you are literally just installing the centos/rhel 7 package), and insteadm RH docs + staff tell IT admins who don't know better to `dnf install podman` as the only correct option and lie that is drop-in compatible. Then we get support tickets because, surprise, podman often doesn't actually replace docker due to bugs, or in areas like `docker-compose`, because it isn't even implemented.

Docker's second death is very much IBM/ RHEL's anti-competitive intent. An infrastructure provider should be neutral on how they present this kind of thing, especially a company selling enterprise reliability for running software on top. The 1984-esque double speak experience has been quite souring wrt ethics of doing business with them around cloud/container-era technology and trusting them for enterprise reliability.

I do find the podman ecosystem technically interesting... but due to the unethical corporate stewardship we're seeing, I'm uncomfortable seeing anyone use it.

Re: Docker's Second Death

#245

Post by pault »

2ion wrote: post #188
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…

Docker Desktop is the only non-hacky way to get a decent Docker (and k8s) setup for development purposes on macOS and Windows. Linux on the desktop never needed that, but those other two do.

Have you tried WSL2? It's been a dream for my use cases as a web developer.

Re: Docker's Second Death

#246

Post by dismalpedigree »

revskill wrote: post #242
GordonS wrote: post #136

Earlier quoted context omitted.

I use Docker Swarm (basically multi-node Compose) in production, and am also really happy with it. It's an order of magnitude simpler than k8s, and perfect for small-medium scale deployments. In terms of configuring your stack, you use regular Compose files, with a few enhancements available (such as better support for secrets). I love it!

What's your solution to the problem of shared disk between hosts ?

Nfs volume mounts. Works quite well. Make sure the hosts can access the nfs endpoints (i run nfs on separate lan)

Re: Docker's Second Death

#247

Post by tariqislam_ »

lmeyerov wrote: post #244

That this was written by a (ex?) Red Hat employee makes a lot of sense. We burned significant time in the last 2 weeks because RHEL 8 intentionally makes it very hard to `dnf install docker-ce` (even though you are literally just installing the centos/rhel 7 package), and insteadm RH docs + staff tell IT admins who don't know better to `dnf install podman` as the only correct option and lie that is drop-in compatible…

Author here. Ex Red Hat, yes. Couple of things:

1. Docker being deprecated has nothing to do with anyone's competitive intent. I believe that the Kubernetes community is optimizing away from bloat.

2. I do not espouse podman. This post was about the container runtime, which podman is most definitely not.

It's been a few years since I left the company, but it's unfortunate that you've had the experience you describe.

Re: Docker's Second Death

#248

Post by sp332 »

coward8675309 wrote: post #10
lima wrote: post #6

So, what's the better business model for a low-level piece of infrastructure like Docker?

Docker, Inc. has the opportunity to be the NPM, Inc. for container images. How much did NPM sell to GitHub for? Less concretely, is there a business model for a low-level piece of infrastructure like Docker? Is there a business model for ncurses or readline or df or ls? "Real world" infrastructure is typically high capex, low margin. How many VC-funded startups build bridges or tunnels? SpaceX is pivoting to Starlink…

How much did NPM sell to GitHub for?

Was this number released?

Re: Docker's Second Death

#249

Post by lmeyerov »

tariqislam_ wrote: post #247
lmeyerov wrote: post #244

That this was written by a (ex?) Red Hat employee makes a lot of sense. We burned significant time in the last 2 weeks because RHEL 8 intentionally makes it very hard to `dnf install docker-ce` (even though you are literally just installing the centos/rhel 7 package), and insteadm RH docs + staff tell IT admins who don't know better to `dnf install podman` as the only correct option and lie that is drop-in compatible…

Author here. Ex Red Hat, yes. Couple of things: 1. Docker being deprecated has nothing to do with anyone's competitive intent. I believe that the Kubernetes community is optimizing away from bloat. 2. I do not espouse podman. This post was about the container runtime, which podman is most definitely not. It's been a few years since I left the company, but it's unfortunate that you've had the experience you describe.

I wouldn't have written anything if dockerless was opt-in for when you wanted to experiment with dropping `dnf install docker-ce`.

There's a difference between infra orgs promoting new tech as an alternative vs. blocking their competitors. Infra co's are paid to be reliable neutral providers & advisors - instead, it seems corporate greed here has folks actively breaking enterprise userland and misleading decisions makers in sensitive areas like gov, utilities, world-scale services, etc.

Like I said, I found the technical goal interesting and have been following. However, working through the year+ papertrail of RH doublespeak here makes me dread having to interact with them as an active OSS dev and in my dayjob working with big businesses / govs. RHEL often has policy lock-in in these orgs, so I know it'll keep happening unless the community stops it. As is, the stewards are needlessly risking putting podman and friends into a politically contentious category similar to urbit, oracle, etc., and are costing a lot of time & $$$ from people who are already stretched thin.

Re: Docker's Second Death

#250

Post by nicwolff »

user5994461 wrote: post #189
nikisweeting wrote: post #183

Earlier quoted context omitted.

You just define a depends_on: condition: service_healthy, works great in v2.4. v3 is really a different beast, it's not an upgrade in the traditional sense, more of a lateral move with the introduction of swarm. I've even seen Docker employees recommend in forums using v2 independently of v3 if you need certain features (I can try and dig up a link from my archive if you're interested). Compose file version 2 is not…

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…

As of the September release of Compose version 1.27.0 https://github.com/docker/compose/releases/tag/1.27.0 the config format versions 2 and 3 are merged and "depends_on" – and "extends"! – are back.
Post reply on HN