Docker 与虚拟机有何不同?

新手上路,请多包涵

我不断重读 Docker 文档,试图了解 Docker 和完整 VM 之间的区别。它如何在不那么重的情况下提供完整的文件系统、隔离的网络环境等?

为什么将软件部署到 Docker 映像(如果这是正确的术语)比简单地部署到一致的生产环境更容易?

原文由 zslayton 发布,翻译遵循 CC BY-SA 4.0 许可协议

阅读 660
2 个回答

Docker 最初使用 Linux Containers (LXC),但后来改用 runC (以前称为 libcontainer ),它运行在与其主机相同的操作系统中。这允许它共享大量的主机操作系统资源。此外,它使用分层文件系统 ( AuFS ) 并管理网络。

AuFS 是一个分层文件系统,因此您可以将只读部分和写入部分合并在一起。可以将操作系统的公共部分设为只读(并在所有容器之间共享),然后为每个容器提供自己的挂载以供写入。

因此,假设您有一个 1 GB 的容器映像;如果您想使用完整的 VM,则需要 1 GB x 所需的 VM 数。使用 Docker 和 AuFS,您可以在所有容器之间共享 1 GB 的大部分,如果您有 1000 个容器,您仍然可能只有 1 GB 多一点的空间用于容器操作系统(假设它们都运行相同的操作系统映像) .

一个完整的虚拟化系统获得分配给它自己的一组资源,并进行最少的共享。你得到更多的隔离,但它更重(需要更多的资源)。使用 Docker,您可以获得更少的隔离,但容器是轻量级的(需要更少的资源)。因此,您可以轻松地在主机上运行数千个容器,而且它甚至不会闪烁。试着用 Xen 来做,除非你有一个非常大的主机,否则我认为这是不可能的。

一个完整的虚拟化系统通常需要几分钟才能启动,而 Docker/LXC/runC 容器需要几秒钟,通常甚至不到一秒钟。

每种类型的虚拟化系统各有利弊。如果您想要完全隔离并保证资源,那么完整的 VM 是您的最佳选择。如果您只是想将进程彼此隔离并希望在合理大小的主机上运行大量进程,那么 Docker/LXC/runC 似乎是要走的路。

有关更多信息,请查看 这组博客文章,这些文章很好地解释了 LXC 的工作原理。

为什么将软件部署到 docker 映像(如果这是正确的术语)比简单地部署到一致的生产环境更容易?

部署一致的生产环境说起来容易做起来难。即使您使用 ChefPuppet 之 类的工具,也总会有操作系统更新和其他在主机和环境之间发生变化的事情。

Docker 使您能够将操作系统快照到共享映像中,并使其易于部署在其他 Docker 主机上。在本地,dev、qa、prod 等:都是相同的图像。当然,您可以使用其他工具来做到这一点,但几乎没有那么容易或快速。

这非常适合测试;假设您有数千个测试需要连接到数据库,并且每个测试都需要数据库的原始副本并将更改数据。经典的方法是在每次测试后使用自定义代码或 Flyway 等工具重置数据库 - 这可能非常耗时,并且意味着必须连续运行测试。但是,使用 Docker,您可以创建数据库的映像并在每个测试中运行一个实例,然后并行运行所有测试,因为您知道它们都将针对同一数据库快照运行。由于测试是在 Docker 容器中并行运行的,因此它们可以同时在同一个盒子上运行,并且应该更快地完成。尝试使用完整的 VM 执行此操作。

从评论…

有趣的!我想我仍然对“快照[ting] OS”的概念感到困惑。如果没有制作操作系统的图像,如何做到这一点?

好吧,让我们看看我能不能解释一下。您从一个基础映像开始,然后进行更改,并使用 docker 提交这些更改,然后它会创建一个映像。此图像仅包含与基础的差异。当你想运行你的镜像时,你还需要基础,它使用分层文件系统将你的镜像分层在基础之上:如上所述,Docker 使用 AuFS。 AuFS 将不同的层合并在一起,你得到你想要的;你只需要运行它。您可以继续添加越来越多的图像(层),它将继续只保存差异。由于 Docker 通常构建在来自 注册表 的现成映像之上,因此您很少需要自己“快照”整个操作系统。

原文由 Ken Cochrane 发布,翻译遵循 CC BY-SA 4.0 许可协议

了解虚拟化和容器如何在低级别工作可能会有所帮助。这将清除很多事情。

注意:我在下面的描述中进行了一些简化。有关更多信息,请参阅参考资料。

虚拟化如何在低级别工作?

在这种情况下,VM 管理器接管 CPU 环 0(或较新 CPU 中的“根模式”)并拦截来宾操作系统进行的所有特权调用,以制造来宾操作系统拥有自己的硬件的假象。有趣的事实:在 1998 年之前,人们认为在 x86 架构上实现这一点是不可能的,因为没有办法进行这种拦截。 VMware 的人是第 一个想到重写内存中的可执行字节以实现来宾操作系统的特权调用的人。

最终效果是虚拟化允许您在同一硬件上运行两个完全不同的操作系统。每个客户操作系统都会经历引导、加载内核等所有过程。您可以拥有非常严格的安全性。例如,客户操作系统无法获得对主机操作系统或其他客户的完全访问权限,从而搞砸了。

容器如何在低级别工作?

大约在 2006 年,包括一些 Google 员工在内的人们实现了一个新的内核级功能,称为 _命名空间_(不过这个想法 在 FreeBSD 中就已经存在了)。操作系统的一项功能是允许进程之间共享网络和磁盘等全局资源。如果这些全局资源被包装在命名空间中以便它们只对在同一命名空间中运行的那些进程可见怎么办?比如说,您可以获得一块磁盘并将其放在命名空间 X 中,然后在命名空间 Y 中运行的进程无法看到或访问它。同样,命名空间 X 中的进程无法访问分配给命名空间 Y 的内存中的任何内容。当然,X 中的进程无法看到或与命名空间 Y 中的进程通信。这为全局资源提供了一种虚拟化和隔离。这就是 Docker 的工作方式:每个容器在自己的命名空间中运行,但使用与所有其他容器 完全相同 的内核。发生隔离是因为内核知道分配给进程的命名空间,并且在 API 调用期间,它确保进程只能访问其自己的命名空间中的资源。

容器与虚拟机的局限性现在应该很明显了:您不能像在虚拟机中那样在容器中运行完全不同的操作系统。但是,您 可以 运行不同的 Linux 发行版,因为它们共享相同的内核。隔离级别不如虚拟机强。事实上,在早期的实现中,有一种方法可以让“guest”容器接管主机。您还可以看到,当您加载新容器时,操作系统的全新副本不会像在 VM 中那样启动。所有容器 共享同一个内核。这就是容器重量轻的原因。同样与 VM 不同的是,您不必为容器预先分配大量内存,因为我们没有运行操作系统的新副本。这允许在一个操作系统上运行数千个容器,同时对它们进行沙箱化,如果我们在它们自己的虚拟机中运行操作系统的单独副本,这可能是不可能的。

原文由 Shital Shah 发布,翻译遵循 CC BY-SA 4.0 许可协议

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题