What's missing to fully replace Docker Desktop?
Podman Desktop 1.2 Released: Compose and Kubernetes Support
31–40 of 132 posts
Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support
#32Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support
#33Earlier 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.
Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support
#34Earlier 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.
Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support
#35Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support
#36Earlier 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.
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
#37When 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
#38Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support
#39Earlier 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…
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
#40Earlier 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.
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.