A complete containerisation tech stack with the main goal of providing intuitive user experience through abstracting the lower-level runtime components. In its early days, Docker relied on lxc before shifting to its own runtime libcontainer (now in runc).
Currently, the DE comes in two forms:
- Docker Desktop — for the everyday developer (includes a GUI)
- Docker Engine — stripped down server version containing only the essentials
Regardless of the form, each version comes with several key components:
docker— a cli that allows a user to interact with thedockerddaemondockerd— the Docker daemon which validates and propagates user requests downward to containerd- containerd — a high-level container runtime that manages image building, networking, storage, and container creation through runc
- runc — low-level runtime that builds and runs the containers
Prior to v1.24 of k8s, you could still1 use the whole DE as a runtime through the built-in dockershim. However, from that point onwards the only way of using Docker was through cri-dockerd — a 3rd-party2 adapter shim that works as a drop-in replacement for the deprecated dockershim.
Sources
- https://www.docker.com/blog/containerd-vs-docker/
- https://www.tutorialworks.com/difference-docker-containerd-runc-crio-oci/
Footnotes
-
Originally, the DE was the default runtime solution in Kubernetes. But, with the emergence of other runtimes they introduced the CRI which works as a unified interface that allows k8s to interact with any OCI-compliant runtime. ↩
-
Docker and Mirantis agreed to continue supporting the dockershim code in the form of cri-dockerd. ↩