<p>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.</p>
<p>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.</p>
<p>I've also read <a href="https://stackoverflow.com/questions/16047306/how-is-docker-different-from-a-virtual-machine">How is Docker different from a virtual machine</a> but it's mainly about the difference between virtual machines and containers but my question is specifically about container engines.</p>
<p>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)?</p>
<p><a href="https://i.stack.imgur.com/VQ75i.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/VQ75i.jpg" alt="container architecture" /></a></p>

<blockquote>
<p>Is a container engine an entire layer between OS and applications?</p>
</blockquote>
<p>No.</p>
<blockquote>
<p>Is a container engine another application running next to other applications on top of OS?</p>
</blockquote>
<p>This definition is better.</p>
<p><a href="https://stackoverflow.com/users/1553450/fatherlinux">Scott McCarty</a> has the following slide in one of his presentations:</p>
<p><a href="https://i.stack.imgur.com/sp69G.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/sp69G.jpg" alt="enter image description here" /></a></p>
<p><a href="https://docs.google.com/presentation/d/1S-JqLQ4jatHwEBRUQRiA5WOuCwpTUnxl2d1qRUoTz5g/edit#slide=id.g566dfb1a47_0_22" rel="nofollow noreferrer">link to this slide</a></p>
<hr />
<p>A bit of history follows which might help with terms like <code>docker daemon</code>, <code>containerd</code>, <code>runc</code>, <code>rkt</code>...</p>
<p>from: <a href="https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html" rel="nofollow noreferrer">CoreOS documentation</a>:</p>
<blockquote>
<p><a href="https://i.stack.imgur.com/Jhnnh.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/Jhnnh.png" alt="enter image description here" /></a></p>
<p>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 <strong>centralized process running as root</strong>.</p>
<p>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.</p>
<p>Since version 1.11, the Docker daemon no longer handles the execution of containers itself. Instead, this is now handled by <a href="https://containerd.io/" rel="nofollow noreferrer">containerd</a>. More precisely, the <strong>Docker daemon</strong> prepares the image as an <a href="https://www.opencontainers.org/" rel="nofollow noreferrer">Open Container Image</a> (OCI) bundle and makes an API call to containerd to start the OCI bundle. containerd then starts the container using <a href="https://github.com/opencontainers/runc" rel="nofollow noreferrer">runC</a></p>
</blockquote>
<p>Further reading:</p>
<ul>
<li><a href="https://stackoverflow.com/questions/41645665/how-containerd-compares-to-runc">How containerd compares to runC</a></li>
<li><a href="https://docs.google.com/presentation/d/1S-JqLQ4jatHwEBRUQRiA5WOuCwpTUnxl2d1qRUoTz5g/edit#slide=id.g566dfb1a47_0_0" rel="nofollow noreferrer">Linux Container Internals 2.0</a></li>
<li><a href="https://blog.docker.com/2017/08/what-is-containerd-runtime/" rel="nofollow noreferrer">What is containerd ?</a></li>
<li><a href="https://medium.com/@adriaandejonge/moving-from-docker-to-rkt-310dc9aec938" rel="nofollow noreferrer">Moving from Docker to rkt</a></li>
</ul>
