Dumb question: is it rootless for users on something like macOS?

I'd love to get the benefits of Docker without the battery drain and the Docker software, but I'm not sure if Podman would help much with either.

On macOS it creates a centos VM to run containers in. Rootless simply means that the root user in a container maps to the runner outside and not as the actual system root.

Edit: .. because the runner is not needing to run as root

I vastly prefer it to Docker, especially buildah over buildx. Instead of inventing yet-another-dsl buildah allows you to simply use shell scripts (though it does also support dockerfiles). Another thing buildah is really good at is not doing much automatically: you can really optimize layers if you care to.

The Podman ecosystem has given me a strong disliking of the Docker ecosystem, so I'm also rooting for it.

I think I might be the only one that prefers Docker for building Docker containers using CI.

I use Drone, but instead of using the Docker plugin I start a detached (background) Caddy server to work as a proxy to DOCKER_HOST. That lets me proxy to the local Docker socket to take advantage of caching, etc. while I'm iterating, but gives the option of spinning up docker-in-docker to get a clean environment, without any caching, and running a slower build that virtually identical to what happens on the CI server.

I find that having the daemon available solves a ton of issues that most of the CI provided builder plugins have. For example, with the builder plugins I'd always end up with a step like build-and-tag-and-push which didn't work very well for me. Now I can run discreet build steps like build, test, tag, push and it feels far more intuitive, at least to me.

I only dislike Podman because some distributions used it as an alias for docker which made a lot of docker-compatible software to not work on that distribution unless some workarounds. I wouldnt normally blame the application for this but in this case they are both, application and distribution, from the same dev.

Agreed, the `podman` command is 95% drop-in compatible with the `docker` command, but those edge cases are annoying and I would rather just use the docker cli backed with podman running the containers.

Podman has a docker frontend. On Fedora, it is packaged as podman-docker, I believe. I recently went through the pain of getting testcontainers working on Fedora 41 with Podman. After enabling the Podman socket and setting an environment variables, I was off to the races!

+1, Podman is great. I have been running it for a while on NixOS.

But Compose doesn’t mesh well with the overall NixOS configuration system. So I ended up building a custom tool that can convert your existing Compose project into a NixOS config.

I completely agree and have had the same experience as you with docker-compose working better than the alternatives.

Past versions of podman were flaky, but since version 4, which is now a couple of years old, I haven't had any issues whatsoever. I'd recommend anyone using containers on linux to try it out instead of installing docker out of habit.

If podman compose would parse env var strings correctly, then it would be on par. Not sure why that hasn’t been fixed but probably because it’s a stepping stone instead of a well thought out replacement.

The IO through fuse-overlay is performance limiting though. It's almost half the speed as overlay directly for layers with many tiny files.

Note that Linux allows you to mount overlay within a user namespace if you are root within the user namespace.

In other words, if you are root within a container; even though it is not root on the host; Linux accepte ton mount overlay filesystems (most filesystems are not allowed). `man user_namespace`

You may need to do

  podman system reset

The Linux kernel only gained unprivileged overlay recently. Kernel fuse and fuse-overlay are incompatible so you need to wipe everything.

You may need to set

  [storage]
  
  driver = "overlay"

in storage conf as well.

https://docs.podman.io/en/stable/markdown/podman-system-rese...

> docker-compose with a single env variable what is that env variable?

Probably DOCKER_HOST[0][1]

[0]: https://docs.docker.com/reference/cli/docker/#environment-va...

[1]: https://podman-desktop.io/docs/migrating-from-docker/using-t...

Thank you

yeah, basically verbatim `DOCKER_HOST=unix:///run/user/1000/podman/podman.sock`

> It's also usable via docker-compose

Is that "docker-compose" (with a dash) or "docker compose" (with a space)?

Both should do exacly the same, they are just installed differently. docker compose is installed as docker CLI plugin (Linux only), and docker-compose is installed as standalone binary.

See ref: https://docs.docker.com/compose/install/#scenario-two-instal...

There are subtle differences between the two and not exactly the same.

That would be news to me, as both are pointing to the exact same GitHub repository[0]. Can you name the differences?

[0]: https://github.com/docker/compose

Previous docker-compose was a separate program, written in Python if I remember correctly, people usually preferred to them as v1. Later docker incorporated it into the docker binary itself as a subcommand so that’s v2

v2 is still a separate binary, it can just be installed in different ways (on Linux). If GGGP was referring to v1, then that's legacy software since 2+ years and they probably shouldn't use it.

The one problem I previously hit was that the ansible integration used the Python version; I hope they've fixed it now but haven't looked lately.

Looks like v2 is available: https://galaxy.ansible.com/ui/repo/published/community/docke...

On the I've hand: that's great news!

On the other:

> The Docker compose CLI plugin has no stable output format (see for example https://github.com/docker/compose/issues/10872 ), and for the main operations also no machine friendly output format. The module tries to accomodate this with various version-dependent behavior adjustments and with testing older and newer versions of the Docker compose CLI plugin. Currently the module is tested with multiple plugin versions between 2.18.1 and 2.23.3. The exact list of plugin versions will change over time. New releases of the Docker compose CLI plugin can break this module at any time.

AFAIK docker-compose is a an older utility, and `docker compose` is the new-way to do things.

> Rooting for it.

No root necessary :)

> Rooting for it.

I wanted to say something funny about "rooting" and "rootless", but it's probably too silly. :)

Ruthlessly rooting for rootless!

until you start to use zfs.. (completely doable with fuse overlay, but just painful)

For posterity, there have been some issues when destroying containers. Errors about "inconsistent state of container" or such. But these have always been about non-running containers, so the answer has been destroy/recreate, so no measurable impact for the business. After spawning and destroying thousands of containers in a high-load live environment(across half a dozen servers), I consider podman pretty stable.

And assuming my own comment is high up, this is the env variable we automatically load:

> DOCKER_HOST=unix:///run/user/1000/podman/podman.sock

Honestly everytime i wanted to use podman i hit a bug, which is already fixed most of the time but i can't get the new version because they don't have any direct repos to get updates from, this is very helpful for docker.

Also networking in rootless containers still suck.

The end result is just go bakc to docker with less hassle and better stability.