关于作者

　　Chris Swan 是云网络软件供应商CohesiveFT的首席技术官。作为银行业的技术专家和技术领域的银行专家，他曾经有十几年的时间在从事金融服务业。他大部分时间是在大型瑞士银行中与应用服务器、计算网格、安全、移动和云(如阿里云)这些基础设施打交道。克里斯还喜欢参与互联网上的修补工作，包括一些Raspberry Pi项目。

　　Docker技术的简要综述

　　Docker容器是基于联合文件系统(union file system)的，比如AUFS，利用它可以跨多个容器来共享一些组件，如操作系统镜像和安装的库文件。这种分层的方式也被Dockerfile DevOps工具充分利用，这可以缓存那些已经成功完成的操作。这就省掉了那些安装操作系统和应用程序依赖文件的时间，大幅度加速了测试周期。另外，在容器之间共享库还能减少内存的占用。

　　Docker容器是从镜像开始的，镜像可以是本地创建的、本地缓存的，或者是从注册库中下载的。Docker公司运营着DockerHub公有注册库，上面有官方的数据仓库，是为不同的操作系统、中间件和数据库而创建的。组织和个人可以在Docker Hub上发布镜像的公有库，也可以将其注册成私有库。由于上传的镜像文件可以包含任何东西，所以Docker Hub提供了一种自动构建工具(之前被称为“可信的构建”)，镜像构建于一个Dockerfile，它作为镜像内容的清单。

　　Docker – 迄今为止的故事

　　Docker是一种Linux容器工具集，它是为“构建(build)、交付(ship)和运行(运行)”分布式应用而设计的。作为DotCloud公司的开源项目，其首发版本的时间是2013年的3月份。该项目很快就受到欢迎，这也使得DotCloud公司将其品牌改为Docker(并最终将其原有的PaaS业务出售而专注在Docker上)。Docker 1.0在2014年6月发布，而且延续了之前每月发布一个版本的节奏。

　　其1.0版本标志着Docker公司认为Docker平台已经足够成熟，并可被应用到产品中(公司以及其合作伙伴们还提供了一些需要付费的支持选项)。每月的版本更新显示出该项目仍在快速发展，比如增加新的特性，解决发现的问题。这个项目成功地将“交付”和“运行”解耦，这样源自任意Docker版本的镜像都可和其它任意不同版本一起工作(前向和后向均可兼容)，这就为Docker应用提供了稳定的基础，以应对快速的变化。

　　Docker发展成最受欢迎的开源项目可能会被人看作是一种炒作，但其实这个结果还是有坚实的基础来支撑的。Docker吸引了业界众多知名大牌厂家的支持，其中包括亚马逊(Amazon)、Canonical、CenturyLink、谷歌(Google)、IBM、 Microsoft、New Relic、Pivotal、Red Hat和VMware，这使得只要在有Linux的地方，Docker就几乎随处可用。除了这些大厂家，许多初创企业也围绕着Docker来发展，或是将它们的发展方向和Docker更好地结合起来。所有这些合作伙伴(或大或小)驱动着核心项目和周边生态系统的快速发展。

　　Docker利用了一些Linux核心工具，比如cGruops、命名空间和SELinux来支撑容器之间的隔离。起初Docker只是LXC容器管理子系统的前端，但它在0.9版本中引入了libcontainer，这个原生的Go语言库提供了用户空间和内核之间的接口。

　　“容器化”的应用

　　几乎所有的Linux应用都可以运行在Docker容器里，并且对编程语言或架构的选择没有任何的限制。实际上仅有的限制在于从操作系统的角度来看容器被允许做什么。即使如此，也可以通过在特权模式下运行容器来降低限制，以大幅度地减少受到的控制(与此对应的是装载到容器里的应用风险增加，并可能会导致对主机操作系统的损坏。)

　　容器从镜像开始，反过来镜像也可以从运行的容器中得到。从本质上说有两种方法可以把应用置入到容器中-手动和Dockerfile。

　　手动构建

　　手动构建从启动一个基础操作系统的容器开始，然后通过交互式终端，用所选Linux相关的包管理器安装应用程序及其依赖项(dependencies)。Zef Hemel在他的文章“使用Linux容器以支持便捷的应用部署”中提供了这个过程的细致描述。一旦应用完成安装，新的容器就可以推送到注册库(比如Docker Hub)中或者被导出成一个tar文件。

　　Dockerfile

　　Dockerfile是对Docker容器创建过程进行脚本化的系统。每个Dockerfile详细说明了开始的基础镜像，以及随后一系列在容器中运行的命令和添加到容器中的文件。Dockerfile也可以说明容器对外的端口，启动时的工作目录和缺省执行的命令。用Dockerfile构建的容器可以象手动构建那样被推送到注册库中或者导出成tar文件。Dockerfile也可以应用到Docker Hub的自动构建系统中，即在Docker公司的控制下，在系统中根据Dockerfile从头构建镜像，并且这个镜像的源对于使用它的任何人都是可见的。

　　一个进程?

　　手动构建还是使用Dockerfile来构建镜像，考虑的关键在于容器刚启动时只能执行一个单进程。若容器的服务目的比较单一，比如只运行一个应用服务器，那么运行单个进程就没什么问题(一些争论说容器本应该只包括一个进程)。对于那些希望在容器中运行多个进程的情况，管理进程(supervisor process)需要先启动，这样它可以接着孵化出其他期望的进程。此时容器中没有初始的系统，所以任何事都要依赖systemd，不修改新兴系统或类似系统都无法工作。

　　容器和虚拟机的对比

　　Docker容器要比虚拟机有效率的多，这是因为它们可以共享内核和相关的库。同样的原因，容器所占用的内存也要比虚拟机少得多，虽然虚拟机利用了RAM的过度承诺技术(RAM overcommitment)。容器也减少了对存储的占用，因为部署的容器会共享镜像的底层。IBM的Boden Russel已经做了一个基准测试(benchmarking)来对比两者的不同。

　　容器也表现出比虚拟机更低的系统负载，所以同样的应用，在容器中相比在虚拟机中，性能通常会相当或者更好。IBM的研究者团队发布了一个虚拟机和Linux容器性能对比的报告可以参考。

　　容器只是在隔离特性上要比虚拟机差，虚拟机可以使用ring-1特权的硬件隔离技术，如Intel的VT-d and VT-x。这种隔离技术可以防止虚拟机破出(breaking out)和彼此交互。容器没有任何形式的硬件隔离，这使得它容易受到漏洞的利用。从Shocker(可对Docker进行概念攻击)的验证来看，Docker 1.0之前的版本都是很脆弱的。尽管利用Shocker，Docker在1.0版本中修复了一些特定的问题，但Docker的CTO Solomon Hykes仍然表示：“当我们感觉可以轻松地宣称Docker打开箱(out-of-the-box)可以安全容纳非受信的uid0程序(译者注： root和超级用户权限)时，我们一定会明言相告”。Hykes的话从另一方面承认仍然存在一些其他的漏洞和相关的风险，在容器变得可靠之前还有很多工作要做。

　　对于许多用户案例，在容器和虚拟机二者之间选择其一是种错误的二分法。Docker可以在虚拟机中运行地很好，这可以让它应用在已有的虚拟化框架中，如私有云和公有云(如阿里云)。同样也有可能在容器中运行虚拟机，这有点像谷歌在它的云平台中使用容器的方式。只要IaaS得到广泛应用，并可按需提供虚拟机服务，那么就有理由期待未来数年容器和虚拟机的应用可以并存。还有一种可能，即将容器管理和虚拟化技术进行融合以提供一种两全其美的方法：所以硬件信任锚微虚拟化实现支撑libcontainer能够与Docker的工具链和生态系统的前端进行集成，而使用不同的提供了更好隔离性的后端。微虚拟技术(类似于Bromium的 vSentry和VMware的 Project Fargo)已经应用到桌面环境中为应用提供基于硬件的隔离，所以相同的方法可以使用到libcontainer上，作为Linux核心容器机制的替代技术。

　　容器和微服务

　　全面描述使用微服务架构的哲理和益处已经超出了本文的范围(InfoQ eMag: Microservices中有全面的阐述)。容器仍然是一种方便的方法来绑定和部署微服务的实例。虽然目前微服务大规模的部署实例还是在(大量)虚拟机上，但容器提供了一种小规模部署的机会。容器具有共享的内存和针对操作系统的磁盘占用、通用代码库，这也意味着可以非常有效地一起部署多个版本的服务。

　　合成

　　Docker有个原生的机制来连接容器，它所依赖的元数据可以被传送到相关的容器中，这些元数据被用做环境变量和主机入口。类似Fig和geard这样的应用合成工具，可以在单文件中表达这种依赖关系图，这样多个容器就可以互相配合成为一个系统。CenturyLink的Pannamax合成工具在底层采用了和Fig、geard相似的方法，但加入了基于Web的用户接口，并且直接和GitHub进行了集成，这样就可以分享合成后的应用了。

　　连接的容器

　　一些小的应用适合放在单个容器中，但许多情况下应用需要扩展到多个容器。Docker成功催生了一系列新的应用合成工具、编制工具及平台即服务实现。绝大多数努力的后面，是希望能简化从一组相互连接的容器来创建应用的过程。很多工具在扩展、容错、性能管理和部署资产的版本控制方面也提供了帮助。

　　编制

　　编制系统包括Decking、New Relic公司的Centurion和谷歌公司的Kubernetes，它们的目标都是帮助实现容器的部署和它的生命周期管理。也有很多基于Apache Mesos系统(特别是它为应用长期运行设计的Marathon框架)的商业化实现(比如Mesosphere)，它们可以和Docker一起使用。通过提供在应用需求和底层架构间的抽象(例如，需求表达为CPU核数和内存大小)，编制工具提供了两者之间的解耦，这种设计简化了应用开发和数据中心的运维。还有各种各样的编制系统，这主要是因为之前许多内部系统工具冒出来了，它们之前开发出来是用于管理容器大规模部署的。例如Kubernetes就是基于谷歌的Omega系统，而Omega系统是用来管理整个谷歌云环境中的容器。

　　合成工具和编制工具功能上会有部分的重合，所以使用时它们彼此可以作为补充。例如Fig可以用来描述容器功能上如何交互，同时Kubernetes pods(译者注：pods可以被看成一个容器组)可以用来提供相关的监测和扩展功能。

　　连接性

　　Docker的网络能力相当原始，容器中的服务对相同主机的其它容器是可见的，并且Docker可以映射端口到主机操作系统，使得服务在网络中也是可见的。Libchan是Docker官方赞助的连接方法，它提供了Go语言的网络服务库，类似于channels。在libchan找到自己应用的道路之前，还是有空间留给第三方程序来提供一些补充性的网络服务。例如，Flocker采用了基于代理的方法，这使得服务(连同底层的存储)可以在主机间进行迁移。

　　平台即服务

　　有很多原生于Docker的PaaS实现，例如Deis和Flynn，已经体现出Linux容器在支持开发灵活性上的强大优势(而不是那些自以为是给定的一套语言和框架)。其它的云平台如CloudFoundry、OpenShift和Apcera Continuum，已经采用集成基于Docker相关功能到现有系统中的技术路线，这样基于Docker镜像(或者是创建它们的Dockerfiles)的应用在部署和管理的同时，仍然可以使用之前系统支持的语言和框架。

　　所有的云

　　由于Docker可以运行在任何有合理数据内核的Linux虚拟机上，所以它可以运行在很多IaaS提供的云上。许多大的云提供商宣布了对Docker和它的生态系统的附加支持。

　　亚马逊已经引入Docker到它的弹性豆茎(Elastic Beanstalk)系统中(这是在IaaS之上的编制服务)。谷歌使Docker成为可管理的虚拟机(managed VMs)，它提供了在应用程序引擎的PaaS和计算引擎的的IaaS之间的中间站。微软和IBM也都宣布了基于Kubernetes的服务，这样在他们的云上就可以部署和管理多容器应用了。

　　为了给当前使用的广泛多样的后端提供一致性的接口，Docker团队引入了libswarm，它会被集成到多数的云(如阿里云)和资源管理系统中。Libswarm一个明确的目标是“通过切换服务来源的办法来防止供应商锁定”。这通过呈现一组一致性的服务(以及相关的API)来完成，这些服务会附着到特定后端的实现上。比如Docker服务器服务会呈现Docker远程API到本地Docker命令行工具中，这样众多的服务提供者就可以管理相关的容器了。

　　基于Docker的新的服务类型仍在起步阶段。虽然位于伦敦的果园实验室(Orchard labs)可以提供Docker容器的托管服务,但Docker公司表示,在它收购果园实验室后相关服务不会被置于优先位置。Docker公司还向cloudControl公司出售了其先前的DotCloud PaaS 业务。如OpenVZ之类基于旧的容器管理系统的服务已经比较普通了,所以在一定程度上Docker需要向主机提供商们证明其价值。

　　Docker的未来

　　Docker公司已经建立了清晰的道路，即发展核心能力(libcontainer)、跨业务管理(libswarm)和容器间消息(libchan)。与此同时，通过收购果园实验室(Orchard labs)，Docker公司表达了利用自身生态系统的意愿。但是，这不仅仅关注Docker公司，这个项目的贡献者还来自于一些大牌公司，如谷歌、IBM和Red Hat。在仁慈的独裁者、首席技术官Solomon Hykes的掌舵下，Docker公司和Docker项目的技术领先有着明确的联系。在项目初始的18个月里，它已经显示出通过自己的输出来快速前进的能力，并且没有减弱的迹象。

　　许多投资者正着眼于十年前VMware公司ESX/ vSphere平台的功能矩阵，试图找出已经由虚拟机普及而驱动的企业预期和现有Docker生态系统之间的差距(和机会)。在网络存储和细粒度的版本管理(用于容器中的内容)领域，现有Docker生态系统做得并不好，这就为初创企业和在职人员提供了机会。

　　随着时间的推移，虚拟机和容器(Docker中的“运行”部分)之间的区别很可能变得不再那么重要，这将使注意力转到“构建(build)”和“交付(ship)”方面。这些变化将使 “Docker会发生什么?”的问题，相比“Docker会带给IT业什么?”的问题，变得更不重要。

　　Docker和它的发行版

　　Docker已经成为主流Linux版本的标准特性，比如Ubuntu, Red Hat Enterprise Linux (RHEL) 和CentOS。遗憾的是这些Linux发行版与Docker项目在步调上并不一致，从而导致这些Linux发行版中Docker的版本比当前能用的老得多。例如Ubuntu 14.04的Docker版本是0.9.1，并且在Ubuntu升级到14.04.1时Docker的版本也没有变(当时Docker项目版本是1.1.2)。在官方库中还有一个命名空间冲突的问题，因为Docker也是KDE系统托盘的名字，所以在Ubuntu 14.04中Docker包和命令行工具起了另一个名称“docker.io”。

　　在企业级Linux发行版中情况也没有太大的不同，CentOS 7中Docker的版本是0.11.1，这是Docker公司宣布1.0版本产品准备就绪之前的一个开发版。Linux发行版用户如果要使用最新的版本以保证稳定性、性能和安全，那么按照Docker安装指导操作并使用Docker公司提供的库，要比使用Linux发行版中的版本要好得多。

　　Docker的到来也催生了新的Linux发行版，比如CoreOS和Red Hat的Project Atomic，它们设计成能运行容器的最小环境系统。这些发行版相比传统Linux发行版本，有比较新的内核和Docker版本，对内存和硬盘的占用也比较小。新的发行版本中也有一些新的工具用来管理大容量的容器部署，比如fleet负责分布式系统启动，而etcd负责元数据管理。这些Linux发行版针对自身的分布式更新采用了新的机制，这样就可使用最新版本的内核和Docker了。这表示对Docker应用的其中一种效果的认可，那就是把注意力重心从发行版和包管理解决方案转到Linux内核(和使用内核的Docker子系统)上来。

　　尽管新发行版(译者注：类似于CoreOS)也许是Docker最佳的运行方式，但是支持容器的传统发行版和它们的包管理工具仍然十分重要。Docker Hub上提供了 Debian、Ubuntu和CentOS的正式镜像，还有“半官方”Fedora的镜像库。RHEL没有在Docker Hub上的镜像，因为它们是直接由Red Hat发行的。这意味着Docker Hub上的自动构建机制只对那些纯开源的Linux发行版本可用(并愿意信任那些起源于Docker公司团队策划的基础镜像)。

　　Docker Hub同时集成了源控制系统，如GitHub和Bitbucker，用来自动构建包管理器。包管理器可在镜像构建过程中生成构建规格(在Dockerfile中)和最终构建镜像之间的复杂关系。构建过程的结果具有不确定性，这不是Docker的特定问题，而和包管理器如何工作相关。今天构建的是这个版本，在另一个时间构建可能会得到一个新的版本，这也就是包管理器需要更新功能的原因。容器抽象(即较少关注容器中的内容)与容器扩展(因为轻量级资源利用率​​)可能会使这种不确定性成为Docker相关的痛点。

　　原文出自：http://blog.csdn.net/miller_lover/article/details/41073547