容器到底是个啥？（附Docker学习资源汇总）

Docker与容器

1

初识容器与Docker

容器技术起源于Linux开源平台，并且经历了比较长时间的发展阶段，其中最重要的成果是Linux容器（Linux Containers，LXC）技术。

IBM DeveloperWorks网站关于容器技术的描述是这样的：“容器有效地将由单个操作系统管理的资源划分到孤立的组中，以更好地在孤立的组之间平衡有冲突的资源使用需求。与虚拟化相比，这样既不需要指令级模拟，也不需要即时编译。容器可以在核心CPU本地运行指令，而不需要任何专门的解释机制。此外，也避免了准虚拟化（paravirtualization）和系统调用替换中的复杂性。”

听不明白，是吧？

直白的翻译过来就是这样的：如果认为虚拟机是模拟运行的一整套操作系统（包括内核、应用运行态环境和其他系统环境）和跑在上面的应用，那么容器就是独立运行的一个（或一组）应用，以及它们必需的运行环境。

容器中运行的就是一个或者多个应用程序，以及应用运行所需要的环境。容器直接运行在操作系统内核之上的用户空间。容器技术可以让多个独立的用户空间运行在同一台宿主机上。容器既可以运行在物理机也可以运行在虚拟机上，当然也可以运行在公有云主机上。

在LXC之前，这些相关技术经过多年的演化已经十分成熟和稳定，但是由于种种原因，它们并没有被很好地集成到主流的Linux内核中，用户使用起来并不方便。例如，如果用户要使用OpenVZ技术，需要先手动给操作系统打上特定的内核补丁方可使用，而且不同版本并不一致。类似的困难造成在很长一段时间内，这些优秀的技术只流传于技术人员的小圈子中。

后来LXC项目借鉴了前人成熟的容器设计理念，并基于一系列新引入的内核特性，实现了更具扩展性的虚拟化容器方案。更加关键的是，LXC终于被集成到了主流Linux内核中，进而成为了Linux系统轻量级容器技术的事实标准。从技术层面来看，LXC已经趟过了绝大部分的“坑”，完成了容器技术实用化的大半历程。

那么Docker又是什么呢？

Docker是轻量级容器管理引擎，它的出现为软件开发和云计算平台之间建立了桥梁。我们如果把容器对标为虚拟机的话，Docker可以对标为hypervisor管理层，它是一个容器管理引擎技术，而不是容器本身。这一点是经常被混淆的。它的作用是提供了一套优雅、简洁的工具，利用linux开源生态已有技术，实现容器横向和纵向生命周期的完整、简单、高效、快捷的管理。

在前述LXC的基础上，Docker进一步优化了容器的使用体验，让它进入了寻常百姓家。

首先，Docker提供了各种容器管理工具（如分发、版本、移植等）让用户无需关注底层的操作，可以更简单明了地管理和使用容器；其次，Docker通过引入分层文件系统构建和高效的镜像机制，降低了迁移难度，极大地提升了用户体验。用户操作Docker容器就像操作应用自身一样简单。

Docker是基于Go语言实现的开源容器项目，诞生于2013年年初，最初发起者是dotCloud公司。Docker自开源后受到广泛的关注和讨论，目前已有多个相关项目（包括Docker三剑客、Kubernetes 等），逐渐形成了围绕Docker容器的生态体系。 由于Docker在业界造成的影响力实在太大，dotCloud公司后来也直接改名为Docker Inc，并专注于Docker相关技术和产品的开发。

Docker的构想是要实现“Build，Ship and Run Any App， Anywhere”，即通过对应用的封装（Packaging）、分发 （Distribution）、部署（Deployment）、运行（Runtime）生命周期进行管理，达到应用组件“一次封装，到处运行”的目的。这里的应用组件，既可以是一个Web应用、一个编译环境，也可以是一套数据库平台服务，甚至是一个操作系统或集群。

基于Linux平台上的多项开源技术，Docker提供了高效、敏捷和轻量级的容器方案，并支持部署到本地环境和多种主流云平台。可以说，Docker首次为应用的开发、运行和部署提供了“一站式”的实用解决方案。

2

为什么要使用Docker

（1）提供一种简单、轻量的应用建模方式

在云时代，开发者创建的应用必须要能很方便地在网络上传播，也就是说应用必须脱离底层物理硬件的限制；同时必须是“任何时间、任何地点”可获取的。因此，开发者需要一种新型的创建分布式应用程序的方式，快速分发和部署，这正是Docker所能够提供的最大优势。

Docker通过容器来打包应用，解耦应用和运行平台。意味着迁移的时候，只需要在新的服务器上启动需要的容器就可以了，无论新旧服务器是否是同一类型的平台。这无疑将节约大量的宝贵时间，并降低部署过程出现问题的风险。

（2）职责的逻辑分离

使用 Docker,开发人员只需要关心容器中运行的应用程序，而运维人员只需要关心如何管理容器。Docker设计的目的就是要加强开发人员写代码的开发环境与应用程序要部署的生产环境的一致性，从而降低那种“开发时一切都正常，肯定是运维的问题”的风险。

（3）快速、高效的开发生命周期

Docker的目标之一就是缩短代码从开发、测试到部署、上线运行的周期，让你的应用程序具备可移植性，易于构建，并易于协作。

（4）鼓励使用面向服务的架构

Docker还鼓励面向服务的架构和微服务架构。Docker推荐单个容器只运行一个应用程序或进程，这样就形成了一个分布式的应用程序模型，在这种模型下，应用程序或服务都可以表示为一系列内部互联的容器，从而使分布式部署应用程序，扩展或调试应用程序都变得非常简单，同时也提高了程序的内省性。

Docker核心概念集合

1

Docker客户端和服务器

Docker 架构如下图所示：

Docker 采用的是 Client/Server 架构。客户端向服务器发送请求，服务器负责构建、运行和分发容器。客户端和服务器可以运行在同一个 Host 上，客户端也可以通过 socket 或 REST API 与远程的服务器通信。

最常用的 Docker 客户端是 docker 命令。通过 docker 我们可以方便地在 Host 上构建和运行容器。docker 支持很多操作（子命令）。除了 docker 命令行工具，用户也可以通过 REST API 与服务器通信。

关于Docker API我们后续会详细介绍。

Docker 服务器：Docker daemon 是服务器组件，以 Linux 后台服务的方式运行。

Docker daemon 运行在 Docker host 上，负责创建、运行、监控容器，构建、存储镜像。

默认配置下，Docker daemon 只能响应来自本地 Host 的客户端请求。如果要允许远程客户端请求，需要在配置文件中打开 TCP 监听。

2

Docker镜像

Docker的大部分操作都围绕着它的三大核心概念——镜像、容器和仓库而展开。因此，准确把握这三大核心概念对于掌握Docker技术尤为重要。

Docker镜像类似于虚拟机镜像，可以将它理解为一个只读的模板。例如，一个镜像可以包含一个基本的操作系统环境，里面仅安装了Apache应用程序（或用户需要的其他软件）。可以把它称为一个Apache镜像。

镜像是创建Docker容器的基础。通过版本管理和增量的文件系统，Docker提供了一套十分简单的机制来创建和更新现有的镜像，用户甚至可以从网上下载一个已经做好的应用镜像，并直接使用。

Docker镜像与传统xen虚拟化中提到的镜像或者虚拟机模板底层实现原理是截然不同的。联合文件系统是实现Docker镜像的技术基础。

Docker镜像是由文件系统叠加而成。最底端是一个引导文件系统，即bootfs，这很像典型的Linux/Unix的引导文件系统。Docker用户几乎永远不会和引导文件系统有什么交互。实际上，当一个容器启动后，它将会被移到内存中，而引导文件系统则会被卸载（unmount），以留出更多的内存供 initrd磁盘镜像使用。

Docker镜像的第二层是root文件系统rootfs ,它位于引导文件系统之上。rootfs可以是一种或多种操作系统(如 Debian或者Ubuntu文件系统)。

在传统的Linux引导过程中，root文件系统会最先以只读的方式加载，当引导结束并完成了完整性检查之后，它才会被切换为读写模式。但是在Docker里，root文件系统永远只能是只读状态，并且Docker利用联合加载(union mount)技术又会在root文件系统层上加载更多的只读文件系统。

联合加载指的是一次同时加载多个文件系统，但是在外面看起来只能看到一个文件系统。联合加载会将各层文件系统叠加到一起，这样最终的文件系统会包含所有底层的文件和目录。

Docker将这样的文件系统称为镜像。一个镜像可以放到另一个镜像的顶部。位于下面的镜像称为父镜像(parent image),可以依次类推，直到镜像栈的最底部，最底部的镜像称为基础镜像(base image)。

最后，当从一个镜像启动容器时，Docker会在该镜像的最顶层加载一个读写文件系统。我们想在Docker中运行的程序就是在这个读写层中执行的。

当 Docker第一次启动一个容器时，初始的读写层是空的。当文件系统发生变化时，这些变化都会应用到这一层上。比如，如果想修改一个文件，这个文件首先会从该读写层下面的只读层复制到该读写层。该文件的只读版本依然存在，但是已经被读写层中的该文件副本所隐藏。

通常这种机制被称为写时复制(copy on write)，这也是使Docker如此强大的技术之一。 每个只读镜像层都是只读的，并且以后永远不会变化。当创建一个新容器时，Docker会构建出一个镜像栈，并在栈的最顶端添加一个读写层。这个读写层再加上其下面的镜像层以及一些配置数据，就构成了一个容器。

3

Docker容器

Docker容器类似于一个轻量级的沙箱，Docker利用容器来运行和隔离应用。容器是从镜像创建的应用运行实例。可以将其启动、开始、停止、删除，而这些容器都是彼此相互隔离的、互不可见的。

可以把容器看做是一个简易版的Linux系统环境（包括root用户权限、进程空间、用户空间和网络空间等）以及运行在其中的应用程序打包而成的盒子。

镜像自身是只读的。容器从镜像启动的时候，会在镜像的最上层创建一个可写层。

Docker可以帮用户构建和部署容器，用户只需要把自己的应用程序或服务打包放进容器即可。容器是基于镜像启动起来的，容器中可以运行一个或多个进程。我们可以认为，镜像是Docker生命周期中的构建或打包阶段，而容器则是启动或执行阶段。

总结起来，Docker容器就是：

• 一个镜像格式；
• 一系列标准的操作；
• 一个执行环境。

Docker借鉴了标准集装箱的概念。标准集装箱将货物运往世界各地，Docker将这个模型运用到自己的设计哲学中，唯一不同的是：集装箱运输货物，而 Docker运输软件。 每个容器都包含一个软件镜像，也就是容器的“货物”，而且与真正的货物一样，容器里的软件镜像可以进行一些操作。例如，镜像可以被创建、启动、关闭、重启以及销毁。

和集装箱一样，Docker在执行上述操作时，并不关心容器中到底塞进了什么，它不管里面是Web服务器，还是数据库，或者是应用程序服务器什么的。所有容器都按照相同的方式将内容“装载”进去。

Docker也不关心用户要把容器运到何方：用户可以在自己的笔记本中构建容器，上传到 Registry，然后下载到一个物理的或者虚拟的服务器来测试，再把容器部署到Amazon EC2 主机的集群中去。像标准集装箱一样，Docker容器方便替换，可以叠加，易于分发，并且尽量通用。

使用 Docker,可以快速构建一个应用程序服务器、一个消息总线、一套实用工具、一个持续集成(continuous integration, CI)测试环境或者任意一种应用程序、服务或工具。可以在本地构建一个完整的测试环境，也可以为生产或开发快速复制一套复杂的应用程序栈。

可以说，Docker的应用场景相当广泛。

4

Registry与Docker仓库

Docker仓库类似于代码仓库，它是Docker集中存放镜像文件的场所。

有时候会看到有资料将Docker仓库和仓库注册服务器 （Registry）混为一谈，并不严格区分。实际上，仓库注册服务器是存放仓库的地方，其上往往存放着多个仓库。每个仓库集中存放某一类镜像，往往包括多个镜像文件，通过不同的标签（tag）来进行区分。例如存放Ubuntu操作系统镜像的仓库称为Ubuntu仓库，其中可能包括14.04、12.04等不同版本的镜像。

Registry与Docker之间关系如下图所示：

根据所存储的镜像公开分享与否，Docker仓库可以分为公开仓库 （Public）和私有仓库（Private）两种形式。目前，最大的公开仓库是官方提供的Docker Hub，其中存放了数量庞大的镜像供用户下载。 国内不少云服务提供商（如时速云、阿里云等）也提供了仓库的本地源，可以提供稳定的国内访问。

当然，用户如果不希望公开分享自己的镜像文件，Docker也支持用户在本地网络内创建一个只能自己访问的私有仓库。当用户创建了自己的镜像之后就可以使用push命令将它上传到指定的公有或者私有仓库。这样用户下次在另外一台机器上使用该镜像时，只需要将其从仓库上pull下来就可以了。

可以看出，Docker利用仓库管理镜像的设计理念与Git非常相似，实际上在理念设计上借鉴了Git的很多优秀思想。

5

Docker的技术组件

Docker可以运行于任何安装了现代Linux内核的x64主机上。推荐的内核版本是3.8或者更高。Docker的开销比较低，可以用于服务器、台式机或笔记本。

Docker的技术组件主要包括以下几个部分。事实上，每个技术组件展开都是非常长的篇幅，这里我们就不展开论述，有兴趣的同学可以通过末尾提供的学习资源汇总，自行查看相关更加详细的资料。

• 一个原生的Linux容器格式，Docker中称为libcontainer。
• Linxu内核的命名空间（namespace） , 用于隔离文件系统、进程和网络。
• 文件系统隔离：每个容器都有自己的root文件系统。
• 进程隔离：每个容器都运行在自己的进程环境中。
• 网络隔离：容器间的虚拟网络接口和IP地址都是分开的。
• 资源隔离和分组：使用cgroups（即 control group, Linux的内核特性之一）将 CPU 和内存之类的资源独立分配给每个Docker容器。
• 写时复制:文件系统都是通过写时复制创建的，这就意味着文件系统是分层的、快速的，而且占用的磁盘空间更小。
• 日志：容器产生的STDOUT、STDERR和 STDIN这些IO流都会被收集并记入日志， 用来进行日志分析和故障排错。
• 交互式shell：用户可以创建一个伪tty终端，将其连接到STDIN ,为容器提供一个交互式的shell。

6

数据卷：数据持久保持、容器间共享和迁移

数据卷是一个可供容器使用的特殊目录，它将主机操作系统目录直接映射进容器，类似于Linux中的mount操作。

数据卷可以提供很多有用的特性，如下所示：

• 数据卷可以在容器之间共享和重用，容器间传递数据将变得高效方便；
• 对数据卷内数据的修改会立马生效，无论是容器内操作还是本地操作；
• 对数据卷的更新不会影响镜像，解耦了应用和数据；
• 卷会一直存在，直到没有容器使用，可以安全地卸载它。

在用docker run命令的时候，使用-V标记可以在容器内创建一个数据卷。多次重复使用-v标记可以创建多个数据卷。

如果用户需要在多个容器之间共享一些持续更新的数据，最简单的方式是使用数据卷容器。数据卷容器也是一个容器，但是它的目的是专门用来提供数据卷供其他容器挂载。

首先，创建一个数据卷容器dbdata，并在其中创建一个数据卷挂载到/dbdata：

然后，可以在其他容器中使用--volumes-from来挂载dbdata容器中的数据卷，例如创建db1和db2两个容器，并从dbdata容器挂载数据卷：

此时，容器db1和db2都挂载同一个数据卷到相同的/dbdata目录。 三个容器任何一方在该目录下的写入，其他容器都可以看到。

7

容器网络技术：外部访问与容器互联

总体而言，在容器中大致可以通过以下几种虚拟网络技术实现外部对于容器的访问以及容器之间的互联互通。

（1） 宿主机端口映射

在启动容器的时候，如果不指定对应的参数，在容器外部是无法通过网络来访问容器内的网络应用和服务的。

当容器中运行一些网络应用，要让外部访问这些应用时，可以通过-P或-p参数来指定端口映射。当使用-P（大写的）标记时，Docker 会随机映射一个49000~49900的端口到内部容器开放的网络端口：

（2）容器互联

容器的互联（linking）是一种让多个容器中应用进行快速交互的方式。它会在源和接收容器之间创建连接关系，接收容器可以通过容器名快速访问到源容器，而不用指定具体的IP地址。

使用--link参数可以让容器之间安全地进行交互。

下面先创建一个新的数据库容器：

然后创建一个新的web容器，并将它连接到db容器：

Docker相当于在两个互联的容器之间创建了一个虚机通道，而且不用映射它们的端口到宿主主机上。在启动db容器的时候并没有使用-p和-P标记，从而避免了暴露数据库服务端口到外部网络上。

Docker通过两种方式为容器公开连接信息：

• 更新环境变量；
• 更新/etc/hosts文件。

（3）使用Docker虚拟网桥

Docker启动时会在主机上自动创建一个docker0虚拟网桥，实际上是一个Linux网桥，可以理解为一个软件交换机，它会在挂载其上的接口之间进行转发，如图所示。

同时，Docker随机分配一个本地未占用的私有网段（在RFC1918 中定义）中的一个地址给docker0接口。比如典型的172.17.42.1，掩码为255.255.0.0。此后启动的容器内的网口也会自动分配一个同一网段（172.17.0.0/16）的地址。

当创建一个Docker容器的时候，同时会创建了一对veth pair接口（当数据包发送到一个接口时，另外一个接口也可以收到相同的数据包）。这对接口一端在容器内，即eth0；另一端在本地并被挂载到docker0网桥，名称以veth开头（例如vethAQI2QT）。

通过这种方式，主机可以跟容器通信，容器之间也可以相互通信。如此一来，Docker就创建了在主机和所有容器之间一个虚拟共享网络。

除了默认的docker0网桥，用户也可以指定网桥来连接各个容器。在启动Docker服务的时候，使用-b BRIDGE或--bridge=BRIDGE来指定使用的网桥。

（4）libnetwork插件化网络功能

从1.7.0版本开始，Docker正式把网络跟存储这两部分的功能实现都以插件化形式剥离出来，允许用户通过指令来选择不同的后端实现。这也是Docker希望构建围绕着容器的强大生态系统的一些积极的尝试。

剥离出来的独立容器网络项目叫libnetwork，从名字就能看出来，它希望将来为不同容器定义统一规范的网络层标准。事实上，这套网络虚拟化逻辑与Vmware等传统虚拟化厂商的大致是一样的。

libnetwork中容器网络模型（Container Networking Model，CNM）十分简洁，可以让上层使用网络的大量应用容器最大程度上不去关心底层实现。容器网络模型的结构如图所示。

包括三种基本元素：

• Sandbox（沙盒）：代表一个容器（准确地说，是其网络命名空间）；
• Endpoint（接入点）：代表网络上可以挂载容器的接口，会分配IP地址；
• Network可以连通多个接入点的一个子网。

可见，对于使用CNM的容器管理系统来说，具体底下网络如何实现，不同子网彼此怎么隔离，有没有QoS，都可以不关心。只要插 件能提供网络和接入点，只需把容器给接上或者拔下，剩下的都是插件驱动自己去实现。这样就解耦和容器和网络功能，十分灵活。

CNM的典型生命周期如下图所示。首先，是驱动注册自己到网络控制器，网络控制器使用驱动类型，来创建网络，然后在创建的网络上创建接口，最后把容器连接到接口上即可。销毁过程则正好相反，先把容器从接入口上卸载，然后删除接入口和网络即可。

目前CNM支持的驱动类型有四种：Null、Bridge、Overlay、Remote。简单介绍如下：

• Null：不提供网络服务，容器启动后无网络连接；
• Bridge：就是Docker传统上默认用Linux网桥和Iptables实现的单机网络；
• Overlay：是用vxlan隧道实现的跨主机容器网络；
• Remote：扩展类型，预留给其他外部实现的方案，比如有一套第三方的SDN方案（如OpenStack Neutron），就可以接进来。

8

Dcokfile：创建镜像

创建镜像的方法主要有三种：基于已有镜像的容器创建、基于本地模板导入、基于Dockerfile创建。

创建Docker镜像的第一种方法是使用docker com m it命令。可以将此想象为我们是在往版本控制系统里提交变更。

用户也可以直接从一个操作系统模板文件导入一个镜像，主要使用docker import命令。命令格式为docker import[OPTIONS]file|URL|-[REPOSITORY[:TAG]]。

并不推荐使用 docker commit的方法来构建镜像。相反，推荐使用被称为 Dockerfile的定义文件和docker build命令来构建镜像。

Dockerfile使用基本的基于DSL (Domain Specific Language)) 语法的指令来构建一个Docker镜像，推荐使用 Dockerfile方法来代替docker commit.因为通过前者来构建镜像更具备可重复性、 透明性以及幂等性。

一旦有了 Dockerfile，我们就可以使用docker build命令基于该Dockerfile 中的指令构建一个新的镜像。

Dockerfile由一行行命令语句组成，并且支持以#开头的注释行。 一般而言，Dockerfile分为四部分：基础镜像信息、维护者信息、镜像操作指令和容器启动时执行指令。例如：

其中，一开始必须指明所基于的镜像名称，接下来一般是说明维护者信息。后面则是镜像操作指令，例如RUN指令，RUN指令将对镜像执行跟随的命令。每运行一条RUN指令，镜像就添加新的一层，并提交。最后是CMD指令，用来指定运行容器时的操作命令。

Dockerfile指令说明

9

Docker API

除了通过Docker客户端与Docker引擎进行交互之外，Docker还支持通过API的方式来与Docker的各个组件进行交互，包括Docker Registry、Docker Hub和Docker 守护进程等。

在 Docker生态系统中一共有3 种 API。

• Registry API：提供了与来存储Docker镜像的Docker Registry集成的功能。
• Docker Hub API：提供了与 Docker Hub集成的功能。
• Docker Remote API：提供与Docker守护进程进行集成的功能。

所有这3 种 API都是RESTful风格的。其中Remote API进是通过程序与Docker进行集成和交互的核心内容。

通过API我们可以实现Docker的几乎全方位的管理，包括镜像管理、容器管理、公有仓库管理、注册服务器管理等，在大规模容器云自动化管理、可视化运维管理以及DevOps等场景中，尤其有用。

并且自Docker 的 0.9版本开始Docker Remote API开始提供了认证机制。这种认证机制采用了 TLS/SSL证书来确保用户与API之间连接的安全性。

10

Docker命令汇总

一张图总结Docker的命令

Docker与虚拟化

1

Docker为什么能够成功？

Docker实现的种种基础技术（cgroups、namespace、分层文件系统）在Docker之前已经存在很多年。并且，LXC也在诸多企业的生产环境中得到了大量的应用实践，并得到了极为明显的性能优势。

Google大规模容器集群的性能比传统虚拟机要高很多，接近于Bare Metal。与传统虚拟机相比，容器集群让这些公司拥有秒级而非分钟级的弹性计算伸缩能力，同时使用更少的机器运行更多实例。

既然容器技术有如此大的优势，为什么Docker之前，容器并没有引发广泛的关注呢？核心的问题在于易用性，而Docker解决了这个问题。

Docker首次创造了一种简单易行并且覆盖应用全生命周期的工作流，用户可以通过简单的指令或Restful API来拉取、打包、运行和维护容器。这种简化从根本上降低了应用程序部署的难度，极大地提高了应用运行时环境的部署与维护的效率。

用户可以不依赖类似Ansible、Chef、Puppet这类的配置管理和发布系统，不需要在部署中同时关注基础系统与软件的安装配置，以及应用的安装调试。

Docker提供了一种统一的实践方法，每个服务（或应用）维护一个Dockerfile文件。即便使用编排工具如Docker Compose，一个服务（或应用）也只需维护一个docker-compose.yml文件。应用程序及其运行时环境全部打包到一个简单易读的Dockerfile或Compose文件中， 开发团队和运维团队都可以透明地合作维护这个文件，极大降低了沟通成本与部署成本，极大满足了研发团队与DevOps团队、运维团队之间的沟通需求，清晰划分了责任边界。

Docker正以一种前所未有的方式让用户可以在各种Linux发行版、各种开发环境中快速切换，这对应用开发者来说真是一种福音。

使用各种开发环境的用户，再也不必担心破坏主机的系统环境（如环境变量）和应用程序。系统架构师们也可以使用Docker来快速搭建各种网络架构的系统，且可以方便地管理这些系统之间的数据连接和共享。

目前Docker发展迅速，基于Docker的PaaS平台也层出不穷。这让技术创业者无需折腾服务器部署，只需专注业务代码的实现即可。

真正解决用户痛点，真正带来效率的提升，是一个产品和技术能最终成功的关键！

2

Docker与虚拟化的区别

两者的架构区别如下：

前人总结的两者的主要区别如下：

关于Docker是否能够取代虚拟化，是个被讨论很久的问题，个人愚见：虚拟化和Docker并不是对立与相互取代的关系，场景化需求才是两种技术选择的关键。

虚拟机和容器技术本身并不对立，也不存在谁取代谁的问题，关键是企业是否合理运用技术在合理的应用场景当中解决相应的技术问题，未来的企业级云平台也应该囊括对这些技术的支持，以满足企业对不同业务所需不同技术栈的灵活选择！

关于这一点，我们后面还有文章深度探讨。

事实上，Docker技术极大的改变了企业建设应用系统的流程和生态，Docker本身也与虚拟化、微服务架构、DevOps、自动化运维等之间有着千丝万缕的联系。

我们将在后续的文章中，继续探讨两个问题：

1. Docker容器技术在可见的未来，比如3-5年，能够完全取代虚拟化技术吗？
2. Docker与微服务、DevOps之间有怎样的关系？它们如何一起改变了企业应用开发的生态和工作流程？