Comment by cdmckay
8 hours ago
I switched to Podman because it’s daemon less (no resources are used unless a container is running) and it doesn’t need to run as root.
Otherwise it’s basically the same and you can continue using your Dockerfiles and Docker Compose files.
Unless you’re doing something really fancy it’s basically a drop-in replacement.
The only issue I’ve run into with Podman is that, like docker, I can’t have the container’s process be part of my shell’s foreground process group. For docker the daemon (either rootful or rootless) makes that inevitable, but podman has better rootless support, so I’d been hoping.
Unfortunately, there’s an unconditional setsid during podman’s container setup, which as far as I could tell exists so that the container can be detachable.
(This was all so that I could have the same job management with Ctrl-Z, SIGSTOP, SIGTSTP, fg, and bg, regardless of whether the process I’m running starts up a container. The only way I’ve found to have that is by handling chroot/unshare myself.)
UNIX job management is fundamentally broken already in that it simply can't be properly nested, even with PID namespaces. If the "container’s process [is the] part of my shell’s foreground process group", then it can not, literally can not, job manage its children.