容器引擎是OS和应用程序之间的整个层，还是OS之上与其他应用程序相邻的另一个应用程序？

Question

在大多数教程，出版物甚至一些Docker博客文章中，容器引擎都被说明为位于操作系统顶部的整个层。它也被视为进行虚拟化的虚拟机管理程序或层，有时甚至被称为轻量级虚拟化或OS级虚拟化。

但事实是，这些应用程序直接在OS上运行，并且它们都共享相同的内核。容器引擎不解释或翻译任何代码以在基础OS上运行。

我也读过How is Docker different from a virtual machine，但是主要是关于虚拟机和容器之间的区别，但是我的问题是关于容器引擎的。

将容器引擎说明为操作系统和应用程序之间的整个层是否正确（图1），还是应将其视为操作系统之上与其他应用程序相邻运行的进程（图2）？

Answer 1

  

容器引擎是操作系统和应用程序之间的整个层吗？

否。

  

容器引擎是OS之上与其他应用程序相邻运行的另一个应用程序吗？

这个定义更好。

Scott McCarty在他的演讲之一中具有以下幻灯片：

link to this slide

---

接下来的一些历史可能会有助于docker daemon，containerd，runc，rkt ...

来自：CoreOS documentation：

  

     

在Docker 1.11版之前，Docker Engine守护进程下载容器映像，启动容器进程，公开远程API并充当日志收集守护进程，所有这些操作均在以root身份运行的集中式进程中。

     

尽管这样的集中式体系结构便于部署，但是它没有遵循Unix进程和特权分离的最佳实践；此外，这使得Docker难以与upstart和systemd等Linux初始化系统正确集成。

     

从1.11版本开始，Docker守护进程不再处理容器本身的执行。而是由containerd处理。更准确地说， Docker守护程序将映像准备为Open Container Image（OCI）捆绑包，并对容器进行API调用以启动OCI捆绑包。然后使用runC

启动容器

进一步阅读：

• How containerd compares to runC
• Linux Container Internals 2.0
• What is containerd ?
• Moving from Docker to rkt

Answer 2

这取决于您要如何看待它。

在Docker中，容器基本上是Docker进程的子进程， 并且被设置为受杂项约束。内核功能 像名称空间或cgroups。

因此，尽管容器进程可能认为它们运行在内核之上， 这是由Docker设置并由内核功能创建的幻觉。

人们是否认为错觉可以算作一个单独的“容器引擎”层，这是个人的事情。 （恕我直言，这基本上是“ vim vs Emacs”类型的问题。）

Answer 3

在您的问题上进行回答的容器图像在运行时成为容器，对于Docker容器而言-当图像成为容器在Docker Engine上运行时成为容器。但是，正如在大多数容器体系结构图片中一样，泊坞窗引擎部署在主机操作系统和集中化应用程序之间的整个层上，因为集中化体系结构的目的是在顶部仅构建集中化应用程序。

因此，如果您不想在操作系统之上仅部署统一的应用程序，则不必使用Docker Engine，这意味着不必使用Docker Engine，并且部署在整个Docker架构级别上。如果要在docker enginer上分配整个层，并假设环境中的每个应用程序都将被集中化，那么由您决定是否创建这种架构。

我们可以将Docker Engine定义为运行时（是客户端服务器应用程序），并且可以使用工具启用（由Dockerfile定义）以在Dockerfile之上运行隔离的“容器”部分中的主机操作系统。

希望对您有帮助。