Historically, Docker Engine or Docker has always required root privileges to run. This is because certain features like namespaces or mount points which forms the basis of Docker filesystems have always required elevated privileges. You may have started running docker daemon or dockerd in context of another user, but that user needs to be made part of Docker Group, which was assigned root privileges during installation time. Rootless mode means running the Docker daemon and even containers as an unprivileged user to protect the root user from future attacks on the host system.Read More »
So you might ask – what does dockerd do? As its turns out, it does quite a lot of thing actually!! Things like networking, logging, docker-swarm, service discovery, DNS implementation, authentication, image management, storage management etc. It also exposes API to listen to requests from docker cli, you know the tool that decides how we interact with docker engine, in our daily lives. Someday these functionalities might be spun off to their own smaller counterparts, but for now these are all the things that dockerd does on a daily basis. Not only this, there are two different versions of docker engine – docker community edition (or docker CE) and docker enterprise edition (or docker EE).Read More »
So far we have discussed about runc, containerd in detail and their relative counterparts. We now need to take a look at the component called shim. The shim is integral to the implementation of daemonless containers and separating the low-level container runtimes such as crun or runc from high-level container runtimes such as containerd. As we discussed earlier that containerd uses runc to create new containers. In fact, it forks a new instance of runc for every container it creates. However, once each container is created, the parent runc process exits. This means we can run hundreds of containers without having to run hundreds of runc instances.Read More »
As we discussed in previous posts, that Docker team re-factored, extracted and donated containerd as container runtime to the CNCF in Mar’2017. As of docker engine 1.11, docker engine switch to containerd as default runtime as well and it has been there since. containerd implements downloading images, managing them, and running containers from images. When it needs to run a container it unpacks the image into an OCI runtime bundle and shells out to runc to run it. Also, containerd is platform agnostic, so you can run it on pretty much any OS.Read More »
As we have mentioned previously, runc was donated to OCI and have been managed separately since then. runc is located at GitHub at https://github.com/opencontainers/runc. It is the de-facto standard low-level container runtime. It is written in Golang based CLI tool for spawning, running and managing containers according to the OCI specification. And its very fast at that. To create a container, runc needs two things – a specification file named config.json and a root filesystem as per OCI specifications, both of these present inside a directory/bundle:Read More »
Docker Engine from Docker, Inc has been at forefront of technology, when it comes to containers. It was so synonymous with containers, that docker and containers used to mean the same thing for a long time. It used to be so till the time Kubernetes and OCI came and confusion has taken over since. However, Docker Engine contains so many UX enhancements, that it feels like magic till today and still a recommended option for anyone starting to get their hands dirty in container technology. What we call Docker Engine or simply docker, is composed of many small components tied together like a car engine. Note that Docker Engine is further a small component in set of tools included in the Docker Desktop, which in itself is a separate world.Read More »
In the Kubernetes release v1.20, the development team has marked dockershim as deprecated. There was initially some shock and confusion, as it was perceived that team is moving away from docker completely, however that is not the case. As its turns out, what the team is doing, is steering the Kubernetes away from the proprietary parts of Docker or Docker Engine or just simply called Docker. The Docker Engine is further comprised of many different sub-components like dockerd, containerd, runc etc., many of which were initially developed by Docker Inc and then given away to community. These were later standardized and maintained by the community.
The Kubernetes community has written a detailed blog post about deprecation with a dedicated FAQ page for it. This blog post is being written to understand the impact and what needs to be done about it. Depending on how do you use Docker, think and understand about it, you may or may not have to do anything about it or get worried about sleepless nights.Read More »