我一直在重读Docker文档,试图理解Docker和完整VM之间的区别。它是如何设法提供一个完整的文件系统、隔离的网络环境等而不那么沉重的?
为什么将软件部署到Docker映像(如果这是正确的术语)比简单地部署到一致的生产环境更容易?
我一直在重读Docker文档,试图理解Docker和完整VM之间的区别。它是如何设法提供一个完整的文件系统、隔离的网络环境等而不那么沉重的?
为什么将软件部署到Docker映像(如果这是正确的术语)比简单地部署到一致的生产环境更容易?
当前回答
1.重量轻
这可能是许多码头工人学习者的第一印象。
首先,docker映像通常比VM映像小,因此易于构建、复制和共享。
第二,Docker容器可以在几毫秒内启动,而VM可以在几秒钟内启动。
2.分层文件系统
这是Docker的另一个关键特性。图像具有图层,不同的图像可以共享图层,从而更节省空间,构建速度更快。
如果所有容器都使用Ubuntu作为它们的基本映像,那么不是每个映像都有自己的文件系统,而是共享相同的下划线Ubuntu文件,并且只在它们自己的应用程序数据上有所不同。
3.共享OS内核
将容器视为进程!
在主机上运行的所有容器实际上都是一堆具有不同文件系统的进程。它们共享相同的OS内核,只封装系统库和依赖项。
这在大多数情况下都很好(没有额外的OS内核维护),但如果容器之间需要严格隔离,则可能会出现问题。
为什么重要?
所有这些似乎都是进步,而不是革命。好吧,数量的积累导致质量的转变。
考虑应用程序部署。如果我们想部署一个新的软件(服务)或升级一个,最好是更改配置文件和进程,而不是创建一个新VM。因为创建一个具有更新服务的VM,测试它(开发人员和QA之间共享),部署到生产需要几个小时,甚至几天。如果出了什么问题,你必须重新开始,浪费更多的时间。因此,使用配置管理工具(木偶、盐堆、厨师等)安装新软件,最好下载新文件。
说到docker,不可能使用新创建的docker容器来替换旧容器。维护更容易!构建一个新映像,与QA共享,测试,部署它只需要几分钟(如果一切都是自动化的),最坏的情况下需要几个小时。这被称为不可变基础设施:不要维护(升级)软件,而是创建一个新的。
它改变了服务的交付方式。我们需要应用程序,但必须维护VM(这是一个难题,与我们的应用程序无关)。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的网络聊天!)。
Docker是这样介绍自己的:
Docker是推动集装箱运输的公司,也是唯一容器平台提供程序,以解决混合云。今天的企业面临着数字化的压力转换,但受现有应用程序和同时合理化日益多样化的投资组合云、数据中心和应用程序架构。Docker启用应用程序和基础架构之间的真正独立性开发人员和IT运营人员释放他们的潜力并创建一个模型以实现更好的协作和创新。
所以Docker是基于容器的,这意味着你有可以在当前机器上运行的图像和容器。它不包括像VM这样的操作系统,而是像Java、Tomcat等一组不同的工作包。
如果你了解容器,你就会了解Docker是什么,以及它与VM的区别。。。
那么,什么是容器?
容器映像是一个轻量级、独立的可执行包一个包含运行它所需的一切的软件:代码,运行时、系统工具、系统库、设置。两者都可用基于Linux和Windows的应用程序、容器化软件将始终运行无论环境如何,都是一样的。容器隔离软件从其环境来看,例如发展和分段环境,帮助减少运行团队之间的冲突同一基础设施上的不同软件。
如下图所示,每个容器都有一个单独的包,并且在一台机器上运行,共享该机器的操作系统。。。它们安全且易于运输。。。
1.重量轻
这可能是许多码头工人学习者的第一印象。
首先,docker映像通常比VM映像小,因此易于构建、复制和共享。
第二,Docker容器可以在几毫秒内启动,而VM可以在几秒钟内启动。
2.分层文件系统
这是Docker的另一个关键特性。图像具有图层,不同的图像可以共享图层,从而更节省空间,构建速度更快。
如果所有容器都使用Ubuntu作为它们的基本映像,那么不是每个映像都有自己的文件系统,而是共享相同的下划线Ubuntu文件,并且只在它们自己的应用程序数据上有所不同。
3.共享OS内核
将容器视为进程!
在主机上运行的所有容器实际上都是一堆具有不同文件系统的进程。它们共享相同的OS内核,只封装系统库和依赖项。
这在大多数情况下都很好(没有额外的OS内核维护),但如果容器之间需要严格隔离,则可能会出现问题。
为什么重要?
所有这些似乎都是进步,而不是革命。好吧,数量的积累导致质量的转变。
考虑应用程序部署。如果我们想部署一个新的软件(服务)或升级一个,最好是更改配置文件和进程,而不是创建一个新VM。因为创建一个具有更新服务的VM,测试它(开发人员和QA之间共享),部署到生产需要几个小时,甚至几天。如果出了什么问题,你必须重新开始,浪费更多的时间。因此,使用配置管理工具(木偶、盐堆、厨师等)安装新软件,最好下载新文件。
说到docker,不可能使用新创建的docker容器来替换旧容器。维护更容易!构建一个新映像,与QA共享,测试,部署它只需要几分钟(如果一切都是自动化的),最坏的情况下需要几个小时。这被称为不可变基础设施:不要维护(升级)软件,而是创建一个新的。
它改变了服务的交付方式。我们需要应用程序,但必须维护VM(这是一个难题,与我们的应用程序无关)。Docker让你专注于应用程序,让一切变得流畅。
关于:-
“为什么将软件部署到docker映像比简单部署到一致的生产环境?"
大多数软件都部署到许多环境中,通常至少部署以下三种环境:
个人开发者PC共享开发人员环境单个测试仪PC共享测试环境QA环境UAT环境负载/性能测试实时登台生产档案文件
还需要考虑以下因素:
根据工作的性质,开发人员,甚至测试人员,都将拥有微妙的或完全不同的PC配置开发人员通常可以在公司或企业标准化规则无法控制的PC上进行开发(例如,在自己的机器上开发的自由职业者(通常是远程开发的),或未“受雇”或“签约”以某种方式配置其PC的开源项目的贡献者)某些环境将由负载平衡配置中的固定数量的多台计算机组成许多生产环境将根据流量级别动态(或“弹性”)创建和销毁基于云的服务器
正如你所看到的,一个组织的服务器总数很少是一位数,通常是三位数,而且很容易更高。
这一切都意味着,仅仅因为巨大的容量(即使是在绿地场景中),首先创建一致的环境就已经足够困难了,但鉴于服务器数量众多、新服务器的添加(动态或手动)、o/s供应商、防病毒供应商、浏览器供应商等的自动更新,由开发人员或服务器技术人员执行的手动软件安装或配置更改等。让我重复一遍-保持环境一致几乎是不可能的(没有双关语)(好吧,对于纯粹主义者来说,这是可以做到的,但这需要大量的时间、精力和纪律,这正是为什么VM和容器(例如Docker)最初被设计出来的原因)。
因此,请更像这样思考您的问题:“鉴于保持所有环境一致性的极端困难,即使考虑到学习曲线,将软件部署到docker映像中是否更容易?”。我想你会发现答案总是“是”——但只有一种方法可以找到,在Stack Overflow上发布这个新问题。
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通常基于注册表中的现成图像构建,因此您很少需要自己“快照”整个操作系统。