从一项颠覆性的技术成果转化而来，衍生出一整套社区体系，Docker在开发速度上屡创历史记录。然而，在Docker项目在采用和普及方面呈现出惊人趋势的同时，也给我们带来了一系列的疑问和困惑。在今天的文章中，我想把重点放在朋友们最关心的评论话题上。随着Docker项目的热度不断飙升，刚刚接触这个新事物的读者在实践中不禁会有这样的疑问：如果你已经决定使用Docker，是否还需要同时使用OpenStack时间？在给出自己的观点之前，我打算先从背景资料入手，为大家讲解一下，以便更透彻地理解这个命题背后的理论基础。背景信息从最简单的组合形式出发，Docker实际上旨在提供一个容器环境，可以在共享的基础设施上管理软件工作负载，但同时确保不同的负载相互隔离，互不影响。.以KVM为代表的虚拟机系统所做的工作是类似的：创建一个完整的操作系统栈，通过虚拟机hypervisor包含与系统相关的设备。然而，与虚拟机解决方案不同，Docker在很大程度上依赖于Linux操作系统中内置的一项名为LXC（Linux容器）的功能。LXC利用操作系统内置的各种功能来划分不同进程的内存，甚至可以在一定程度上拆分CPU和网络资源。Docker镜像不需要像一个新的操作系统那样经历完整的启动过程，从而可以大大减小软件包的体积，应用程序在共享计算资源上运行时会更加轻量化。优势。此外，Docker还允许工作负载直接访问设备驱动程序，从而实现远超hypervisor解决方案的I/O操作。这样的话，我们就可以直接在裸机上使用Docker了，这就带来了上面提到的核心问题：如果已经使用了Docker，是否还需要同时使用OpenStack等云解决方案？前面的结论绝不是空话。BodenRussell最近对Docker与KVM等hypervisor的性能差异进行了基准测试，并在DockerCon大会上公布了测试结果。基准测试非常详尽，正如预期的那样，显示启动KVM管理程序与启动Docker容器之间的时间消耗存在显着差异。这个测试也表明两者在内部和CPU利用率方面也存在巨大差异，如下图所示。红线是KVM，蓝线是Docker。这种性能上的明显差异代表了两种具有非常不同资源密度和整体利用率的类似目的解决方案。而这样的差异也会直接体现在运行特定工作负载所需的资源总量上，最终体现在实际使用成本上。结论总结以上结论并非简单地指向OpenStack，而是适用于OpenStack和其他类似的云基础设施解决方案。在我看来，之所以最后经常会把问题指向OpenStack，是因为OpenStack项目在私有云环境领域其实已经获得了相当大的知名度，而且是目前我们会考虑作为替代方案的唯一技术成果。码头工人。·问题的核心不是OpenStack，而是hypervisor！许多性能基准测试将Docker和KVM置于天平的两端，但很少涉及OpenStack。事实上，上述专项基准测试同时在KVM镜像和Docker容器环境下运行OpenStack，结果表明这两类技术成果能够带来理想的协同效应。考虑到这一点，当我们选择在基于Docker的Nova堆栈之上运行OpenStack时（如下图OpenStack文档提供的图所示），那些资源利用参数变得无关紧要。·在这种情况下，云基础设施可以在容器或管理程序中提供完整的数据中心管理解决方案，这只是一个更大系统的一个组件。以OpenStack为代表的云基础设施解决方案包括多租户安全与隔离、管理与监控、存储与网络等多项功能设置。任何云/数据中心管理系统都不能脱离这些服务而独立存在，但对Docker或KVM基础环境并没有太多要求。·目前，Docker还不是一个功能齐全的虚拟化环境。在安全方面有很多严重的局限性，缺乏对Windows系统的支持。因此暂时不能作为真正可行的KVM备份方案。.虽然正在进行的后续开发工作会逐步弥合这些差距，但以相对保守的态度，这些问题的解决也可能意味着容器技术会在性能上做出妥协。另一件需要注意的事情是，原始管理程序和容器化的实际应用程序性能之间也存在巨大差异，下面的基准测试图表清楚地说明了这一点。一个可能的合理解释是，应用通常使用缓存技术来减少I/O资源开销，这极大地影响了测试结果对真实环境运行状态的准确反映。·如果我们将Docker容器打包在KVM镜像中，两者的区别就可以忽略不计了。这种架构通常使用hypervisor来控制云计算资源，并使用Heat、Cloudify或Kubernetes等进程层来管理虚拟机资源范围内的容器。总结由此，我得出一个结论，如果要正确看待OpenStack、KVM和Docker的关系，正确的出发点是把它看成一套完整的辅助栈——其中OpenStack作为一个整体数据中心管理解决方案KVM的作用是作为多租户的计算资源管理工具，而Docker容器则负责应用部署包相关的工作。在这样的情况下，我们可以总结出一套通用的解决方案模式，其中Docker起到了以下作用：Docker提供经过认证的软件包，并确保它们能够与稳定不变的现有基础设施模型合作顺利工作。·Docker为微服务POD提供了一个优秀的容器化运行环境。在OpenStack之上使用Docker，将其作为相当于裸机环境的运行平台。话虽如此，我确实目睹了许多精确定义工作负载的实例，在这些实例中，使用云基础设施是一种自由选择，而不是一种要求。比如我考虑搭建一个小型的自动化开发测试环境，用于DevOps，那么我个人更倾向于直接在裸机环境上使用Docker机制。在虚拟机和容器两类环境之间，进程层将成为一套完整的抽象对接工具。使用带有Docker的进程框架的一大优势是我们可以根据实际需要随时在OpenStack和裸机环境之间切换。通过这种方式，我们将能够选择任何解决方案选项——只要它确实符合我们的流程引擎对目标环境的特定需求。OpenStackOrchestration(Heat)在最新的Icehouse版本中已经明确表示支持Docker环境。Cloudify作为一个基于TOSCA的开源流程框架，最初适用于OpenStack、VMware、AWS甚至裸机等云环境，但最近开始将Docker支持纳入自身。GoogleKubernetes主要针对GCE协作目标，但我们也可以对其进行定制以适应其他云或运行时环境。英文：http://opensource.com/business/14/11/do-i-need-openstack-if-i-use-docker
