2013 年 3 月 15 日，在加利福尼亚州圣克拉拉召开的 Python 开发者大会上，dotCloud 的创始人兼首席执行官 Solomon Hvkes 在一场仅五分钟的微型演讲中，首次提出了 Docker 这一概念。当时，仅约 40 人（除 dotCloud 内部人员）获得了使用 Docker 的机会。
这在之后的几周内，有关 Docker 的新闻铺天盖地。随后这个项目很快在 Github 上开源，任何人都可以下载它并为其做出贡献。在之后的几个月中，越来越多的业界人士开始听说 Docker 以及它是如何彻底地改变了软件的开发、交付和运行的方式。一年之内，Docker 的名字几乎无人不知无人不晓，但还是有很多人不太明白 Docker 究竟是什么，人们为何如此兴奋。
Docker 是一个工具，它致力于为任何应用程序创建分发版本而简化封装流程，将其部署到各种规模的环境中，并将敏捷软件组织的工作流程和响应流水化。
Docker 带来的希望
虽然表面上被视为一个虚拟化平台，但 Docker 远远不止如此。Docker 涉及的领域横跨了业界多个方面，包括 KVM、 Xen、 OpenStack、 Mesos、 Capistrano、 Fabric、 Ansible、 Chef、 Puppet、 SaltStack 等技术。或许你已经发现了，在 Docker 的竞争产品列表中有一些很值得关注。例如，大多数工程师都不会认为，虚拟化产品和配置管理工具是竞争关系，但 Docker 和这两种技术都有点关系。前面列举的一些技术常常因其提高了工作效率而获得称赞，这就导致了大量的探讨。而现在 Docker 正是这些过去十年间最广泛使用的技术之一。
如果你要拿 Docker 分别与这些领域的卫冕冠军按照功能逐项比较，那么 Docker 看上去可能只是个一般的竞争对手。Docker 在某些领域表现的更好，但它带来的是一个跨越广泛的解决工作流程中众多挑战的功能集合。通过将类似 Capistrano 和 Fabric 这样的易用的应用部署工具和易于管理的虚拟系统结合起来，提供钩子使工作流自动化、编排易于实施，Docker 提供了一套非常强大的功能集。
大量的新技术来来去去，因此对这些新事物保持一定的怀疑总是好的。如果不深入研究，人们很容易误以为 Docker 只是另一种为开发者和运营团队解决一些具体问题的技术。如果把 Docker 单独看作一种虚拟化技术或者部署技术，它看起来并不引人注目。不过 Docker 可比表面上看起来的强大得多。
即使在小型团队中，团队内部的沟通和相处也往往是困难的。然而在我们生活的这个世界里，团队内部对于细节的沟通是迈向成功越来越不可或缺的因素。而一个能够降低沟通复杂性，协助开发更为强健软件的工具，无疑是一个巨大的成功。这正是 Docker 值得我们深入了解的原因。当然 Docker 也不是什么灵丹妙药，它的正确使用还需深思熟虑，不过 Docker 确实能够解决一些组织层面的现实问题，还能够帮助公司更好更快地发布软件。使用精心设计的 Docker 工作流程能够让技术团队更加和谐，为组织创造实实在在的收益。
那么，最让公司感到头疼的问题是什么呢？现如今，很难按照预期的速度发布软件，而随着公司从只有一两个开发人员成长到拥有若干开发团队的时候，发布新版本时的沟通负担将越来越重，难以管理。开发者不得不去了解软件所处环境的复杂性，生产运营团队也需要不断地理解所发布软件的内部细节。这些通常都是不错的工作技能，因为它们有利于更好地从整体上理解发布环境，从而促进软件的鲁棒性设计。但是随着组织成长的加速，这些技能的拓展很困难。
充分了解所用的环境细节往往需要团队之间大量的沟通，而这并不能直接为团队创造值。例如，为了发布版本 1.2.1、开发人员要求运维团队升级特定的库，这个过程就降低了开发效率，也没有为公司创造价值。如果开发人员能够直接升级他们所使的库，然后编写代码，测试新版本，最后发布软件，那么整个交付过程所用的时间将会明显缩短。如果运维人员无需与多个应用开发团队相协调，就能够在宿主系统上升级软件，那么效率将大大提高。Docker 有助于在软件层面建立一层隔离，从而减轻团队的沟通负担。
除了有助于解决沟通问题，在某种程度上 Docker 的软件架构还鼓励开发出更多健壮的应用程序。这种架构哲学的核心是一次性的小型容器。在新版本部署的时候，会将旧版本应用的整个运行环境全部丢弃。在应用所处的环境中，任何东西的存在时间都不会超过应用程序本身。这是一个简单却影响深远的想法。这就意味着，应用程序不会意外地依赖于之前版本的遗留产物；对应用的短暂调试和修改也不会存在于未来的版本中；应用程序具有高度的可移植性，因为应用的所有状态要么直接包含于部署物中，且不可修改，要么存储于数据库、缓存或文件服务器等外部依赖中。
因此，应用程序不仅具有更好的可扩展性，而且更加可靠。存储应用的容器实例数量的增减，对于前端网站的影响很小。事实证明，这种架构对于非 Docker 化的应用程序已然成功，但是 Docker 自身包含了这种架构方式，使得 Docker 化的应用程序始终遵循这些最佳实践，这也是一件好事。
Docker 工作流程的好处
我们很难把 Docker 的好处一一举例。如果用得好，Docker 能在多个方面为组织，团队，开发者和运营工程师带来帮助。从宿主系统的角度看，所有应用程序的本质是一样的，因此这就决定了 Docker 让架构的选择更加简单。这也让工具的编写和应用程序之间的分享变得更加容易。这世上没有什么只有好处却没有挑战的东西，但是 Docker 似乎就是一个例外。以下是一些我们使用 Docker 能够得到的好处：
使用开发人员已经掌握的技能打包软件
许多公司为了管理各种工具来为它们支持的平台生成软件包，不得不提供一些软件发布和构建工程师的岗位。像 rpm、mock、 dpkg 和 pbuilder 等工具使用起来并不容易，每一种工具都需要单独学习。而 Docker 则把你所有需要的东西全部打包起来，定义为一个文件。
使用标准化的镜像格式打包应用软件及其所需的文件系统
过去，不仅需要打包应用程序，还需要包含一些依赖库和守护进程等。然而，我们永远不能百分之百地保证，软件运行的环境是完全一致的。这就使得软件的打包很难掌握，许多公司也不能可靠地完成这项工作。常有类似的事发生，使用 Scientific Linux 的用户试图部署一个来自社区的、仅在 Red Hat Linux 上经过测试的软件包，希望这个软件包足够接近他们的需求。如果使用 Dokcer、只需将应用程序和其所依赖的每个文件一起部署即可。Docker 的分层镜像使得这个过程更加高效，确保应用程序运行在预期的环境中。
测试打包好的构建产物并将其部署到运行任意系统的生产环境
当开发者将更改提交到版本控制系统的时候，可以构建一个新的 Docker 镜像，然后通过测试，部署到生产环境，整个过程中无需任何的重新编译和重新打包。
将应用软件从硬件中抽象出来，无需牺牲资源
传统的企业级虚拟化解决方案，例如 VMware，以消耗资源为代价在物理硬件和运行其上的应用软件之间建立抽象层。虚拟机管理程序和每一个虚拟机中运行的内核都要占用一定的硬件系统资源，而这部分资源将不能够被宿主系统的应用程序使用。而容器仅仅是一个能够与 Linux 内核直接通信的进程，因此它可以使用更多的资源，直到系统资源耗尽或者配额达到上限为止。
Docker 出现之前，Linux 容器技术已经存在了很多年，Docker 使用的技术也不是全新的。但是这个独一无二的集强大架构和工作流程于一身的 Docker 要比各个技术加在一起还要强大的多。Docker 终于让已经存在了十余年的 Linux 容器走进了普通技术人员的生活中。Docker 让容器更加轻易地融入到公司现有的工作流程中。以上讨论到的问题已被很多人认可，以至于 Docker 项目的快速发展超出了所有人的合理预期。
Docker 发布的第一年，许多刚接触的新人惊讶地发现，尽管 Docker 还不能在生产环境中使用，但是来自 Docker 开源社区源源不断的提交，飞速推动着这个项目向前发展。随着时间的推移，这一速度似乎越来越快。现在 Docker 进入了 1.x 发布周期，稳定性好了，可以在生产环境中使用。因此，许多公司使用 Docker 来解决它们在应用程序交付过程中面对的棘手问题。
Docker 不是什么
Docker 可以解决很多问题，这些问题是其他类型的传统工具专门解决的。那么 Docker 在功能上的广度就意味着它在特定的功能上缺乏深度。例如，一些组织认为，使用 Docker 之后可以完全摈弃配置管理工具，但 Docker 真正强大之处在于，它虽然能够取代某些传统的工具，但通常与它们是兼容的，甚至与它们结合使用还能增强自身的功能。下面将列举一些 Docker 还未能完全取代的工具，如果与它们结合起来使用，往往能取得更好的效果。
企业级虚拟化平台（VMware、KVM 等）
容器并不是传统意义上的虚拟机。虚拟机包含完整的操作系统，运行在宿主操作系统之上。虚拟化平台最大的优点是，一台宿主机上可以使用虚拟机运行多个完全不同的操作系统。而容器是和主机共用同一个内核，这就意味着容器使用更少的系统资源，但必须基于同一个底层操作系统（如 Linux）。
云平台（Openstack、CloudStack 等）
与企业级虚拟化平台一样，容器和云平台的工作流程表面上有大量的相似之处。从传统意义上看，二者都可以按需横向扩展。但是，Docker 并不是云平台，它只能在预先安装 Docker 的宿主机中部署，运行和管理容器，并能创建新的宿主系统（实例），对象存储，数据块存储以及其他与云平台相关的资源。
配置管理工具（Puppet、Chef 等）
尽管 Docker 能够显著提高一个组织管理应用程序及其依赖的能力，但不能完全取代传统的配置管理工具。Dockerfile 文件用于定义一个容器构建时内容，但不能持续管理容器运行时的状态和 Docker 的宿主系统。
部署框架（Capistrano、Fabric等）
Docker 通过创建自成一体的容器镜像，简化了应用程序在所有环境上的部署过程。这些用于部署的容器镜像封装了应用程序的全部依赖。然而 Docker 本身无法执行复杂的自动化部署任务。我们通常使用其他工具一起实现较大的工作流程自动化。
工作负载管理工具（Mesos、Fleet等）
Docker 服务器没有集群的概念。我们必须使用其他的业务流程工具（如 Docker 自己开发的 Swarm）智能地协调多个 Docker 主机的任务，跟踪所有主机的状态及其资源使用情况，确保运行着足够的容器。
虚拟化开发环境（Vagrant 等）
对开发者来说，Vagrant 是一个虚拟机管理工具，经常用来模拟与实际生产环境尽量一致的服务器软件栈。此外，Vagrant 可以很容易地让 Mac OS X 和基于 Windows 的工作站运行 Linux 软件。由于 Docker 服务器只能运行在 Linux 上，于是它提供了一个名为 Boot2Docker 的工具允许开发人员在不同的平台上快速运行基于 Linux 的 Docker 容器。Boot2Docker 足以满足很多标准的 Docker 工作流程，但仍然无法支持 Docker Machine 和 Vagrant 的所有功能。
如果没有强有力的参考标准，很难理解 Docker 的作用。下一章我们将概览 Docker，它是什么，它的目标使用场景，以及它的优势。
作者简介：
Karl Matthias 曾在创业公司和世界 500 强企业中担任过开发人员，系统管理员和网络工程师。在德国和英国的初创公司工作了若干年后，他和家人回到了美国俄勒冈州波特兰，在 New Relic 公司担任首席网站可靠性工程师。业余时间，他会和他的两个女儿玩，用他那老式相机摄摄影，或者骑骑自行车。
Sean Kane 目前在 New Relic 公司的共享基础设施团队中担任首席网站可靠性工程师。他在生产运维领域有很长的职业生涯，在不同的行业中工作过，有许多不同的头衔。他在各类聚会和技术论坛做过演讲，涉及过疲劳预警和硬件自动化等话题。他的青年阶段大部分在海外度过，毕业于林林兄弟及巴纳姆和贝利小丑学院，在美国中央情报局做过两次实习等等，他一直在探索生活的真谛。
原文发布时间为：2017-02-11
本文来自云栖社区合作伙伴“Linux中国”
