我一直在重读Docker文档,试图理解Docker和完整VM之间的区别。它是如何设法提供一个完整的文件系统、隔离的网络环境等而不那么沉重的?

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


当前回答

有很多答案可以更详细地解释这些差异,但这里是我非常简短的解释。

一个重要的区别是VM使用单独的内核来运行操作系统。这就是它很重并且需要时间引导的原因,消耗了更多的系统资源。

在Docker中,容器与主机共享内核;因此它重量轻,可以快速启动和停止。

在虚拟化中,资源是在设置开始时分配的,因此当虚拟机在许多时间内处于空闲状态时,资源没有得到充分利用。在Docker中,容器没有分配固定数量的硬件资源,可以根据需求自由使用资源,因此具有高度的可扩展性。

Docker使用UNION文件系统。。Docker使用写时复制技术来减少容器消耗的内存空间。在此处阅读更多信息

其他回答

我喜欢肯·科克伦的回答。

但我想补充一点观点,这里没有详细介绍。在我看来,Docker在整个过程中也有所不同。与虚拟机不同,Docker不仅仅是硬件的最佳资源共享,而且它还为打包应用程序提供了一个“系统”(作为一组微服务是可取的,但不是必须的)。

对我来说,它正好填补了面向开发人员的工具(如rpm、Debian包、Maven、npm+Git)与操作工具(如Puppet、VMware、Xen)之间的差距,你可以这么说。。。

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

您的问题假定了某种一致的生产环境。但如何保持一致?考虑一些数量(>10)的服务器和应用程序,这是管道中的阶段。

为了保持同步,您将开始使用类似木偶、厨师或您自己的供应脚本、未发布的规则和/或大量文档。。。理论上,服务器可以无限期运行,并保持完全一致和最新。实践无法完全管理服务器的配置,因此存在很大的配置漂移和运行服务器的意外更改空间。

因此,有一种已知的模式可以避免这种情况,即所谓的不可变服务器。但不可变的服务器模式并不受欢迎。主要是因为Docker之前使用的VM的限制。处理几个千兆字节的大图像,移动这些大图像,只是为了改变应用程序中的一些字段,这是非常费力的。可以理解。。。

有了Docker生态系统,你永远不需要在“小改动”上移动千兆字节(感谢aufs和Registry),也不必担心在运行时将应用程序打包到Docker容器中会导致性能下降。您不必担心该图像的版本。

最后,即使在您的Linux笔记本电脑上,您也可以经常复制复杂的生产环境(如果在您的情况下不起作用,请不要打电话给我;)

当然,您可以在VM中启动Docker容器(这是一个好主意)。减少VM级别的服务器资源调配。所有这些都可以由Docker管理。

同时Docker使用自己的实现“libcontainer”而不是LXC。但LXC仍然可用。

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

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

假设您有一个1GB的容器映像;如果要使用完整的虚拟机,则需要有1 GB x所需数量的虚拟机。使用Docker和AuFS,您可以在所有容器之间共享1GB的空间,如果您有1000个容器,那么容器操作系统的空间可能只有1GB多一点(假设它们都运行同一个操作系统映像)。

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

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

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

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

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

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

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

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

来自评论。。。

有趣的我想我仍然对“快照操作系统”的概念感到困惑。如果不制作操作系统的图像,那么如何做到这一点?

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

这里的大多数答案都涉及虚拟机。我将给你一个简单的回答,这个问题在过去几年中对我的帮助最大。是这样的:

Docker只是运行进程的一种奇特方式,而不是虚拟机。

现在,让我再解释一下这意味着什么。虚拟机是它们自己的野兽。我觉得解释Docker是什么比解释虚拟机更能帮助你理解这一点。特别是因为这里有很多很好的答案,告诉你某人说“虚拟机”的确切含义。所以

Docker容器只是一个进程(及其子进程),它使用主机系统内核内的cgroups与其他进程进行划分。通过在主机上运行ps aux,您实际上可以看到Docker容器进程。例如,“在容器中”启动apache2只是将apache2作为主机上的一个特殊进程启动。它只是与机器上的其他过程分开了。需要注意的是,容器不存在于容器化流程的生命周期之外。当你的进程失效时,你的容器也会失效。这是因为Docker将容器中的pid 1替换为应用程序(pid 1通常是init系统)。关于pid 1的最后一点非常重要。

就每个容器进程所使用的文件系统而言,Docker使用UnionFS支持的映像,这是您在Docker拉ubuntu时下载的映像。每个“图像”只是一系列层和相关元数据。分层的概念在这里非常重要。每一层都只是其下一层的变化。例如,当你在构建Docker容器时删除Dockerfile中的一个文件时,你实际上只是在最后一层的上面创建一个层,上面写着“该文件已被删除”。顺便说一句,这就是为什么您可以从文件系统中删除一个大文件,但映像仍然占用相同的磁盘空间。文件仍然存在,在当前文件下面的层中。层本身只是文件的tarball。您可以使用docker save--output/tmp/ubuntu.tar-ubuntu和cd/tmp&&tar-xvf-ubuntu.tar来测试这一点。然后您可以四处看看。所有看起来像长散列的目录实际上都是单独的层。每一个都包含文件(layer.tar)和元数据(json)以及有关该特定层的信息。这些层只是描述文件系统的更改,这些更改保存为“在”原始状态之上的层。当读取“当前”数据时,文件系统读取数据时,就像只查看最顶层的更改一样。这就是为什么文件看起来被删除了,尽管它仍然存在于“先前”层中,因为文件系统只查看最顶层。这允许完全不同的容器共享其文件系统层,即使每个容器中最顶层的文件系统可能发生了一些重大变化。当容器共享其基本图像层时,这可以节省大量磁盘空间。但是,当您通过卷将目录和文件从主机系统装载到容器中时,这些卷会“绕过”UnionFS,因此更改不会存储在层中。

Docker中的网络是通过使用以太网桥(主机上称为docker0)和主机上每个容器的虚拟接口实现的。它在docker0中创建一个虚拟子网,用于容器之间的通信。这里有许多联网选项,包括为容器创建自定义子网,以及“共享”主机的网络堆栈以供容器直接访问的功能。

Docker进展很快。它的文档是我见过的最好的文档之一。它通常写得很好,简洁准确。我建议您查看可用的文档以获取更多信息,并将文档置于在线阅读的任何其他内容之上,包括堆栈溢出。如果你有具体的问题,我强烈建议加入Freenode IRC上的#docker并在那里提问(你甚至可以使用Freenode的网络聊天!)。

通过这篇文章,我们将描绘虚拟机和LXC之间的一些区别。让我们先定义它们。

VM:

虚拟机模拟物理计算环境,但对CPU、内存、硬盘、网络和其他硬件资源的请求由虚拟化层管理,虚拟化层将这些请求转换为底层物理硬件。

在此上下文中,VM称为来宾,而其运行的环境称为主机。

LXC:

Linux容器(LXC)是操作系统级的功能,可以在一个控制主机(LXC主机)上运行多个独立的Linux容器。Linux容器是VM的轻量级替代品,因为它们不需要虚拟机管理程序,即Virtualbox、KVM、Xen等。

现在,除非你被艾伦(Zach Galifianakis,来自《宿醉》系列)麻醉,并在拉斯维加斯呆了一年,否则你会非常清楚Linux容器技术的巨大兴趣,如果我具体说一下,在过去几个月里在世界各地引起轰动的一个容器项目是Docker,它引发了一些回响,认为云计算环境应该放弃虚拟机(VM),并将其替换为容器,因为它们的开销更低,性能可能更好。

但最大的问题是,它可行吗?,这明智吗?

a.LXC的作用域是Linux的一个实例。它可能是不同风格的Linux(例如CentOS主机上的Ubuntu容器,但它仍然是Linux。)类似地,如果我们查看VM,基于Windows的容器现在被限定为Windows的一个实例,它们的范围非常广,并且使用管理程序,您不限于操作系统Linux或Windows。

b.与虚拟机相比,LXC开销低,性能更好。基于LXC技术构建的工具,即Docker,为开发人员提供了运行应用程序的平台,同时也为运营人员提供了一个工具,允许他们在生产服务器或数据中心上部署相同的容器。它试图让运行应用程序、启动和测试应用程序的开发人员与部署该应用程序的操作人员之间的体验无缝衔接,因为这是所有摩擦的所在,DevOps的目的是打破这些孤岛。

因此,最好的方法是云基础设施提供商应该提倡适当使用VM和LXC,因为它们都适合处理特定的工作负载和场景。

到目前为止,放弃虚拟机并不现实。因此,VM和LXC都有各自的存在和重要性。

在我看来,这取决于你的应用程序的需求,为什么决定部署到Docker,因为Docker根据其功能将应用程序分解为小部分,这变得有效,因为当一个应用程序/功能出现错误时,它对其他应用程序没有影响,与使用完整的vm相比,它的配置会更慢、更复杂,但在某些方面比码头工人更安全