Is container engine an entire layer between OS and applications or just another application running next to other applications on top of OS?
In most of the tutorials, publications and even some Docker blog posts, container engine is illustrated as an entire layer that sits on top of the OS. It is also considered as a hypervisor or a layer that does virtualization and it's even sometimes called lightweight virtualization or OS-level virtualization.
But the truth is, the apps are running on the OS directly and they all share the same kernel. The container engine does not interpret or translate any code to run on the underlying OS.
I've also read How is Docker different from a virtual machine but it's mainly about the difference between virtual machines and containers but my question is specifically about container engines.
Is it correct to illustrate container engine as an entire layer between the OS and the applications (figure 1) or it should be considered just as a process running next to other applications on top of the OS (figure 2)?
Similar Questions
3 Answers
Answering on your question container images become containers at runtime and in the case of Docker containers - images become containers when they run on Docker Engine. But as in most pictures of containers architecture docker engine is deployed on entire layer between host operating system and contenerized application because aim of contenerized architecture is to build just contenerized application on top.
So if you don't want to deploy only contenerized application on top of operating system you don't have to use Docker Engine and that implies that Docker Engine don't have to be used and deployed on entire level of docker architecture. It is up to you while creating such architecture if you want to allocate whole layer on docker enginer and assume that whole every single application in your environment will be contenerized one.
We can define Docker Engine as the runtime (is a client-server application)and tooling that enables container applications, defined by a Dockerfile, to run on top of a host operating system in an isolated "container" section.
I hope it helps.
It depends on how you want to look at it.
In Docker, containers are basically child processes of Docker processes, and are additionally set up to be constrained by misc. kernel features like namespaces or cgroups.
So while the container processes might think they run on top of the kernel, it's an illusion set up by Docker and created by the kernel features.
And whether one thinks the illusion counts as a separate "Container Engine" layer is a personal matter. (IMHO it's basically "vim vs Emacs" type of issue.)
Is a container engine an entire layer between OS and applications?
No.
Is a container engine another application running next to other applications on top of OS?
This definition is better.
Scott McCarty has the following slide in one of his presentations:
A bit of history follows which might help with terms like docker daemon, containerd, runc, rkt...
from: CoreOS documentation:
Prior to Docker version 1.11, the Docker Engine daemon downloaded container images, launched container processes, exposed a remote API, and acted as a log collection daemon, all in a centralized process running as root.
While such a centralized architecture is convenient for deployment, it does not follow best practices for Unix process and privilege separation; further, it makes Docker difficult to properly integrate with Linux init systems such as upstart and systemd.
Since version 1.11, the Docker daemon no longer handles the execution of containers itself. Instead, this is now handled by containerd. More precisely, the Docker daemon prepares the image as an Open Container Image (OCI) bundle and makes an API call to containerd to start the OCI bundle. containerd then starts the container using runC
Further reading: