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 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 ?

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 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.