[22.06 backport] daemon: support other containerd runtimes (MVP) #43887
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Contrary to popular belief, the OCI Runtime specification does not specify the command-line API for runtimes. Looking at containerd's architecture from the lens of the OCI Runtime spec, the shim is the OCI Runtime and runC is "just" an implementation detail of the
io.containerd.runc.v2
runtime. When one configures a non-default runtime in Docker, what they're really doing is instructing Docker to create containers using theio.containerd.runc.v2
runtime with a configuration option telling the runtime that the runC binary is at some non-default path. Consequently, only OCI runtimes which are compatible with theio.containerd.runc.v2
shim, such as crun, can be used in this manner. Other OCI runtimes, including kata-containers v2, come with their own containerd shim and are not compatible withio.containerd.runc.v2
. As Docker has not historically provided a way to select a non-default runtime which requires its own shim, runtimes such as kata-containers v2 could not be used with Docker.Allow other ContainerD shims to be used with Docker; no daemon configuration required. If the daemon is instructed to create a container with a runtime name which does not match any of the configured or stock runtimes, it passes the name along to ContainerD verbatim. A user can start a container with the kata-containers runtime, for example, simply by calling
Runtime names which ContainerD would interpret as a path to an arbitrary binary are disallowed. While handy for development and testing it is not strictly necessary and would allow anyone with Engine API access to trivially execute any binary on the host as root, so we have decided it would be safest for our users if it was not allowed.
It is not yet possible to set an alternative ContainerD shim as the default runtime; it can only be configured per-container. Doing so properly, with validation and configuration reload handling, is quite the nontrivial undertaking with the current state of the daemon configuration logic. That will be addressed in a subsequent PR.
- What I did
- How I did it
- How to verify it
Unit and integration tests cover the new functionality.
To manually verify:
$PATH
docker run --rm --runtime io.containerd.my-runtime.v1 alpine ls
The
io.containerd.runc.v2
shim is aliased toio.containerd.runc-alias.v2
in the development container image as a convenience for manual testing.- Description for the changelog
docker info
and cannot be set as the default runtime at this time.- A picture of a cute animal (not mandatory but encouraged)