2016年6月5日更新：

距离回答这个问题已经过去很长时间了，在此期间docker也一直发展。但本答案仅仅作为向新人介绍docker的入门文章的话，在大方向上还是没问题的。

本文仅仅是个docker入门介绍文章，用比较宏大的叙事来描述docker的面貌，如果想了解更细节或者更深入的东西，还是需要去深入学习官方文档等内容。

答案正文：

---

# 难懂的docker学术式定义Docker is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating-system-level virtualization on Linux. Docker uses the resource isolation features of the Linux kernel such as cgroups and kernel namespaces, and a union-capable filesystem such as aufs and others to allow independent “containers” to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines.

Docker是一个开放源代码软件项目，让应用程序布署在软件容器下的工作可以自动化进行，借此在Linux操作系统上，提供一个额外的软件抽象层，以及操作系统层虚拟化的自动管理机制。Docker利用Linux核心中的资源分离机制，例如cgroups，以及Linux核心命名空间(name space)，来建立独立的软件容器(containers)。这可以在单一Linux实体下运作，避免启动一个虚拟机器造成的额外负担。

——摘自维基百科

这个定义真是学院派的不能再学院派了，一般人通过这个充满专业名词的定义，能模糊地了解docker是种虚拟化工具，可以实现简化部署之类功能，但是并不能清楚地理解它到底牛逼在什么地方。

## 如何搞懂一个陌生的概念？

要搞明白docker的概念只看定义远远不够，还需要通过其他方式来认识它，一般来说有三种：

第一种：在长期使用docker的过程中，逐渐体会到其优势(放到具体场景中认识)

第二种：通过和一些已经熟悉的概念对比来认识(比如虚拟机)

上述两种方法都要求掌握相当多的软件虚拟化知识，但是对于一个从未接触过docker，甚至对部署都不是很了解，也没时间去研究docker的新人，应该怎么快速理解docker的核心优势呢？

第三种：借助于隐喻。

如果你不清楚隐喻的概念，这里有一篇文章单独介绍：隐喻 。如果不想了解，可以将隐喻简单理解为类比：借助于另一个更容易认识的概念来映射新概念。

# docker的隐喻

「docker」字面意思是「码头工人」，这个名字应该是官方深思熟虑之后的结果，本身就带有很强的隐喻性质：借用了一个在真实世界中已经成熟的体系——全球物流系统，来映射docker在软件领域中起到的作用。

在全球物流系统中，一个非常重要的发明就是集装箱。

##集装箱重要在哪里？

为了理解这件事情，可以先考察一下集装箱出现之前的物流情况：货物从工厂生产出来之后装箱，然后一箱箱的搬到卡车上，然后再一箱箱卸下来，一箱箱送上火车，运送到码头附近的火车站，再一箱箱卸下来，装上卡车，拉到货轮上，再一箱一箱的装上去…

可以看出在整个流程中，大量的时间，人力 ，物力浪费在了中间的装卸上。在物流系统里，由于路程和运输工具速度的限制，货物真正在路上的时间是一定的，在交通技术得到改善之前，这个时间也很难去缩短，于是「货物装卸时间」就成了物流系统中的瓶颈。

这个瓶颈在集装箱出现之后得到了很大的改善。集装箱重要在它提供了一种通用的封装货物的标准规格(尺寸，外形符合统一标准)，这样就产生了一些巨大的优点：只需要在运输前一次性封装，集装箱就可以放上火车，卡车，拉到码头，直接放在货船上；卸船之后直接再放上火车，卡车，运送到目的地。而且由于集装箱符合统一标准，整个流程非常容易机械化，这引发了以集装箱为中心的整个全球物流的标准化进程，进而节省了大量的资源，物流成本迅速下降，促进了全球资源的流动与重新配置。

##docker(码头工人)正是借用了集装箱的隐喻

docker就像往集装箱里装货物的码头工人那样，它把应用打包成具有某种标准规格的集装箱，用计算机领域的语言来说，这种按照一定规格封装的集装箱叫「镜像」。其实就是将你原来的代码添加点额外的内容，格式之类的，生产出来的一个符合某种标准的东西。

集装箱减少了货物的运输工作量，那docker镜像又有什么相似的优势呢？同样可以先看看docker出现之前的应用部署是情况。

### docker出现之前的部署情况

在docker出现之前，比如说要部署一个django(一个流行的python web服务框架)应用，要做哪些事情？首先得有个python环境，比如这个要部署的应用基于python3，而你机器上是python2，那ok，先装个python3吧，一看装起来还挺麻烦，要先装各种依赖，还要解决一些可能的冲突，没办法硬着头皮上吧。

装完python之后，发现还要装mysql，还用了redis。没办法，继续下载，安装，配置。费了九牛二虎之力终于搞完了，一天就这么过去了。

啥？你告诉我原来的服务器不用了，要换一台服务器？我靠，那重新来一遍吧。

啥？你说咱们的基础应用做的太好，要进行推广，需要指导其他厂商部署？我选择狗带

上面的描述可能有些夸张，但也不是非常罕见。在docker出现之前，各种安装、配置环境正是运维人员经常做的事情之一，而且在重复工作上浪费了巨大的资源。

###docker出现之后

####标准的交付件

前面提到docker最像集装箱的地方，就是它是软件交付领域的一种「标准化」，这种标准化的具体产物，简单来说就是「镜像(image)」。「镜像」这个词说实话太玄乎，当然对应的原文「image」本身也挺玄乎的。原因是它根据一些场景引申了本来的含义。

image本身是「画像，映像」的意思，又有「现实物体的抽象描绘」的意思，而且画像本身可以很容易的复制，后来又有了「原画像复制品」一类的意思。

再后来直接就拿来表示光盘镜像(很容易复制的存储影像的东西，只不过画像是画在纸上，但这种影像以数字形式存在于光盘上)。

当然「镜像」在汉语中就有「复制品」的含义，只不过加入了汉字独有的意境，显得玄乎，朦胧了。

在docker中镜像是指，把你的应用按照docker规定的格式封装成一种具有某种标准规格的东西(就像集装箱把你的货物封装起来类似)。形象的说，就是把你的应用按照一定的格式抽象的画了个画像。

在docker中镜像是无法直接运行的，我猜想这并不是技术上的原因，而是出于工程设计的考虑。因为一般来说，一个软件的某个具体版本只会打包成一个镜像， 如果镜像可以配置，运行的话，在使用过程中很可能会对镜像造成破坏。

那怎么样避免镜像损坏的问题呢？就是再加一层，相当于分身术，只要本尊没问题，分身怎么扑街都不会真正的跪掉。多加的这一层分身，就叫容器(container)，这个名字也挺形象，它就像个盒子一样，你的应用在里面运行，而且多了一层安全机制。你想使用服务或把你的应用跑起来的话，只需要基于镜像新创建一个容器就可以了(一条命令搞定)，而镜像还放在那里不动，没办法，金贵嘛。

#### Docker 究竟简化了什么东西？

docker在部署过程中，将安装，配置等重复的部分自动化完成。只需要在第一次部署时，构建完可用的docker镜像(装好集装箱)，在以后使用中，短短的几行命令就可以直接拉取镜像，根据这个镜像创建出一个容器，把服务跑起来了。所需要的仅仅是安装了docker的服务器，一个Dockerfile文件(装箱清单)，以及比较流畅的网络而已，真可谓『一次构建，到处部署』。需要python3环境？直接在Dockerfile(装箱清单)中加入： from python:3.x 搞定。

需要迁移服务器？ 直接把Dockerfile，备份数据拷贝到新服务器，几条命令又搞定

需要作为服务给别人使用？Dockerfile即是最清晰的部署文档，维护一个官方镜像即可，谁需要就直接拉下来几条命令部署上就行了。

到这里你可能更能明白，docker不像传统的软件交付方式那样，只把代码以及说明文档之类的给你就完了，而是直接给你一个像集装箱那样的标准docker货件，这个标准件不仅包括了应用代码本身，还包括了代码运行需要的OS等整体依赖环境。

于是，谁想用我的服务，直接拉取镜像，实例化一个容器就可以了，不再像之前那样有繁复的安装过程————这些都有人给你做过了。

#### 当然docker的优点不止于此

基于一件核心事物的「标准化」有时候可以做更多的事情，就像集装箱带来的「标准化」不仅限于集装箱本身，同时还包括了运输器械，物流管理方法等在内的整个领域的标准化和效率的提高。

再远的标准化案例比如自行车上的螺丝，轮胎等都有全球通用的标准，这些核心标准一经建立就对行业产生了深远的影响。

docker也类似，一旦这种虚拟化封装标准建立起来之后，就可以基于标准件和相应的管理方式做更多的事情。

随便举一些例子：

1.统一的管理服务

使用docker部署的应用，都会在docker的管理范围之内。这也是docker的另一个优点(第一个是标准化)，它提供了一种隔离的空间，把服务器上零散的部署应用集中起来进行管理。

比如未使用docker的时候，一个服务器上部署了n多服务，有mysql，redis，rabbitmq...。有一天服务器突然断电重启了，那些没有设置自动重启的应用，那些重启出问题的应用，那些你甚至都不知道隐藏在某个角落里的重要应用没启动成功….

使用docker后，一眼就可以看出那些应用正常启动了，那些应用又出问题了，接下来只用有条不紊的处理就ok了。

2.持续交付上的应用

持续交付有一些超出范围，自己去寻找答案吧

3.弹性计算

也就是根据需要，动态地添加新的应用服务，在不需要时收回服务器资源，docker的标准化让这种弹性能力得到了更好的应用。

# 最后，关于docker的一个误解

很多人说docker改变了运维世界，这句话是从群体角度来说的，是统计学意义上的改变，像mysql，python这样被大规模使用的基础应用，docker化之后为整个群体所节省的时间是非常巨大的。

有人可能会问，我只有一台服务器，也不太可能会迁移。我的python服务，mysql服务，只需要部署一次，就可以在以后重复使用了。那这样docker对于我来说还有优势吗？毕竟docker也是有学习成本的。

如果你确信你的应用都是一次性的，而且只提供给自己使用，那么docker在这种场景下的优势不是特别明显：即便是docker，最初的构建也是需要有人做的，这和直接在机器上部署一次的工作量差不多。也就是说，docker并不能把部署的工作「减少为0」，比较好的情况下是「基本减少为1」。

但是，你真的真的确信，你所做的工作只是一次性的吗？