问容器引擎是操作系统和应用程序之间的一整层，还是仅仅是在操作系统之上的其他应用程序旁边运行的另一个应用程序？

EN

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

不是的。

是一个容器引擎，另一个应用程序运行在操作系统之上的其他应用程序旁边吗？

这个定义更好。

Scott McCarty在他的一个演示文稿中有以下幻灯片：

​

​

link to this slide

下面是一些历史，可能会对docker daemon，containerd，runc，rkt等术语有所帮助……

来自：CoreOS documentation

在Docker1.11版本之前，Docker引擎守护进程下载容器镜像，启动容器进程，公开远程API，并充当日志收集守护进程，所有这些都是以根运行的集中进程。

虽然这种集中式架构便于部署，但它没有遵循Unix进程和权限分离的最佳实践；此外，它使Docker难以与Linux init系统(如upstart和systemd )正确集成。

从1.11版本开始，Docker守护进程不再自己处理容器的执行。相反，这现在由containerd处理。更准确地说，API Docker守护进程将映像准备为一个Open Container Image ( OCI )包，并向发出一个API调用以启动OCI包。containerd然后使用runC启动容器

进一步阅读：

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

这取决于你想如何看待它。

在Docker中，容器基本上是Docker进程的子进程，并且被额外设置为受misc约束。内核特性，如命名空间或cgroup。

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

一个人是否认为幻觉算作一个单独的“容器引擎”层是个人问题。(这基本上是"vim vs Emacs“类型的问题。)

回答你的问题，容器镜像在运行时成为容器，在Docker容器的情况下-镜像当它们在Docker引擎上运行时成为容器。但就像大多数容器架构的图片一样，docker引擎被部署在主机操作系统和上下文应用程序之间的整个层上，因为上下文架构的目的是在顶部构建上下文应用程序。

因此，如果你不想只在操作系统上部署上下文应用程序，你就不需要使用Docker Engine，这意味着Docker Engine 不需要在整个docker架构级别上使用和部署。如果你想在docker enginer上分配整个层，并假设你的环境中的每个应用程序都将被配置为一个应用程序，那么在创建这样的体系结构时，这取决于你。

我们可以将Docker Engine定义为运行时(是一个客户端-服务器应用程序)，并利用使Docker文件定义的容器应用程序能够在一个独立的“容器”部分中的主机操作系统上运行。

我希望它能帮上忙。