Podman Desktop v1.5 with Compose onboarding and enhanced Kubernetes pod data | Hacker News Reader

Podman Desktop v1.5 with Compose onboarding and enhanced Kubernetes pod data

podman-desktop.io

209 pointsmairindubh118 comments

After docker desktop became unusable, I jumped to colima and never looked back. I still use the docker runtime in it (the non-proprietary part) but it also supports containerd. On Mac it's just a "brew install colima" and then "colima start"

I also install the compose and ecr credentials plug-ins (since I use ecr for my container registry.) It has the full functionality of docker desktop minus the UI, which I never used anyways.

https://github.com/abiosoft/colima

We tried to use podman at work (via nix) and ran into all kinds of confusing issues, especially in regards to docker in docker and CI builds. Swapped to using colima (again via nix) for the mac folks and regular docker engine for linux, and things have been much smoother. Definitely recommended if your podman setup is as difficult as ours was.

We also attempted to move to Podman, but it just wasn't ready at the time. Since colima works well for our use case (devs with MacBooks), we haven't had a compelling reason to try Podman again

Thanks for sharing this. I got a new M2 mac and installed Podman as I didn’t want the Docker Desktop as well. But ran into multiple issues and gave up and have been begrudgingly putting up with Docker Desktop.

My main complaints are: * the builds fail randomly * containers don’t stop when I run docker compose stop from CLI

So, I have to restart Docker Desktop a couple of times to reset everything. Does running the docker runtime with colima also gets into these issues?

Please share this experience and what went wrong with the postman team. It is the only way things can improve.

You don’t have to solve the problem. Just state your problem. If you need inspiration, here is an example: https://github.com/containers/podman-desktop/issues/868

I switched to Rancher Desktop which IIRC uses the same engine and haven’t had any compatibility issues with it.

What is the compose plugin? I don't see a reference to it on the github page

"docker compose" is a golang rewrite of the old standalone "docker-compose" python script. [1]

To install it's simply:

$ mkdir -p ~/.docker/cli-plugins

$ curl -SL https://github.com/docker/compose/releases/download/v2.23.0/... -o ~/.docker/cli-plugins/docker-compose

1. https://docs.docker.com/compose/install/linux

It's usually not referring to as a plugin, but as a standalone utility, i.e., `docker-compose` not `docker compose`.

If you put the binary in that magic Docker plugins directory, it'll treat the binary as a plugin and let you do `docker compose`.

Note that these are two different implementations, the standalone docker-compose has different cli arguments and is deprecated for the plugin (which is also a binary executable as you pointed out)

I've been using Colima for the past few months now instead of Docker for Mac and it's running great. Only issue I experience is that there is sometimes a delay after saving before files are synced to the container (using volumes), so when you run a test directly after saving it will still use the old file, or even worse, files that are still in transit, so you have to run your test again a few seconds later.

Been using Orbstack now for a few days and it seems to not have the same file syncing issue, and is faster in every other regard compared to Docker for Mac or Colima.

I haven't experienced any file write delays, have you filed a ticket against the project?

My guess is you're talking about an in-container write with a host system read.

My CI pipelines do this many times a day for code coverage and test results outputs. Those files are tiny though, so I wonder if it has to do with larger file sizes, or perhaps something external to your configuration like samba mounts that isn't playing well with qemus virtual network interface.

I moved from the Mac platform for all the hoops you have to run though to run containers. On Linux I can do it without a VM. (I also hated window management — hello Sway — and the hardware is cheaper).

I’ve moved from Docker to podman as well on Linux. Love it.

Isn't rosetta a sort of middle ground with pretty good performance?

Docker on Mac runs a Linux VM to put containers in. Rosetta doesn't get around that.

Notable too that the VM it runs on Mac comes with qemu user mode emulation and uses binfmt_misc to run binaries for different architectures so obviates the need for Rosetta.

Edit: to try this out compile a “hello world” binary to say arm64 and riscv64 and amd64 and run it all in the same container (be sure to statically link)

Knew it used qemu but didn't know about binfmt_misc. Very cool. I guess that explains why my coworkers with m1 laptops can run our amd64 containers just fine without changes.

Iirc Docker Desktop uses a proprietary VM now, Colima and Podman Desktop use qemu, and I'm not sure about Orbstack (which has come up several times as a lighter weight alternative within this thread.)

I tried to use colima instead of Docker Desktop several months ago on my Mac, but I ran into several difficult issues (i think relating to folder mounts) and gave up.

orbstack was nice

I've been heavily using bind mounts and volumes in colima so it's likely fixed. I DID encounter bind mount issues in podman, but that was several months ago and might also be resolved. (Edit:typos)

For MacOS I can really recommend https://orbstack.dev

It integrates very nicely, has very low CPU idle usage and also lets you quickly spawn VMs with bidirectional file sharing set up.

Since I switched I haven't looked back.

"no more complicated VMs" -orbstack

Curious how this works without a VM, or have they created some sort of linux "shim", a la WSL1.x?

If it's something like WSL1.x it means you're not actually "running linux", which may have subtle repercussions like differences in threading etc since it's really a Darwin system wearing a Linux suit.

That said if you're writing a CRUD app in python, that probably won't matter to you so it's still worth the tradeoff.

“OrbStack uses a lightweight Linux virtual machine with a shared kernel to minimize overhead and save resources, similar to WSL 2 (Windows Subsystem for Linux). This flexible architecture comes with many advantages such as high efficiency, low resource usage, seamless integration with macOS, and more.”

https://docs.orbstack.dev/architecture

Seems they're maintaining an unpublished fork of the Linux kernel "linux-macvirt" to achieve this. Apparently you have to contact them directly for a copy of the code[1]

https://github.com/orbstack/linux-macvirt

I wish they'd give podman compose just a little bit of love. It's been in a perpetual alpha state for a few years now. E.g.

https://github.com/containers/podman-compose/issues/626

https://github.com/containers/podman-compose/issues/489

The PRs are being neglected too e.g.:

https://github.com/containers/podman-compose/pull/521

Why not write a Helm chart and deploy it locally with Helm or ArgoCD?

You're being downvoted. I disagree with that vote, as I cannot tell if this is serious or sarcasm and that makes it an excellent comment.

Well, once you imagine doing this, you'll quickly realize it is actually sarcasm.

I don’t know… I used to routinely install HPC batch schedulers on my laptops, so I could see someone legitimately doing this (unironically too).

I'm too busy creating Bazel buildfiles for enterprise fizzbuzz deploying it with kubernetes.

Out of curiosity, why do you not want to use the real docker compose with podman, now that it's supported?

Half of the point of podman was to avoid the need to run things with root.

Docker compose expects me to have a server running. While I technically could run "podman system service" and configure docker compose to point at a non-standard socket or port in order to run it I would really prefer not to have that kind of headache just to run a script.

Docker compose was also written by docker and exhibits similar levels of shoddiness to docker. The accumulation of bad design decisions by docker is, indeed, why podman exists in the first place. With a little bit of love podman compose could easily surpass docker compose.

I agree with you on the state of podman compose.

I just wanted to clarify that you can run docker-compose with podman in _rootless_ mode. This can be done by running podman's systemd user service.

FWIW I actually tend to run podman compose inside a podman container. This is so I can containerize the integration tests which orchestrate the app. It's a useful pattern - one I think should be a lot more widely used for several reasons. The systemd service wouldn't work in this context.

I could maybe use some entrypoint magic to run a server when the container starts just so I can use docker compose but still...eww.

Running a podman systemd service might suffice if it was something that could be installed with a snap of two fingers on every environment but if it means fscking around with service files it's definitely not something I'd want to add to a "set up a development environment" README.

I see, interesting. I guess you are saying that systemd service wouldn't work because it's not available inside the container.

FWIW it's possible to run a rootless podman container with a working systemd inside the container. I've near tried running podman in podman using systemd though.

Is it? I think Podman only works with "docker-compose" (the Python-based tool that can be installed separately from Docker, which Podman is compatible with, which is now deprecated) as opposed to "docker compose" (the Golang-based plugin which is integrated into Docker Engine, which I think Podman is not (yet?) compatible with).

Would love to be proven wrong, as I ended up down quite a rabbit hole with this topic somewhat recently.

The Golang version, aka. Compose v2 can also be used standalone (they even have prebuilt binaries in their GitHub repository) and is compatible with Podman. Behind the scenes both Compose v1 and v2 use the Docker API which is also implemented by Podman (`podman system service`).

In my experience they work fine together most of the time, I have ran into compatibility bugs sometimes, though things seem to be steadily improving.

Well that's good to know. I ended up going back to Docker containers, but hopefully this means I can take another look at Podman again!

I was under the impression they were sidelining compose in favor of their k8s manifest flavor which.. Well, let's just say I've never been in a compose file and thought "Man, I wish I was writing k8s manifest syntax".

You can write a tool that translates between compose format and k8s-babble on-the-fly.

When I say you, I mean me. That's my current project.

isn't that https://github.com/kubernetes/kompose ?

We've been using podman compose for semi-production purposes at our company and that's been our experience as well. It's just... it's really rough, there are a ton of "known" issues, and it's rather unreliable. As a result, I've been really trying to push the "just use the docker daemon in prod instead" (to no avail... yet).

> "just use the docker daemon in prod instead"

Can you expand on what that means?

Not op, but the suggestion is likely to use Podman Desktop during local container development. Then switch to the docker runtime in production systems (ec2 etc.)

Podman and Docker Engine are both OCI runtimes. The theory being that containers reproducablly run across different runtimes without changes in behavior.

Switching to Docker in production would probably reveal some edge cases, if not outright incompatibilities, at some point.

I use podman compose in my SaaS to automate and make deployment easier for docker containers, it works great in my simple docker compose (image, name, port expose, volume. that’s it). I suppose use case matters, and mine is very simple, but i’ll just toss one more N=1 in the ring.

I think this is on purpose. Podman is suppose to be a stepping stone to OpenShift. They don’t want people using it for anything other than development.

How many workloads that are currently on OpenShift could sit on a RHEL server behind a load balancer and work just as well?

I would wager that the average OpenShift cluster is under 10 nodes, runs COTS software, and a bunch of security and logging apps like Dynatrace and just sits there primarily under utilizes because the COTS vendor is a RH partner and stopped shipping RPMs and said we only support OpenShift moving forward.

Glad to see usability improvements here, but I won't be using it until there's a light theme (asking an application to respect the OS theme is apparently too much these days).

"Light mode button?" https://github.com/containers/podman-desktop/issues/576

Welcome to the club. So many things still don't support a dark theme either. Why aren't dark/light modes standard these days? Super annoying to have to hide a bunch of light mode windows when I'm in a meeting as they reflect brightly off my glasses.

A very Hacker-News complaint, if I’ve ever seen one.

1997: Now you can completely customize the window UI with any colors you like!

2023: We have no plans to have our UI not blind you past 8pm.

That's because before Mac OS X theming was nearly free for apps, so long as they didn't override colors from the OS widgets.

Once Apple started dictating UI fashion you'll take it as is or inverted. If you have different needs then go pound sand. After a decade or so they suddenly discovered dark modes are a thing.

The move to the web also took some pressure off because you can override colors in your browser ... Unless you have a per-app browser locked inside Electron or similar.

Thank god some (native desktop) software is still sane about this. Look at Blender's granularity! https://blender.stackexchange.com/questions/142666/how-can-i...

Windows 3.1 had Hot Dog Stand and was very configurable. ~1991.

[deleted]

    lynx gopher://hngopher.com

The Dark Reader browser extension works for HN.

Chrome has a force-dark-mode option in the :config too with heuristics on how to change things with different modes.

Dark mode causes more issues than light mode for a lot of conditions. Providing only a darkmode is worse than providing only a light mode, IMO.

Every OS has “system” colors. Even with non-native widgets, I have no idea why people don’t use those.

HNcute for chrome still works nicely!

https://caro.io/hn-cute

I had to hard facepalm reading the other replies to this. There are people suffering from things like Astigmatism (myself included) who have an extremely hard time, including headaches, using dark themes. People really need to be a bit more empathetic.

Also, as the OP pointed out, people somehow get angry when all you asked is for an app to follow the system's theme. It has been such a huge regression.

EDIT: typos and clarity

> Also, as the OP pointed out, people somehow get angry when all you asked is for an app to follow the system's theme. It has been such a huge regression.

Was there a time when Podman Desktop supported a light mode? You could change the CSS yourself, which given you only need a light mode, would be pretty trivial.

Please keep in mind that dark themes were introduced as an accessibility feature as well, but not every project can or will prioritize it.

My bad, I did not mean a regression in Podman Desktop specifically, but UI engineering in general. A (couple of?) decades ago it was basically a given that apps will adjust to your system theme (except fancy stuff like Winamp).

> Astigmatism

Wait, is this why I've stopped liking dark mode? I was diagnosed with astigmatism a few years ago. Never connected the two until now.

I find it physically unpleasant to look at during daylight hours, in a way I can't explain to my coworkers.

As a counter example I too suffer from astigmatism and I prefer dark themes with high contrast. Sometimes I'll pick a theme that doesn't exactly vibe color wise just for the high contrast otherwise it's hard to focus, both mentally and actually reading what's on the screen.

I also zoom in most websites, UIs, code editors and the terminal, so take my personal experience as just another point and nothing definitive.

Yep it is quite possible. For me the realization wasn't until the doctor specifically pointed it out that no lens will 100% correct Astigmatism. Then I googled around and read that dark text on light bg is much easier because the ghosting is less pronounced.

I miss my white-on-black Terminal though :(

Where are we at on Podman these days?

If I recall, Podman really caught fire with this community after Docker started trying to charge more people for software. But then Red Hat (i.e. Podman's sponsor) started trying to charge more people for software too, and also became a pariah with this community. It's hard to keep up.

Podman is not the sole product of the people behind it, so they're less motivated to go down the Docker hole, imo.

I used instead of Docker for a while because it came by default on RHEL (I'm using 8).

It has very impressive compatibility with Docker. For 99% of use cases you will not even know you are using Podman. The one case that forced me to uninstall it and use Docker was running `gitlab-runner`'s integration tests which do some funny things with Vagrant and VMWare, and Podman didn't like it. But overall I am very impressed with the compatibility.

There aren't really any advantages to using it for individual users. Being rootless is a huge upside on the server though. At my previous company I accidentally deleted all the containers running on a server because I naively assumed that Docker followed the normal permission model and would only let me delete my containers. Imagine my surprise when I learned that Docker basically runs as root and all users that have access to Docker have root access!

Of course I only made that mistake once, but still... Crazy design.

> There aren't really any advantages to using it for individual users.

Cheers, but his is not true.

Running a container without root privilege is a security advantage for users who run containers that (inevitably) contain vulnerabilities.

Even more so if said containers contain Trojans.

Bit more secure than running directly, but if the container is broken out of, attacker directly gets root.

Adding to the parent's point. The docker hub is full of malware images and the docker devs could not care less.1.2.3.

1. https://www.bleepingcomputer.com/news/security/docker-hub-re...

2. https://sysdig.com/blog/analysis-of-supply-chain-attacks-thr...

3. https://www.bleepingcomputer.com/news/security/thousands-of-...

It's often the case with software "repositories". Pypi, npm, Maven... Security is expensive.

An organisation needs money, on-staff security professionals, and (of course) lawyers to explicitly commit to maintaining a package system.

Even MAAMAN (was FAANG) app stores have been exploited.

FYI your second link is broken or dead.

This is so true… also different users on the same machine can have their own podman daemon mimicking their own private docker daemon.

In some cases it can be useful to run different containers as different users.

You have sudo though presumably, so there's not much difference between giving it access to your account and directly giving it root.

Important to note: docker now supports running everything as rootless, with the same caveats as Podman.

>There aren't really any advantages to using it for individual users.

I'd consider not having to run a service I give root on my machine just to run some containers an advantage as a individual (dev) user.

And however crap RH/IBM itself is, not dealing with Docker corp is also quite good.

If you need to use buildx it is a slog to get right. The split between root and rootless is also wrought with forking guides and very confusing to triage. For example, rootless needs more care with capabilities.

I managed to build and run a Docker compose setup that had been used exclusively with Docker for years without issue.

The problem came when trying to get other systems to talk to Podman in place of Docker. It just ... didn't work.

> But then Red Hat (i.e. Podman's sponsor) started trying to charge more people for software too

Podman is free as is Podman Desktop.

Red Hat didn’t raise its prices.

CentOS Streams and Fedora is still free.

Oh you mean they made it difficult for Rocky to build the SRPMs. Sorry sorry. Hard to keep up with the FUD.

Exactly. Red Hat is ending some things others never even considered to offer. Yet, people stand in line with... Oracle, WTF. FUD sadly works.

Especially while RH still making things accessible for people without money and testers, e.g. https://developers.redhat.com/articles/faqs-no-cost-red-hat-..., includes RHEL, Software Collections and Application Streams, Developer Toolset and Compilers, Red Hat Insights access (sic!).

podman and podman-compose became mainstream and replaced docker for me in "server" scenarios on rhel8/rhel9, fedora and derivatives. Glad to see progress on the desktop!

Podman Desktop is getting really good. But the only thing preventing me from using Podman right now is the fact that Docker has BuildKit, and BuildKit has some really nice features like Secret Mounts, Cache Mounts and SSH Mounts.

I've been using it since I migrated our container builds to buildah (docker-dind is spooky) and I needed something Docker-Desktopy without paying for a license. Works great. Even supports Docker Desktop plugins, which was a surprise.

If you're using Linux (especially with Gnome), I can highly recommend Pods[1] as a desktop client for Podman. It's much less cluttered than Podman Desktop, but still supports most of its features.

[1] https://github.com/marhkb/pods#readme

Can someone link me to what Compose means in this context? Google takes me to https://github.com/containers/podman-compose but I just wanna make sure that's what they are talking about.

https://github.com/compose-spec/compose-spec/blob/master/spe...

I do prefer podman over docker. It just feels lighter (idk what it’s like under the hood)

Have they fixed the macOS time drift issue yet?

No, they also haven't fixed the machine "failing to start" (but actually starting anyway) and not mounting volumes. I'm switching back to Docker.

Do you have an issue no.?

https://github.com/containers/podman/issues/20081

https://github.com/containers/podman/issues/20428

https://github.com/containers/podman/issues/20462

https://github.com/containers/podman/issues/19611

I will forward these to the team.

Sorry for the late reply.

Why are we lumping a Linux kernel feature (cgroups) on top of macOS?

You mean the time skew when you have your machine sleep (close the lid), right? We have fixed this a while back; this was part of CRC almost 2 years back and we backported this to Podman Machine. If you still see this, let me know and I'll have someone look at this again.

I've seen this as recently as a few weeks ago on Podman 4.7.1 on a 2019 16" Intel MacBook Pro running Monterey 12.5.1, although I hadn't recreated my Podman machine VM in a few months so it may have been running an outdated image; certainly not a 2 year old one though. In my case it manifested as TLS failures due to an "expired" certificate.

Yeah it is still happening on fresh podman install as of a month or so. So many of my coworkers ran into the issue there is an internal wiki about it. The hwutil sync command thing works but it’s annoying.

Why or how is this different from running podman in Ubuntu/fedora/Linux?

It is a GUI for working with podman, docker, and kubernetes. It is functionally similar to Docker Desktop, which is also just a GUI to work with containers. It is a tool for those that prefer working with containers with a GUI instead of the terminal.

> It is a tool for those that prefer working with containers with a GUI instead of the terminal.

Sort of. In the case of podman desktop, that is true because you can opt to just install the cli podman if you prefer.

But in the world of Docker, they force end-users on Mac (and I think windows) to install docker through docker desktop even if you don't ever touch the GUI. I don't use the GUI ever, but can't find a way to install docker on Mac outside of the GUI. Maybe there's a way, but at least on Docker's website it seems to be the only way and at my company with ~100 devs no one else has figured it out either.

On windows I just use WSL2 with docker installed through the Linux distribution (Ubuntu in my case). This way I get docker on my windows Laptop without the annoying docker desktop

Did you follow a particular guide for how to do that?

I remember trying a while back, when WSL2 was first released, and I couldn't get it to work; IIRC I couldn't get stuff running in Windows to communicate with stuff running in containers in WSL2, and also vice-versa.

On WSL2, you just install Docker the same way as you would do on Linux. `sudo apt install docker.io` (from Debian/Ubuntu repo) or `curl https://get.docker.com | sh` (from Docker Inc). If you are using different WSL distribution, the standard way to install docker should work just fine. (e.g. `sudo pacman -S docker` works as expected on ArchWSL)

I agree. I do remember that in earlier versions WSL2 this approach didn't work, but currently it's the same as installing docker on a regular Linux distribution

Nice! Are there any limitations to be aware of?

I wanted to build a Windows container image but I really did not want to install Docker Desktop. After some digging around I found my way to the Docker server / client binaries for Windows page that allowed me to do this: https://docs.docker.com/engine/install/binaries/#install-ser...

Thanks, that's good to keep in mind if I ever need to run docker engine on windows!

I think you can use docker-machine for this purpose: https://datamachines.com/blog/how-to-install-a-docker-machin...

> But in the world of Docker, they force end-users on Mac (and I think windows) to install docker through docker desktop even if you don't ever touch the GUI.

They try. But between homebrew and Colima you can get away with cli tools.

Well the most significant difference [on macOS or Windows] is you must use a VM (by default Podman Machine) so there can be a Linux kernel to run the containers.

This is a significant limitation that you do not have when running on Linux. As I recall there are some other (related?) features that are not implemented on the macOS.

[edited to reflect that I misread the parent and thought they were specifically asking what was different on non-Linux platforms)

Another Electron app that isn't visually integrated with Linux -- under GNOME/Wayland the app does not have native or at least native looking window buttons, it also has sharp edges without a shadow behind the window, as all other apps.

This is a surprise as Podman Desktop development is lead by RedHat, a company not only behind a Linux distro but one that leads the GNOME project.

Podman Desktop is mostly for Windows users.

But Electron still feels like a wrong choice. Plugins for Visual Studio Code or Eclipse would be nice.

> Plugins for Visual Studio Code or Eclipse would be nice

Can't you just use the docker plugins and configure the binary of the docker plugin and point it to the podman binary and it should work. Or just alias podman as docker

I'm a little confused, podman is just IBM docker, right?

I was right, it's redhat docker.

Reply on news.ycombinator.com