01、本质上的区别

VM(VMware)在宿主机器、宿主机器操作系统的基础上创建虚拟层、虚拟化的操作系统、虚拟化的仓库，然后再安装应用；

Container(Docker容器)，在宿主机器、宿主机器操作系统上创建Docker引擎，在引擎的基础上再安装应用。

那么问题来了，没有操作系统，怎么运行程序？

可以在Docker中创建一个ubuntu的镜像文件，这样就能将ubuntu系统集成到Docker中，运行的应用就都是ubuntu的应用。

02、使用上的区别

Size

• 虚拟机中ubuntu所占内存：

• Docker容器中ubuntu镜像文件所占内存：

01、Startup

Docker在宿主机器的操作系统上创建Docker引擎，直接在宿主主机的操作系统上调用硬件资源，而不是虚拟化操作系统和硬件资源，所以操作速度快。

这个其实安装一个ubuntu的虚拟机和拉取一个Docker的ubuntu镜像文件，运行一下就知道了，区别很明显，虚拟机开一下大概得2分多钟，而Docker只需要2秒钟。

02、Integration

首先，Docker可以让你非常容易和方便地以“容器化”的方式去部署应用。它就像集装箱一样，打包了所有依赖，再在其他服务器上部署很容易，不至于换服务器后发现各种配置文件散落一地，这样就解决了编译时依赖和运行时依赖的问题。

其次，Docker的隔离性使得应用在运行时就像处于沙箱中，每个应用都认为自己是在系统中唯一运行的程序，就像刚才例子中，A依赖于python 2.7，同时A还依赖于B，但B却依赖于Python 3，这样我们可以在系统中部署一个基于Python 2.7的容器和一个基于Python 3的容器，这样就可以很方便地在系统中部署多种不同环境来解决依赖复杂度的问题。这里有些朋友可能会说，虚拟机也可以解决这样的问题。诚然，虚拟化确实可以做到这一点，但是这需要硬件支持虚拟化及开启BIOS中虚拟化相关的功能，同时还需要在系统中安装两套操作系统，虚拟机的出现是解决了操作系统和物理机的强耦合问题。但Docker就轻量化很多，只需内核支持，无需硬件和BIOS的强制要求，可以轻松迅速地在系统上部署多套不同容器环境，容器的出现解决了应用和操作系统的强耦合问题。

正因为Docker是以应用为中心，镜像中打包了应用及应用所需的环境，一次构建，处处运行。这种特性完美解决了传统模式下应用迁移后面临的环境不一致问题。同时，Docker压根不管内部应用怎么启动，你自己爱咋来咋来，我们用docker start或run作为统一标准。这样应用启动就标准化了，不需要再根据不同应用而记忆一大串不同启动命令。

基于Docker的特征，现在常见的利用Docker进行持续集成的流程如下：
开发者提交代码
触发镜像构建
构建镜像上传至私有仓库
镜像下载至执行机器
镜像运行

其基本拓扑结构如图1所示

熟悉Docker的朋友都知道，Docker启动非常快，可以说是秒启。在上述的五步中，1和5的耗时较短，整个持续集成主要耗时集中在中间的3个步骤，也就是docker build、docker push、docekr pull这样还是无法达到顺滑的极致要求，下来我们来分析下build、push、pull的耗时和解决方法：

03、docker build

网络优化

dockerhub的官方镜像在国外，由于众所周知的原因，在国内进行构建时网络会是很大的瓶颈，甚至某些公司的环境是无Internet连接的。

在这种情况下，建议使用国内的镜像源，或者自己搭建私有仓库，保存项目需要的基础镜像，把构建过程中的网络传输都控制在国内或者内网，这样就不用再考虑网络方面的问题。

使用 .dockerignore文件

dockerignore文件的设计是为了在docker build的过程中排除不需要用到的文件以及目录，目的是为了docker build这个过程可以尽可能地快速高效以及构建出来的image没有多余的“垃圾”。

最小化镜像层数（layers）

把镜像层数减到最少，能加快容器的启动速度，但是这里也要权衡另一个问题：dockerfile的可读性。你可以把一个dockerfile写得很复杂以达到构建出最小层数的镜像，但同时你的dockerfile可读性也降低了。所以我们要在镜像层数和dockerfile可读性之间做出妥协。

04、docker push

docker registry升级到v2后加入了很多安全相关检查，在v2中的镜像的存储格式变成了gzip ，镜像在压缩过程中占用的时间也比较多。我们简单分解一下docker push的流程。

buffer to disk，将该层文件系统压缩成本地的一个临时文件；
上传文件至registry；
本地计算压缩包digest，删除临时文件，digest传给registry；
registry计算上传压缩包digest并进行校验；
registry将压缩包传输至后端存储文件系统；
重复1-5直至所有层传输完毕；
计算镜像的manifest并上传至registry重复 3-5。
这样的设计导致push会很慢，如果采用官方的dockerhub，需要考虑docker build一节中提及的网络方面影响，dockerhub公有镜像库还需考虑安全方面的因素。

同时docker和registry设置了过多的安全防范措施（如双向证书认证等），主要是为了防止在公有云的环境下镜像的伪造和越权获取。但是在一个可信的环境内，如果build和push过程都是自己掌控，很多措施都是多余的。

05、docker pull

docker pull 镜像的速度对服务启动速度至关重要，好在registry v2后可以并行pull了，速度有了很大改善。但是依然有一些小的问题影响了启动的速度：

下载镜像和解压镜像是串行的；

串行解压，由于v2都是gzip要解压，尽管并行下载了还是串行解压，内网的话解压时间比网络传输都要长；

和registry通信， registry在pull的过程中并不提供下载内容只是提供下载url和鉴权，这一部分加长了网络传输，而且一些metadata还是要去后端存储获取，延时还是有一些的。

通过刚才的分析，大家可以看到，其实docker build、push、pull其实主要耗时是在网络传输（主要）及安全防范措施（轻微）上，整个传输过程甚至大大超过了其他所有步骤的时间；这样可以借助我们的AppHouse方便的搭建本地企业级镜像仓库，将网络传输转移至内网，同时完全掌控了 build、push和pull的过程，这样提高效率的同时也解决了安全问题，可谓一举两得。
经过Docker、AppHouse的帮助，我们距极致追求的如丝般顺滑的持续集成目标只有一步之遥，Docker解决了依赖和环境问题，AppHouse解决了镜像安全快速传输的问题，接下来就是容器的部署和管理问题。

Docker实现了底层技术的创新，它的出现将开发者从与系统的纠缠中释放了出来，但是阻碍企业使用Docker的问题是容器的大规模部署、管理问题和缺少企业级容器工具及系统。

镜像创建完成后，需要把它发布到测试和生产环境。因为Docker占用资源小，在单个服务器上部署成百上千个容器也不足为奇。这个阶段中如何更合理地使用Docker也是一个难点，开发团队需要考虑如何打造一个可伸缩扩展的分发环境。

AppSoar提供人性化的Web管理界面，丰富的Compose文件格式和功能完备的API接口，通过Compose实现以十分简单的文件描述复杂的应用结构，让部署变得更简单。并且，AppSoar还提供丰富的企业应用商店，让一键创建服务成为可能。这样可以快速搭建应用场景，开发者只需要关注开发本身即可。

打通最后一个环节后，整个持续集成平台架构演进到如图2所示。

03、Docker特点

上手快

用户只需要几分钟，就可以把自己的程序“Docker 化”。Docker 依赖于“写时复制” (copy-on-write)模型，使修改应用程序也非常迅速，可以说达到“随心所致，代码即改” 的境界。

随后，就可以创建容器来运行应用程序了。大多数 Docker 容器只需要不到 1 秒中即可 启动。由于去除了管理程序的开销，Docker 容器拥有很高的性能，同时同一台宿主机中也可以运行更多的容器，使用户尽可能的充分利用系统资源。

职责的逻辑分类

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

快速高效的开发生命周期

Docker 的目标之一就是缩短代码从开发、测试到部署、上线运行的周期，让你的应用程序具备可移植性，易于构建，并易于协作。(通俗一点说，Docker 就像一个盒子，里面可以装很多物件，如果需要这些物件的可以直接将该大盒子拿走，而不需要从该盒子中一件 件的取。)

鼓励使用面向服务的架构

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

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！