Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Podman Desktop 1.2 Released: Compose and Kubernetes Support

podman-desktop.io

Post reply on HN
Print view View original

61–70 of 132 posts

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#61

Post by Art9681 »

tauchunfall wrote: post #17
alphabettsy wrote: post #12

Earlier quoted context omitted.

Is Docker still using a VirtualBox based solution? I thought they were using the macOS virt framework.

colima allows to chose between qemu and apple virtualization framework. I found there is not much diffence in performance between both on my intel macbook. I think it will not take long until rancher also updates to latest lima to support apple virtualization. but I haven't checked the latest release notes.

That's because QEMU can do hardware acceleration in an x86 host but not in M architecture. But as far as I know, only the Apple framework can do hardware acceleration or use Rosetta 2 to make things near native speed on an M-series Mac.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#62

Post by hu3 »

Art9681 wrote: post #51
chenster wrote: post #42

Do people still use Vagrant? Last time I tried Docker on Mac, it was painfully slow. So I kept using Vagrant, which used more disc space, but very fast, and the Intel Macbook pro fan never kicked in once like Docker did.

Containers on anything other than Linux run in a Virtual Machine. Depending on the platform, you may or may not have hardware acceleration. It's either using the software emulator (slow) or hardware acceleration. On the new M architecture, I believe Docker now supports Rosetta2 emulation via Apple's Hypervisor Framework so it is near native performance. As far as Vagrant being faster than Docker, it's possible the qe…

Just a nit. Docker on Windows is near native-like performance, using WSL2.

WSL2 even supports running Linux GUI applications and GPU passthrough.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#63

Post by vbezhenar »

preya2k wrote: post #45
vbezhenar wrote: post #41

Earlier quoted context omitted.

Docker compose is extremely basic. Even on a single node Kubernetes is more capable than docker compose. Ingresses, Services, Deployments, Cronjobs, Statefulsets. Awesome operators. Cert-manager. There're so many things I could easily do with Kubernetes that would require countless unmaintainable bash scripts and ad-hoc approaches with docker-compose.

For me, I really enjoy how basic it is. I’ve never missed any of these things for my simple single-host scenarios.

Simple setups will be as simple with Kubernetes.

However with Kubernetes your infrastructure will be ready to scale. You need to expose both front-end and back-end services under the same host? No need to tinker with nginx configs, you just create two ingresses and do it in a standardized way. You need to run your service with two replicas and rolling zero-downtime update? Kubernetes has it out of the box. Good luck implementing all the necessary dances with custom docker-compose setup without dropped requests. You want to customize healthcheck? Kubernetes got you covered with all the imaginable scenarios.

The only missing block in Kubernetes is support for building containers. This is implemented with docker-compose extremely elegantly and simple. That I admit.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#64

Post by brazzledazzle »

jadbox wrote: post #27
brazzledazzle wrote: post #18

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.

Not sure if I follow. Let's say I have 2 kinds of clusters with these sets of containers: A) 3 microserver containers on each machine B) Postgres container and a logging container The A and B group can be implemented with docker compose and deployed to each cluster with pulumi/Terraform. Two or a hundred, it doesn't really matter how many cluster groupings you have.

Don't you lose a bunch of the compose niceties (without swarm anyway)? Aliases, networks, shared volumes, etc.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#65

Post by geerlingguy »

erulabs wrote: post #26
geerlingguy wrote: post #16

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.

Compared to Compose on a single server, Kubernetes deployments can have multiple layers (control plane, containers, usually some sidecars) where little quirks occur.

It almost necessitates deeper monitoring and/or extra tools to give a dashboard/'single pane of glass', whereas I can run Compose and just log into the individual server and jump around logs.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#66

Post by e12e »

nwienert wrote: post #39
e12e wrote: post #36

Earlier quoted context omitted.

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.

Porting a ten year old app from local file storage to s3 might not be trivial.

For a new app, one generally should and can embrace 12-facors, and delegate state to stateful services (managed databases, key-value stores, s3 etc).

Do note that for simple services, local disk can be very hard to beat for low complexity, extremely high performance - with the caveat that horizontal scaling might be tricky.

Ed: also depending on privacy requirements - self- hosted s3 (eg minio) might be tricky for a production load. OTOH self-hosted Kubernetes is no walk in the park either!

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#67

Post by imiric »

hu3 wrote: post #56
imiric wrote: post #52

I wish Podman wouldn't be a Docker replica, but a standalone product that competes in the container ecosystem with innovative features. Initially the main advantage it had over Docker was rootless mode, but this has been available in Docker for a while now. What currently sets Podman (Desktop/Compose) apart from its Docker counterparts? I've also run into issues running some containers with Podman that work fine with…

Docker network effect is too important to ignore. That would be like swimming against the current. For example, Deno ( https://deno.land/ ) initially launched with precarious compatiliblity with Node.js, but eventually had to make compromises and adapt so Node.js projects could migrate easier.

All of that can be accomplished by being compatible with the broader OCI ecosystem. But Red Hat explicitly tries to be a Docker replacement (they suggest `alias docker=podman`, which actually breaks in many ways), to the point where I'm not sure why I should bother using a product that will always play catch-up to the real thing. This Desktop and Compose announcement is part of that roadmap, and I'm just wondering what Podman does better than Docker at this point.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#68

Post by mattrick »

hu3 wrote: post #62
Art9681 wrote: post #51

Earlier quoted context omitted.

Containers on anything other than Linux run in a Virtual Machine. Depending on the platform, you may or may not have hardware acceleration. It's either using the software emulator (slow) or hardware acceleration. On the new M architecture, I believe Docker now supports Rosetta2 emulation via Apple's Hypervisor Framework so it is near native performance. As far as Vagrant being faster than Docker, it's possible the qe…

Just a nit. Docker on Windows is near native-like performance, using WSL2. WSL2 even supports running Linux GUI applications and GPU passthrough.

WSL2 still runs in a VM so it has the performance implications of that, not that they usually end up being that significant (I have found that memory usage in WSL2 is usually ridiculously high, though).

I think the support for Linux GUI applications is achieved by running an X server on the Windows side of things.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#70

Post by LeFantome »

imiric wrote: post #67
hu3 wrote: post #56

Earlier quoted context omitted.

Docker network effect is too important to ignore. That would be like swimming against the current. For example, Deno ( https://deno.land/ ) initially launched with precarious compatiliblity with Node.js, but eventually had to make compromises and adapt so Node.js projects could migrate easier.

All of that can be accomplished by being compatible with the broader OCI ecosystem. But Red Hat explicitly tries to be a Docker replacement (they suggest `alias docker=podman`, which actually breaks in many ways), to the point where I'm not sure why I should bother using a product that will always play catch-up to the real thing. This Desktop and Compose announcement is part of that roadmap, and I'm just wondering wh…

Do you do embedded? Look at the size of crun vs runc and at the portability of Go vs C.

Do you like having to have a daemon running? I don’t.

Also, the “pod” in the name may yield a few hints.

Finally, despite all the recent and undeserved hate, I know that Red Hat will keep their source open. I have no such faith in Docker.

Have you priced out Docker Desktop and Podman Desktop lately?

Post reply on HN