[cpuguy83]

Docker's runtime is long spun out into containerd (though there is more work to do here). Builder is in buildkit, which sits on top of containerd.

Would be nice to decouple networking, this will take some work.

Docker is more and more becoming an API that sits on top of a bunch of other services. It does take time to make this happen without breaking compatibility, though.

Docker can also run without root as of Docker 19.03. Even so, "docker requires too many privileges" is marketing speak. Setting up cgroups requires root, setting up mounts (w/o fuse) requires root, setting up network devices requires root, etc... anyone who wants to do these things requires root. Rootless mode on all this tech attempts to work around such limitations, but each workaround comes with trade-offs (slower networking, no cgroup support, slower fs access...).

Definitely agree, though if you want to run services through systemd Docker is not well designed for that purpose.

[jacques_chester]

> Docker is more and more becoming an API that sits on top of a bunch of other services.

Which is a good thing. With Cloud Foundry we moved from using a pre-Docker container engine to using runc as soon as it was available; containerd is the next move.

> Even so, "docker requires too many privileges" is marketing speak.

I don't agree. The API surface still exists and includes too many disparate purposes. The modularisation of Docker is improving that risk profile, but it still exists. Fully segregating the API and the modules is worthy.

[cpuguy83]

Modularization improves maintenance overhead, it does not reduce privilege.

[jacques_chester]

I understand that. My point is that it reduces the blast radius of any one part being compromised.

[windexh8er]

Agreed. One other point is containerd isn't a Kubermetes specific runtime. Why cri-o chose to lock in like that doesn't seem to make long term sense except with regard to ease of development.

[cyphar]

The long-term goal is to switch users to use podman (and buildah I guess), with cri-o being a daemon that uses the same underlying code. The only reason a daemon is required in the first place is because the CRI uses gRPC.

This is loosely similar to how rkt operated, with rktnetes just being a front-end for rkt (though at the time, the CRI didn't exist so it was all hardcoded in Kubernetes).

The goal isn't to have a differently-named daemon required in order to do any operation, and podman enables that (though again, so did rkt).

[windexh8er]

Thanks for your insight! I guess I don't understand why having multiple runtimes helps. If CRI is just an agnostic interface to the tooling what is the advantage of cri-o over containerd? Why make the ecosystem harder when it's all a standard runtime interface anyway? Couldn't Docker tooling, podman and buildah all talk directly to any runtime?