I have a lot of compose files in my homelab/automation setup and those are what I’m most concerned about.
I have a lot of compose files in my homelab/automation setup and those are what I’m most concerned about.
Podman doesn't officially support any thing platform agnostic. How do you (or anyone) deal with this for a project in active development?
Most compose files are small and use familiar linux jargon.
I can give an non-dev IT person a compose file and they can understand every key. I can’t do that with K8s or Quadlet.
The only issue I have is validation, there isn't a convenient built-in command to validate quadlet files and systemd doesn't warn you if any fail to generate. You either have to do a --dry-run first (and probably alias the full command to something reasonable) or check the journal for errors.
For quick conversions you can use compose files directly with podman-compose or docker compose pointed at the podman socket[0].
There's also podlet[1] which converts compose files into native quadlets. It does a pretty good job of taking care of everything for you and for a lot of simple to medium complexity compose files it will Just Work. There's talk of making it into a library of some kind so other tools can transparently convert compose files to quadlets so hopefully we'll see more stuff like it.
Otherwise, writing your own Quadlet files isn't too hard if you're at all familiar with systemd unit files. Most `docker run` or `podman run` arguments have direct quadlet conversions so once you get used to the INI format versus yaml it's pretty easy to see a compose file and churn out the equivalent quadlet(s).
Absolutely zero regrets, would never go back.
Others have pointed out that you can use podman-compose or docker-compose pointed at podman. I did something different: I switched to using systemd to manage all my containers. It was worthwhile as I can just use my usual systemctl and journalctl utilities for both containerized and non-containerized services rather than having to remember two sets of commands.
I only experienced one minor issue with pasta (used by podman) with networking, but by then I had fully committed to podman so I did not even try to see whether I would have had this same issue if I were using docker.
I have zero issues with it doing the builds I need. Works same same as Docker from what I can tell.
I took Docker completely off my Macbook which has a tiny drive in it. Hardly ever use it, except for testing. Podman is super lightweight and using a project I'm developing, launches containers with dev agents in it, just the same as Windows running Docker.
I have the feeling the docker company is communicating a lot with Apple because virtualisation got better and better over the years. I wonder if podman would be a speed downgrade here?
Doubtful. But for sure it would be a compatibility downgrade. When I tried podman-compose a couple years ago, I found it nowhere near usable, though I'm told it's improved since. If you want a better Docker for mac, you're looking for OrbStack.
Highly recommend Podman overall; there are some quirky edge cases, but for the most part it’s a smooth replacement for Docker.
If you don’t want to give up compose entirely, podman-compose exists. I just prefer Quadlets so I haven’t used it much myself.
I will try again. Currently I have a systemd service that tries to start my services with `podman compose `. Sometimes this fails, when I start the service interactively it just works. Unknown what exactly is the issue.
I'm also using podman-compose that is small and delightful (I had to fix a few bugs there). It's just one Python file that you can copy.
Just curious, what might be the cause of such speedup?
What I'm experimenting with right now is defining stuff with a Kubernetes yaml, which podman also supports: https://docs.podman.io/en/latest/markdown/podman-kube.1.html.
It's slightly more verbose than docker-compose, but podman supports it natively and you can actually wrap your app containers into a single "pod" for easier management.
Other than that, I haven't found anything that makes me consider using docker again.
Regardless it works enough for me to run local Kubernetes and Tilt
There is however, the LLMs that pull their fair share of documentation, or rather, replacing it. Not opening that can of worms here, but heck am I glad I can query `$AI` about occasional Podman "burst pipe", instead of hitting Google and looking for [that one e-mail message from a guy who had exactly the same issue, solved it _and_ had the wherewithal to post the solution](https://xkcd.com/979/).
We never got into use of `docker compose`, not in any capacity to speak of, and these days we use Kubernetes and OKD/Openshift for things that Docker -- in my understanding -- solves with swarm and composition. It works well enough, I almost don't find it worthwhile to mention that it does :)
The few cases where something was not directly translatable was <10 minutes with a coding agent to make some minor config changes, and then it just worked.
For anyone with a working homelab there is no reason to switch
If you're worried about security, both need extra work
Podman has been mature and sane. In cases where $someone's container depends on su privs, I blame the $someone, not Podman.
Having a heterogenous fleet can be annoying though, some Podman-only config values[1] stop Docker dead in its tracks because it hates unknown fields.
1. It was a while back, and I can't remember what specific field it was, but it had to do with namespacing and/or (sub)UID mapping.
On the other hand I could see it being hard for people to only install the cli part of docker. Luckily on arch that was simple due to how it's packaged.