Is the compose support recent? Tried earlier this year, and it was not nearly there. And I use docker compose stuff as remote interpreter in IntelliJ/Pycharm stuff, that didn't work well with podman when I tested.

I don't really care what I use, I just want to be able to develop locally without spending days setting stuff up. Rootless or whatever means nothing to me. Docker compose have made that easy for lots of otherwise complicated projects. Just compose up, point editor at the image and ready to go.

It is at least a year or so old. But there have been quite a few bugs, and iirc it was only at v4 where incompatible bugs have been ironed out. Not that it wasn't usable previously, you'd just run into a few issues.

> Not that it wasn't usable previously, you'd just run into a few issues.

I don't like that definition of "usable".

Compose v2.0 compatibility became available only since last month which was very late.

If podman isn't for technical benefit, is this all about political decision for RH to govern container ecosystem on their own instead of dealing with docker?

Podman has a few tricks up its sleeve that Docker can't do. Among other things:

- `--rootfs` lets you start a container from a directory instead of an image

- You can configure alternate container storage locations, e.g. to share a common library of container images among multiple machines over NFS

- As previously mentioned, it has the k8s-like notion of "pods" which are multiple containers sharing namespaces with each other

- It will play nice with systemd, both inside and outside of containers, and can generate systemd services for containers

I think the last point is really why Podman exists in the first place; IIRC, Red Hat's developers made a valiant effort to get patches into Docker to improve its cooperation with systemd, but the folks working on Docker weren't interested. If Red Hat's patches to Docker had been upstreamed, Podman might not exist.

Sounds nice and all but I really liked docker compose for setting up containers, I'll have to find out if podman has full docker compose support yet, then maybe I'll switch.

Last time I tested it, it had some downsides, but "last time" was like at the start of this year so things maybe might have improved since then.

4.1 fully supports both the old 1.x Python versions of Compose and the new 2.x Go versions of it - you need to use the docker CLI if you want 2.x though.

I can understand the aversion to Red Hat control but the desire to use Podman is obviously arising from the concern about Docker control of the ecosystem.

On my system I have a very small `docker` script that selectively calls either `podman` or `buildah bud` depending on the first arg. The CLIs are completely compatible.

Is there any config to set up this way or do you literally just run podman on the socket and it just knows what to do?

You can set it as systemd socket service, so it doesn’t even run until something tries to connect.

That said, I don’t even bother with that. Podman can run K8s configs, and they are yaml too, only slightly more verbose than a compose file, if you strip everything out you don’t need. The CLI is nicer than compose too, with proper commands instead of tying up a terminal until a ctrl-c.

So you can use kubectl but it talks to podman and not to the api of a k8s cluster? Or does it have its own cli?

There's apparently a 'podman play kube' command that can take some k8s yaml like pod descriptions and instantiate them directly: https://docs.podman.io/en/latest/markdown/podman-play-kube.1... I hadn't heard of this until now but it sounds pretty nifty!

Exactly. Here's a pod.yaml I use for testing a service at work:

https://gist.github.com/pkulak/d22407b887461b416891b78fb3793...

It can probably be even more concise, but I stopped stripping stuff out here.

> There's apparently a 'podman play kube' command that can take some k8s yaml like pod descriptions and instantiate them directly

Wow that's a heck of a killer feature.

Once Podmam implements a replacement for Docker's docker swarm, Docker is effectively deprecated.

I honestly wouldn't put much faith in swarm being viable for long. Mirantis basically stopped working on it before they broke docker apart. The current docker company seems much more focused on developer experience tooling, not distributed systems. There are some longstanding swarm issues and bugs, particularly with changing configurations or one time jobs, that will probably never be fixed. I'd go straight to kubernetes and skip swarm personally. Stuff like k3s make kubernetes much easier to deploy at a small scale. Or I'd look at Hashi's nomad if something about k8s was really a blocker.

podman replacing the docker socket

https://www.redhat.com/sysadmin/podman-docker-compose

As a fun fact, you can also run:

    $ systemctl --user enable --now podman.socket
    $ export DOCKER_HOST=unix:///run/user/$UID/podman/podman.sock

and get a rootless, Docker-compatible socket. If you're running, e.g., a test suite written against the Go Moby APIs, this will execute the containers with Podman rather than with the system daemon.

Wow did not know about full compose support going to check it out now.

That took a while... Although I don't see what benefit I get by going podman when docker works fine and I don't really care about theoretical rootless security enhancement.

Can I use Docker on my company projects, or can I use it for personal use only? I was under the impression that Docker doesn't allow professional use with the unpaid license, though I might have gotten it wrong.

Depends on the size of the company. Over $X revenue or over Y employees and you have to pay. Note that it says revenue, not profit there, be careful with that.

And that's why Docker is dead.

Rootless pods in production sound dope. Keeping a security mindset while developing locally makes sense, no?