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

261–270 of 286 posts

Re: Docker's Second Death

#261

Post by nikisweeting »

nicwolff wrote: post #250
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…

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.

This is amazing news, I was not aware of this. Thank you so much for linking! Do you know if it also applies to the cpu/memory limits and health checks? Is it a true full merge of the two specs? (I will investigate myself and post back too)

Re: Docker's Second Death

#262

Post by nikisweeting »

klibertp wrote: post #257
nikisweeting wrote: post #236

Earlier quoted context omitted.

You can define any order or restart behavior you need with v2. As long any container with a service dependency fail hards if that dependency is missing/down, it will be restarted and the whole app will eventually reach an up state. restart: on-failure depends_on: other_service: condition: service_healthy https://docs.docker.com/compose/compose-file/compose-file-v2... https://docs.docker.com/compose/compose-file/compo…

From GP: > Problem being, "depends_on" was removed in version 3, with no replacement in sight. How is v2 relevant?

v2 and v3 specs are merged as of September apparently, so either set of options works in the current version. (See cousin comments above)

Re: Docker's Second Death

#263

Post by mekster »

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'm a random docker user but that is the same feeling.

podman just doesn't work like docker and podman-compose isn't even at a usable state when RH deprecated Docker which seems completely rushed.

And when you see that it's actually not so easy to install docker anymore, you get the feeling RH has another intention such as trying to control container business by themselves by trying to move people off docker.

If it was purely from technical superiority, then it should've had a smoother migration path.

Re: Docker's Second Death

#264

Post by hda111 »

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.

True but I would use pod yaml with podman. It’s not anywhere near being on par with Docker-compose but it’s the better tool because every pod can be used rootless.

Re: Docker's Second Death

#265

Post by GordonS »

ga6840 wrote: post #232
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!

I also want use docker swarm in production, but I keep hearing people say it has network bugs like after some time services cannot talk to each other. Have you experienced any such issue?

I haven't experienced any networking issues in production at all.

I have experienced 1 networking issue, but only specifically when keepalives are disabled on Windows (where I use Docker for dev/test only)[0]. When using an overlay network, network connections to dockerised Postgres go "stale" after 15 minutes. I workaround it by publish the Postgres port in "host" mode instead of the default of "ingress" mode using `endpoint_mode: dnsrr`.

[0] https://success.mirantis.com/article/ipvs-connection-timeout...

Re: Docker's Second Death

#266

Post by GordonS »

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 ?

I've never actually had to use shared disk, but I'd use NFS if I did (as another commenter suggested) - I've tried it out before, just when playing, and it worked fine.

Re: Docker's Second Death

#267

Post by nikisweeting »

nikisweeting wrote: post #184
nikisweeting wrote: post #117

Earlier quoted context omitted.

Docker-compose v2.4 is arguably much better than v3.0, and in a lot of ways they are really separate specs, not a "newer version" of an old spec. Compose v3 exists to push you towards swarm, whereas compose v2 exists to make docker-compose a complete mini cluster management tool, and succeeds at it in my experience. We continue to use v2.4 in all our projects today because it allows you do easily do things like defin…

If anyone is curious, this is the native official way to define startup order using healthchecks present in v2.4 (but removed in v3 to push you towards swarm): some_service: depends_on: other_service: condition: service_healthy

TIL this has been returned to compose in the latest version! They merged the specs in September so this is now officially supported again going forward. That fixes my last major gripe with compose trying to push people to swarm, which no longer seems to be the case after this merge.

https://github.com/docker/compose/releases/tag/1.27.0

Re: Docker's Second Death

#268

Post by nikisweeting »

beeskneecaps wrote: post #209

Noob comment: is there a docker-compose and docker-compose.umm format equivalent for kubernetes or something else that has staying power? Thanks

Docker compose is now an open standard, just like Dockerfile, and it's wildly popular still so it's here to stay. Multiple tools besides Docker are starting to implement it (like podman). There is no need to go switching everything to Kubernetes.

Re: Docker's Second Death

#269

Post by geerlingguy »

freedomben wrote: post #150
tpetry wrote: post #91

Earlier quoted context omitted.

Podman would be next big thing if: 1. they make a package like docker ob mac where you dont have to fiddle with manually starting vms. An environment where using docker feels native 2. When they start the vm to run podman they will use qemu on arm to simulate an x86 machine and run x86 containers The second one will be a huge step forward as docker will not be able to do this for a long time as they use the mac hyper…

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'.

Re: Docker's Second Death

#270

Post by nikisweeting »

zaro wrote: post #168

Not a big loss, IMO. I still remeber when there was somebody on a dockercon with "I don't accept systemd patches".

From my understanding that was due to a long-running design philosophy clash between the systemd people thinking Docker should be using systemd primitives to manage things like unit startup/shutdown/etc., and the docker people wanting to use their in-house implementations so as not to depend on systemd (and thus rejecting PRs trying to change docker behavior to use systemd). I don't think it's fair to use that as an example of toxic behavior on either side, they each had their motivations, and a consensus needed to be reached for both projects to proceed. From what I can tell that debate seems to be old news these days and I haven't seen as much clashing between those teams. I am not a developer on either side though, this is just from the perspective of a user who follows the Github issues.
Post reply on HN