[PufPufPuf]

One thing I don't like about Podman is that it pretends to be docker-compatible while having some minor differences that will come to bite you. And users of your docker-based project who try to run it on Podman will come to you and complain.

[2bitencryption]

I've found most of the differences to come not from the socket API, or the logical behavior, or CLI differences. But instead from assumptions Docker makes, that it's running rootful, when Podman will not (by default).

As such, most of the fixes for Podman/Docker incompatibilities is just addressing that assumption with a few extra flags on the Podman commands to change how the user namespace maps between the container and the host, etc etc.

[figmert]

This has been my experience too. And that conclusion, I've found that if I really don't want to deal with such quirks, I can indeed literally just run the same docker compose file in rootful mode, and it works.

Making the changes required to run under rootless is often very simple.

[PufPufPuf]

There are also different CLI flags (I recall something related to building and pushing multi-arch containers) and different features supported in compose.yml. Even rootful Podman won't be fully Docker-compatible.

[DarkUranium]

My #1 complaint by far is that it --- pretty much silently --- depends on systemd to work correctly.

Try having a docker-compose with a service that waits until a dependency is healthy --- in a host that has no systemd (such as Alpine Linux).

The service will never start because Podman relies on systemd (and only systemd) to do the periodic healthchecks which it needs to do in order to handle such dependencies.

And of course, this fact isn't adequately documented anywhere. And Red Hat says they'll never, ever drop this dependency.

---

But I don't know if there are any tools compatible with the Docker ecosystem other than Podman. I'd love to find one.

[stryan]

Yeah that's an unfortunate downside of the daemon-less design. Service management (like dependencies, health checks, etc) are outsourced to systemd since there's nothing locally available to monitor them. The fact that the documentation doesn't mention this is a major miss.

For anyone curious, there's more details on why this is tricky to do with Podman at https://github.com/podman-container-tools/podman/pull/27033 .

[chuckadams]

On macOS, there's Orbstack, which is ridiculously compatible (I believe it's based on the same moby engine underneath). On Linux there's oodles of options for working with OCI containers, but nothing else I know of that's compatible with the docker API or CLI.

[rgovostes]

I've been using Podman on Mac and Linux for 3 years, and unfortunately, I have found this to be perennially true. I am willing to doggedly pursue the root cause and file bugs, but for many people it will just seem broken.

Most recently: Netavark doesn't match Docker's behavior with accepting broadcast traffic on a published port.

[tikkabhuna]

Yes! It put me off Podman for years. I do now think it has some clever ideas and if you’re running RHEL it’s a no brainer, but they should be more upfront that you will have to adapt. Especially if you’re moving from rootful docker to rootless Podman.