ArchSummit 微课堂，追捧 & 抗拒 | Docker 使用的一些思考和理解

本文整理自 ArchSummit 微信大讲堂线上群分享内容，此次分享的内容是比较有挑战性，也是比较容易引起争执的一个话题，所以抛砖引玉，大家可以尽情讨论。

一、分享背景

上次在群里分享完持续集成和发布后，群里也有很多同学在问我 docker 应用和发布部署的一些问题，我们做了一些讨论，再加上昨天看到的一个视频，感觉我们其实对于 Docker 的应用并没有理解很清楚。

再加上之前有一段时间我也被这个问题困扰过，有一些自己的思考和理解。所以中午的时候把之前自己的一些思考和记录稍微整理了下，在这里跟大家分享，当抛砖引玉，时间比较紧，可能有些地方说的不一定准确，内容也不是太多，大家可以随意拍砖讨论。

首先声明一下，本次分享属于个人观点，不代表任何组织和机构。同时，我只是从 Docker 使用的角度谈一下我的理解。所以，本次不是 Docker 技术、原理以及实现等相关细节的讨论，像“希特勒 Docker”视频中提到的 Kernel Panic、网络问题、隔离性这些 Docker 纯技术层面上的问题不在本次范围讨论中。

本次分享应该算是另外一个维度的解读，下面开始进入正题。

首先，Docker 的理念说的直接一点就是向用户直接交付 APP，而不是物理或虚拟的机器资源，这样可以大大提升系统集成、发布和部署的效率，而且可以 Run Anywhere，所以这个理念一出，再加之 Docker 的正式发布，火热程度已经不能用火爆来形容了，我们好像见到了救世主，见到了又一颠覆性的技术诞生。

二、对 Docker 使用的一些困惑

但是，经过一些实践和思考后，我经常会反问我自己、我的团队或者同行的几个问题是：

a、当前我们遇到的问题，不用 Docker，在现有的基础架构和体系上是不是就一点办法都没有？

b、发布和部署效率低、人肉介入多，这些问题是不是用了 Docker 就一定能解决了？

c、引入了 Docker 来解决这些问题，带来的对原有系统的改造所投入的成本有多大，是不是能真正能带来效益的最大化？

大家也可以自己反问一下自己，看看你的思考是什么？

随着我们自己团队在做持续集成和发布系统的过程中，我们内部也在思考、讨论和碰撞，通过一个阶段的思考和总结，我们有了自己的一些认识。所以延续着上次分享的思路，我们先看看引入了 Docker 会是怎样一个情况。

以上次我在群里分享的持续集成和发布系统为例，一次集成和发布的过程涉及众多的环节和影响因素，比如应用配置管理、多环境管理、版本分支和合并策略、打包策略、发布策略、发布粒度、服务注册的上下线等等，如果是 web 服务，还要在 Proxy 或其它软负载上面进行流量切换，对于弹性扩容和缩容，我们还要依赖容量评估系统（有的同学说只看下系统负载就好了，其实这只是最简单的指标，完全达不到评估的需求）。

其实，可以看到，运维的建设是一个非常非常重视体系化建设的工作或工种，把这些东西做到位，运维就不会 low。

我们回来，这一套的流程和系统建设又依赖严格地标准化规范和标准化流程的制定，同时规范和流程的制定，又不能单单依赖运维单方面的意愿，还要跟开发、测试、SCM 等等团队进行协作共同制定，制定好了，大家还得能够自觉的遵守，然后开发对应的系统和平台，来自动化上述的一切过程。

关于上次分享的内容，这里不做赘述，具体细节，大家可以参考上次的分享内容。

好了，我们回到 Docker，上述持续集成和发布中的每一个环节，用刚才的问题反问自己，我们找几个环节做几个对比，比如：

a、应用配置管理，我们现在是通过系统来管理一个个配置项，其它系统通过 API 来获取配置。引入了 Docker，对应的就是通过 DockerFile 来做配置，反问一下，DockerFile 需要管理吗？怎么管理？多环境情况下又怎么来处理？

b、打包构建过程，现有方式是拉代码取配置，然后生成 war 包。引入了 Docker，对应的就是生成镜像，反问一下，生成镜像需要拉代码并获取配置吗？

c、标准化和流程规范建设，这个貌似跟用不用 Docker 没关系，不管用不用都要制定，只有源头理顺了，后面才能开发才会顺。

d、现有的代码管理使用 Git，每一次提交通过 commit 来识别，版本分支合并每个公司都有自己的管理策略。引入了 Docker 使用镜像仓库，但是镜像仓库是不是也需要来管理，版本分支策略根据各个公司的实际情况不同，也会不同，好像不是 Docker 的管理范畴。

e、其它，就不一一对比了。大家可以自己思考一下。

我想通过以上比对和反问，我们可以得出这么个结论：基础的工作，发布的环节和细节的梳理，标准化、发布流程规范、应用配置管理、多环境管理、发布策略、服务上下线等等环节，不管用不用 Docker，我们都要做，这个是基础。

a、有些环节上，与用不用 Docker 没有任何关系，在这些环节上 Docker 不会提升任何效率，也解决不了任何问题，比如标准化、流程的约定、版本分支合并的策略等等，这个是技术管理体系内的事情。

b、某些环节上，用或不用 Docker 的区别只是用不同的方式来实现，说的实在一点就是最终都要用代码或脚本一行行敲出来来实现。仅对发布而言，绝大多数的环节，不会有任何的省略，至于是否可以提升效率，还有待评估。

三、Docker 使用场景的几个案例

我上次的分享中已经给大家展示了通过发布系统的方式来完整的实现一次持续集成和发布过程。下面这个用 Docker 来做发布的案例，这个是 QCon 上某服务厂商的分享（注明：仅做对比使用），可以看到，对于多环境的判断、端口的设定、启动的方式、配置的路径等等，这些全部也都是用脚本一行行实现出来的。

提这个案例，也只是想说明，基础的东西，不管用不用 Docker，都是要做的，这个绝不是我们理解的那样，用了 Docker 这些问题就不存在了，况且用了 Docker 也不见得这个工作量真的会更小。

可能这个时候，大家要提到，发布可能是不会比之前有效率，但是扩容部署可以，对，这个观点我严重同意，但是会有一些前提条件的满足，后面马上会提到。

四、我对 Docker 的理解和建议

好了，上面举了一个例子，可能会有以偏概全的嫌疑，后面还有一个。但是先说说个人对 Docker 的理解。

写这个文章或做这次分享，绝不是要黑 Docker 或排斥 Docker，而是期望我们能更合理、更理性的使用 Docker，千万不要认为 Docker 是银弹，认为 Docker 是解决一切效率问题的手段，同时也不能极端的认为，Docker 有这么多的坑，而且也不能解决我的问题，所以就坚决排斥，这两种观点都是狭隘的、不够开放的心态，也是当前普遍的对 Docker 肤浅的认识。

好的，那我谈⼀一下对 Docker 使用的建议（只是我个人的理解，不见得正确和合理，欢迎拍砖和讨论）。

最根本的，我们要汲取 Docker 的先进理念，持续集成和发布 & 部署，Run Anywhere。

a、持续集成和发布 & 部署，如何能够更好更快的向业务交付应用，如何让业务需求快速上线产生实际的价值，这个才是我们的目标，一定不要跑偏了。Docker 的出现实际就是为了要朝这个目标发展的，所以理念和精髓理解了，至于怎么实现，是方式选择问题。千万不要为了 Docker 而 Docker，不要为了技术炫酷而 Docker。

b、Run Anywhere，Docker 最关键的一点就是制定了应用的标准化，通过 Docker 的封装来屏蔽各种应用上的个性化差异，比如 DockerFile，其实就是为了统一和标准应用的配置，比如 Docker 的启停、销毁、更新等，统一的接口标准，比如镜像仓库，统一了镜像的标准等等，所以标准化是 Docker 最核心价值。

所以我们要认识到，Docker 只是提供了这样⼀一套统⼀一的应用标准，至于怎么能够用起来，是需要我们自己根据各自业务的现状去定制、去开发、去实现的，这个是要我们亲自动手去做的。

同时，基于这套标准去适配，是要付出改造的成本和代价的，比如上面提到的那些点，对于技术细节来说还会有隔离性、网络、IO 等等一系列的技术改造和适配问题，这个成本和代价才是 Docker 的火热的 Fans 们与“希特勒”的抗拒者们产生矛盾的最根本的原因。（注意，这里想强调的是，我们做的每⼀件事情都是有成本和代价的，Docker⼀一样不例外。）

所以 Docker 的使用应该是一个演进的过程，不是一蹴而就的。之所以这样讲是因为：

a、还是因为基础要打好，比如标准化、流程规范的制定，应用配置管理、CMDB 的建设等等，这些基础的事情是永恒不变的，只有基础做好了，我们才能更好的基于基础去开发和改造，对接到 Docker 上去，这些东西没有，只是单纯的用 Docker，一切都是枉然。所以，一旦我们基于这些基础工作，能够很方便高效的生成镜像了，那扩容和部署的效率是不是自然也就提升了呢，Docker 的威力是不是才发挥出来了呢。

b、从运维的角度，Docker 是基于 APP 的管理和运维模式，它的唯一标示是容器 ID，而当前绝大数系统的运维是基于资源和 IP 的运维模式，它的唯一标示是 IP，所以两种模式基本是不相容的。而且围绕 IP 的运维模式，又衍生出了发布、部署、监控、稳定性、容量评估等等一系列的系统，所以如果要用 Docker，就意味着这些系统都要做对应的改造，这个成本和代价会非常的大，所以只能慢慢来，同时基于容器的一整套生态系统也需要逐步的打磨和建设。当然类似的问题，还有很多，所以我们会发现 Docker 的应用必须要稳扎稳打逐步来。

c、同时基于容器的⼀一整套生态系统也需要逐步的打磨和建设，比如安全、权限、存储等等，这个生态目前来讲也是在逐步的完善过程中。

不过，业界很多厂商也在考虑这个问题，不断的再完善 Docker 生态，我想这将是 Docker 会继续蓬勃发展下去的最大驱动力，我们也在持续的关注。比如 Rancher，图来自 InfoQ 网站。

这里再插播⼀个我们的实际案例，我们曾在去年双 11 前，花了大约 3 周左右开发过⼀个基于 Docker 的 Web 部署系统，整个理念就是用容器 ID 作为唯⼀标示，而没有用 IP 做标示。

(点击放大图像)

(点击放大图像)

(点击放大图像)

当时的实际效果，可以做到分钟级的部署和快速上线，主要是为了应对大促峰值流量时的快速扩容。双11 大促线上也跑了⼀部分Docker，但是因为容量充足，当时大促期间并没有进行扩容动作。我们后来想推广到线上日常使用，但是最终因为跟原有体系种种的不兼容或者改造成本大而没有广泛应用起来。比如监控、日常维护时命令输出不⼀致、限流策略等等，当然现在我们有专门的⼀个团队在做这方的建设，当⼀系列基础不断完善起来后，这个系统我们依然会重新使用起来。

前段时间跟同行交流这个问题，我们得出的一个一致意见是，“一个新生事物或新技术的引入，应该是从解决现有体系的痛点入手和出发，只有真正能帮研发和业务解决实际问题和痛点了，这样的技术才会有生命力”。

最后以我看到的一篇文章中的一句话做结尾，跟大家共勉： “脚踏实地的解决问题就是创新，我们失败的原因往往是因为急于求成”。

五．Q&A

Q1：现在业界也有很多成功的案例，特别是云服务厂商和 BAT 都有产品推出，他们为什么都很成功，也有成功案例。

还是要说基础建设的重要性，我们跟阿里的同学交流比较多，阿里的标准化、流程规范化之完善和严格，⼀直是我们的标杆。我想每⼀个能够做成这件事情的公司和团队，在前期⼀定是有大量的基础建设工作，所以我们不要光看到表面上的强大和光鲜，这背后⼀定是有很稳固的基础在发挥作⽤用的，类似于高楼大厦和摩天大楼的地基，脑补⼀下就理解了。

同时，每个公司的技术人员的实力和技术储备不⼀样，这⼀点在优秀的互联网公司那里是非常大的⼀个优势，所以可以很快速的研发出可应用的产品。还有很多战略上的考虑，比如各大云服务⼚厂商，不甘在这块领域落后，必然会投入重兵进行研发和布局。

Q2：有一些小的或初创公司也有很成功的案例，这个怎么解释?

这个我的理解，规模不大或者初创的公司，没有历史包袱或者较小，从⼀开始就可以基于 Docker 为基础设施，围绕着这个基础，能够建设出和实现出⼀些成功和优秀的案例，也是非常正常的。但是对于稍大⼀点的公司，就是我文中提到的，必然会涉及到改造成本和代价，这个时候的 ROI 就要多方面综合考虑，出发点不同，就会有不同的决策，但是肯定是会有⼀些取舍的。

Q3：Docker 用在生产环境以机构成熟了吗？蘑菇街的测试环境是否都用的 docker？

这个再提一下，还是那个问题，把围绕 docker 建设的基础工作做好，上生产环境的条件就成熟了。但是稳定性上还要看线上实际运行情况，这个要用事实说话，再大规模的生产环境上运行，还要强大的技术储备，关键时刻必须能 hold 住。我们的测试环境只有部分 docker，下一步会考虑通过 docker 部署，部署效率上是 docker 的优势。

Q4：基于 Docker 遇到的最大的坑是什么？

我觉得从多个方面理解吧，如果从应用方式上，对于 docker 应用姿势不对和思维模式上有问题，这个就是最大的坑，这个是要好好总结和思考的，关键是看解决什么问题。

技术上，我不在这里卖弄了，大家可以看一下我的另外一位同事郭嘉分享的内容，在 InfoQ 上也有文章。

Q5：基于 docket 来进行部署仅仅只为了部署环境一致。这个学习时间是否值得？还是说 docket 有其他值得学习的地方，可以具体说下吗？

通过 Docker 来保证环境一致有它的优势，只要拉对应的 Image 即可，他的理念和原理可以好好学习下。但是我还是想说 Docker 只是一个手段，不是目的。 任何一个新技术都值得学习和研究，但是真正应用的时候，最好是从问题出发，我们的目标和目的一定是解决问题。

Q6：关于蘑菇街标准化、流程规范的具体内容是否可以分享。

这个上次分享过一个提纲，但是具体内容还要看各自的产品和业务的特点来定，我建议你可以做一下总结和思考，这个也必须是从实际出发，即使公布了全套的规范和细节，但是也不一定适用到每个生产环境上。遇到具体问题我们可以讨论，这里不展开说了。

讲师介绍

赵成，花名谦益，ArchSummit 北京的明星讲师，现在负责蘑菇街运维团队的管理以及运维体系的建设工作。在运维行业中已经做了 7 年，之前有过 5 年左右的业务开发经历。加入蘑菇街之前在华为一直做电信级业务的开发和运维工作。

长按下方二维码关注 ArchSummit 公众号，获取更多干货，不错过任何一次大牛分享……

ArchSummit**** 架构师峰会 2016 深圳站将于 7 月 15-16 举行，邀请了来自 Uber、Twitter、Netflix、腾讯、百度、阿里等公司的 50 多位 CTO 和研发总监，为大家带来更多精彩的线下分享 ，更多精彩点击这里。