podman

Maybe podman “just works” on Linux but it still has some work to be done before the same could be said for macOS. E.g. https://github.com/containers/libpod/issues/4039#issuecommen...

> Will this make it easier to run docker without root / sudo? No, because 4.6 is pretty old at this point and this feature has been around for ages. I've been using podman instead of docker more and more recently, it's pretty great. It doesn't require root access to the machine (that's how I use it), although there are some limitations. https://github.com/containers/libpod/blob/master/rootless.md

Fair point re: conmon, and yep, even in the strictest sense of the word, it is a daemon now that I read up on how it executes the container. I guess it's better to say that only a monitoring daemon is required with this setup (rather than all of the additional daemon services that docker provides). Re: rootless podman, it looks like there's a good resource to track progress here: https://github.com/containers/libpod/blob/v1.6.2/rootless.md - that must be a common ask, could be interesting to track. (I'm definitely guilty of being overoptimistic about these tools, but do hope they improve because the principles behind them seem very sound)

I'm a little bit too familiar with podman. LXD is more mature and actually implements all of the hardening features I mentioned. podman could implement them in theory, but doesn't. Its default security posture is very similar (though not the same as) Docker. Don't get me wrong, I do want to see podman succeed -- but I don't like the amount of unneeded hype around it. It's effectively a Docker rewrite by Red Hat (and other folks) that has some fairly important improvements, but it's not a revolutionary new concept. As for buildah, I am too biased to respond to that question. Oh, and most of the Docker CVEs found in recent years -- including those I've found -- have also impacted podman. The most brazen example is that podman was vulnerable to a trivial symlink attack that I fixed in Docker 5 years ago[1,2]. It turns out that both Docker an

I read about Varlink while taking a look at podman, which uses it as a remote interface [1]. I don't think it does anything _much_ different than protobuf or JSON-RPC but simply IMO tries to create a common interface to interact with software or daemons. Protobuf is by itself just a protocol and encoding format, while Varlink wants to create a generic network-independent RPC interface you can easily access from your shell. I'm not sure I understand what's the underlying transport protocol (HTTP? custom one?) but having JSON as encoding format is pretty nice, any shell script could talk with it and it's eas(ier) to inspect. It looks like a generalised version of DBus, without requiring a central daemon. I think it looks pretty cool. EDIT: also it seems to natively handle subscriptions/polling for changes. EDIT 2: the transport protocol is

While it still needs work for performance and other things, Podman already supports rootless containers using user namespaces. It's actually pretty easy to setup too, especially on Arch: https://github.com/containers/libpod/blob/master/rootless.md

Comparing the shortcomings of rootless podman (https://github.com/containers/libpod/blob/master/rootless.md) and rootless docker, they seem almost the same. So this argument may not count, the daemon argument however applies.

Very kind of you to ask, but unfortunately I don't have time to work on this right now. Here are some resources to help get started though and maybe a community that can help: https://github.com/kubernetes/minikube/blob/master/docs/vmdr... https://rootlesscontaine.rs/ https://github.com/rootless-containers https://github.com/containers/libpod/blob/master/rootless.md

rkt is basically dead and so is rktnetes. However, docker internals have basically been replaced with containerd[0] in this point -- the two front runners in the battle to actually run your containers (and power higher level abstraction tools like docker) are containerd[0] and cri-o[1]. I personally prefer containerd, but there are a lot of people who are obsessed with cri-o (big company backers, from what I can remember), despite the fact that it's chronically behind on features (for example alternate runtimes, runtimeClass support), but they're both excellent. Note that there are also other projects like podman[2] that also aim to serve as docker replacements. Discussion on containerd shim in docker can be found on google group[3] way back in 2016. [0]: https://github.com/containerd [1]: https://github.com/cri-o/cri-o [2]: https://githu

I just looked at https://github.com/containers/libpod/blob/master/docs/tutori... . For debian/ubuntu users (of which there are a fair quantity) whilst podman's install process looks like that, I don't see it taking over from Docker any time soon. Not to mention Windows/OSX users. Ease of use should not be overlooked when it comes to developer tooling. Podman can be the most technologically advanced solution, but if it's a pain for developers to get going with it, it's not going to replace Docker any time soon...

Since there are two redhat/podman powerhouses in this thread, first of all thanks for all the hard work! It's not like I'm anti-docker, but it has some hangups that I'll be happy to get away from when I have the chance. I feel like being tied to docker for so long made it harder to understand other tools like ctr/critool/containerd early on. Second thing -- I haven't looked into it much but do you know how the docker in docker support is in podman? Is this thread (https://github.com/containers/libpod/issues/746) the right one to watch?

In some situations rootless works better, e.g. I was not able to use podman with sudo in a container that had `ping` in it [1]. OTOH rootless uses `fuse-overlayfs` instead of the in-kernel overlay2 driver, and initially I ran into a few bugs since it is not yet a fully POSIX filesystem (much like how the initial overlay kernel driver was buggy , and it wasn't only until overlay2 when it started working reliably with docker). Having said that I've been using only podman as an experiment at home, and upstream is very responsive in fixing bugs. There is also a `vfs` backend that can be used as a fallback until bugs in fuse-overlays get fixed. Would be nice if someone developed a testsuite that exercises all the usual FS operations that a container uses (permissions, setuid, setcap, symlinks, etc.) and compares vfs vs fuse-overlayfs vs in-ker

(not a Red Hat employee) My understanding is that many, if not most, operations should not require sudo as of version 1.0. For example, try the commands at https://github.com/containers/libpod/blob/master/docs/tutori...