Live data from Hacker News

Podman Desktop 1.2 Released: Compose and Kubernetes Support

podman-desktop.io

31–40 of 132 posts

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#33
post #26

Earlier quoted context omitted.

Compose has its own footguns, but I've run a number of services with just Compose on a VM or direct on bare metal and the few little issues I've had were easy to debug and fix. Very much unlike Kubernetes, where even a small deployment can sometimes be maddening to debug. Great for larger deployments where complexity is basically guaranteed, but anything that could run on one server with a hot spare is a great fit fo…

Surprised to hear you think debugging in kubernetes is maddening. It’s absolutely very different , but if I had to debug a system I knew nothing about, I’d rather debug a kubernetes based system rather than any other. Standards and all that. Anyways - for a single container or two obviously you’re right - I’m just not sure that’s so common outside of a side project anymore.

Especially because "production" implies an ingress controller, monitoring, etc. Does a Docker Compose-based production setup contain run its own Nginx with its own manually-wired rules? Its own Prometheus?

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#34

Earlier quoted context omitted.

Docker compose falls apart when you need something clustered across nodes or any other multi-host deployment. Once you have to rip it apart it becomes way less appealing. Though I haven't tried it in a while and perhaps the ergonomics have changed.

Docker swarm is supposed to be the migration target for these cases, but I’ve never actually used it.

I lost track about it, I thought swarm was canceled

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#36

Earlier quoted context omitted.

Docker compose falls apart when you need something clustered across nodes or any other multi-host deployment. Once you have to rip it apart it becomes way less appealing. Though I haven't tried it in a while and perhaps the ergonomics have changed.

Docker swarm is supposed to be the migration target for these cases, but I’ve never actually used it.

Swarm works, but has poor support for volumes - which means it's tricky to run legacy applications on swarm (which eg uploads files to local disk, not s3 - or keeps state/cache on disk, not a database).

Ingress is also more complicated/bespoke - the best I've found is traefik with labels for routing/config.

My advice today would be to scale Docker compose vertically (eg: on a dedicated server) - then move to Kubernetes.

The swarm middle ground isn't really worth it IMNHO.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#37
Is there a way to make Podman Desktop use the default system connection rather than the default podman machine?

When I do `podman ps` my client connects to my development VM that is not managed by podman, but I can't seem to find a way to make Podman Desktop do that.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#39
post #36

Earlier quoted context omitted.

Docker swarm is supposed to be the migration target for these cases, but I’ve never actually used it.

Swarm works, but has poor support for volumes - which means it's tricky to run legacy applications on swarm (which eg uploads files to local disk, not s3 - or keeps state/cache on disk, not a database). Ingress is also more complicated/bespoke - the best I've found is traefik with labels for routing/config. My advice today would be to scale Docker compose vertically (eg: on a dedicated server) - then move to Kubernet…

Traefik is really simple to set up and I’d bet setting up s3 is 100x easier than kubernetes no? Unless I’m missing something.

Fwiw I found swarm lovely and just so much easier to work with than anything else solving the same problems.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#40

Earlier quoted context omitted.

Docker compose falls apart when you need something clustered across nodes or any other multi-host deployment. Once you have to rip it apart it becomes way less appealing. Though I haven't tried it in a while and perhaps the ergonomics have changed.

Docker swarm is supposed to be the migration target for these cases, but I’ve never actually used it.

I've done some labbing with Swarm. Swarm is _just different enough_ to be a pain, but just similar enough to fool you into thinking you know what you're doing. Because swarm was also confused terminology (at one point there were two things with the name swarm that did things differently) the tech definitely got a bad rap for a while, but it also stagnated supporting tooling. You can use things like Portainer and Swarmpit to get some visibility into your swarm cluster members, deploy workloads, etc, but it definitely feels like a second class citizen.

Ultimately, I would love for something to exist out there that had the opinions and scope of deployment like Swarm in terms of simplicity, but didn't conflate other tools out there so that ergonomics and documentation were better and less confusing. Kubernetes gives you so much, but I do feel like it's a misstep that the only reasonable way we've simplified Kubernetes for production workflows is to pay a large PaaS to manage it for us.

Post reply on HN