Docker使用的思考和理解有哪些，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
目前创新互联已为上千多家的企业提供了网站建设、域名、网络空间、网站托管运营、企业网站设计、门源网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
一、分享背景：
上次在群里分享完持续集成和发布后，群里也有很多同学在问我docker应用和发布部署的一些问题，我们做了一些讨论，再加上昨天看到的一个视频，感觉我们其实对于Docker的应用并没有理解很清楚。
再加上之前有一段时间我也被这个问题困扰过，有一些自己的思考和理解。所以中午的时候把之前自己的一些思考和记录稍微整理了下，在这里跟大家分享，当抛砖引玉，时间比较紧，可能有些地方说的不一定准确，内容也不是太多，大家可以随意拍砖讨论。
首先声明一下，本次分享属于个人观点，不代表任何组织和机构。同时，我只是从Docker使用的角度谈一下我的理解。所以，本次不是Docker技术、原理以及实现等相关细节的讨论，像“希特勒Docker”视频中提到的Kernel Panic、网络问题、隔离性这些Docker纯技术层面上的问题不在本次范围讨论中。
本次分享应该算是另外一个维度的解读。下面开始进入正题：
首先，Docker的理念说的直接一点就是向用户直接交付APP，而不是物理或虚拟的机器资源，这样可以大大提升系统集成、发布和部署的效率，而且可以Run Anywhere，所以这个理念一出，再加之Docker的正式发布，火热程度已经不能用火爆来形容了，我们好像见到了救世主，见到了又一颠覆性的技术诞生。
但是，经过一些实践和思考后，我经常会反问我自己、我的团队或者同行的几个问题是：
a、当前我们遇到的问题，不用Docker，在现有的基础架构和体系上是不是就一点办法都没有？
b、发布和部署效率低、人肉介入多，这些问题是不是用了Docker就一定能解决了？
b、引入了Docker来解决这些问题，带来的对原有系统的改造所投入的成本有多大，是不是能真正能带来效益的最大化？
大家也可以自己反问一下自己，看看你的思考是什么？
随着我们自己团队在做持续集成和发布系统的过程中，我们内部也在思考、讨论和碰撞，通过一个阶段的思考和总结，我们有了自己的一些认识。所以延续着上次分享的思路，我们先看看引入了Docker会是怎样一个情况：
以上次我在群里分享的持续集成和发布系统为例，一次集成和发布的过程涉及众多的环节和影响因素，比如应用配置管理、多环境管理、版本分支和合并策略、打包策略、发布策略、发布粒度、服务注册的上下线等等，如果是web服务，还要在Proxy或其它软负载上面进行流量切换，对于弹性扩容和缩容，我们还要依赖容量评估系统（有的同学说只看下系统负载就好了，其实这只是最简单的指标，完全达不到评估的需求）。
其实，可以看到，运维是一个非常非常重视体系化建设的工作或工种，把这些东西做到位，运维就不会low。
我们回来，这一套的流程和系统建设又依赖严格地标准化规范和标准化流程的制定，同时规范和流程的制定，又不能单单依赖运维单方面的意愿，还要跟开发、测试、SCM等等团队进行协作共同制定，制定好了，大家还得能够自觉的遵守，然后开发对应的系统和平台，来自动化上述的一切过程。
关于上次分享的内容，这里不做赘述，具体细节，大家可以参考上次的分享内容。
好了，我们回到Docker，上述持续集成和发布中的每一个环节，用刚才的问题反问自己，我们找几个环节做几个对比，比如：
a、应用配置管理，我们现在是通过系统来管理一个个配置项，其它系统通过API来获取配置。引入了Docker，对应的就是通过DockerFile来做配置，反问一下，DockerFile需要管理吗？怎么管理？多环境情况下又怎么来处理？
b、打包构建过程，现有方式是拉代码取配置，然后生成war包。引入了Docker，对应的就是生成镜像，反问一下，生成镜像需要拉代码并获取配置吗？
c、标准化和流程规范建设，这个貌似跟用不用Docker没关系，不管用不用都要制定，只有源头理顺了，后面才能开发才会顺。
d、现有的代码管理使用Git，每一次提交通过commit来识别，版本分支合并每个公司都有自己的管理策略。引入了Docker使用镜像仓库，但是镜像仓库是不是也需要来管理呢？这个管理平台是不是也要定制开发呢？版本分支策略根据各个公司的实际情况不同，也会不同，这也是个管理策略问题，好像应该不是Docker的管理范畴。
d、其它，就不一一对比了。
我想通过以上比对和反问，我们可以得出这么个结论：
基础的工作，发布的环节和细节的梳理，标准化、发布流程规范、应用配置管理、多环境管理、发布策略、服务上下线等等环节，不管用不用Docker，我们都要做，这个是基础。
a、有些环节上，与用不用Docker没有任何关系，在这些环节上Docker不会提升任何效率，也解决不了任何问题，比如标准化、流程的约定、版本分支合并的策略等等，这个是技术管理体系内的事情。
b、某些环节上，用或不用Docker的区别只是用不同的方式来实现，说的实在一点就是最终都要用代码或脚本一行行敲出来来实现。仅对发布而言，绝大多数的环节，不会有任何的省略，至于是否可以提升效率，还有待评估。
再来个案例对比：
我上次的分享中已经给大家展示了通过发布系统的方式来完整的实现一次持续集成和发布过程。下面这个用Docker来做发布的案例，这个是QCon上某服务厂商的分享（注明：仅做对比使用），可以看到，对于多环境的判断、端口的设定、启动的方式、配置的路径等等，这些全部也都是用脚本一行行实现出来的。
提这个案例，也只是想说明，基础的东西，不管用不用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是非常重视基础的标准化和规范化的，但是这个精髓大家都理解了吗？大家的日常工作都做到标准和规范了吗？
所以我们要认识到，Docker只是提供了这样一套统一的应用标准，至于怎么能够用起来，是需要我们自己根据各自业务的现状去定制、去开发、去实现的，这个是要我们亲自动手去做的。
同时，基于这套标准去适配，是要付出改造的成本和代价的，比如上面提到的那些点，对于技术细节来说还会有隔离性、网络、IO等等一系列的技术改造和适配问题，这个成本和代价才是Docker的火热的Fans们与“希特勒”的抗拒者们产生矛盾的最根本的原因。（注意，这里想强调的是，我们做的每一件事情都是有成本和代价的，Docker一样不例外。）
所以Docker的使用应该或者一定是一个逐步演进的过程，不是一蹴而就的。之所以这样讲：
a、还是因为基础要打好，比如标准化、流程规范的制定，应用配置管理、CMDB的建设等等，这些基础的事情是永恒不变的，只有基础做好了，我们才能更好的基于基础去开发和改造，对接到Docker上去，这些东西没有，只是单纯的用Docker，一切都是枉然。所以，一旦我们基于这些基础工作，能够很方便高效的生成镜像了，那扩容和部署的效率是不是自然也就提升了呢，Docker的威力是不是才发挥出来了呢。
b、从运维的角度，Docker是基于APP的管理和运维模式，它的唯一标示是容器ID，而当前绝大数系统的运维是基于资源和IP的运维模式，它的唯一标示是IP，所以两种模式基本是不相容的。而且围绕IP的运维模式，又衍生出了发布、部署、监控、稳定性、容量评估等等一系列的系统，所以如果要用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：基于docke来进行部署仅仅只为了部署环境一致。这个学习时间是否值得？还是说docket有其他值得学习的地方，可以具体说下吗？
通过Docker来保证环境一致有它的优势，只要拉对应的Image即可，他的理念和原理可以好好学习下。但是我还是想说Docker只是一个手段，不是目的。
任何一个新技术都值得学习和研究，但是真正应用的时候，最好是从问题出发，我们的目标和目的一定是解决问题。
Q6：关于蘑菇街标准化、流程规范的具体内容是否可以分享。
这个上次分享过一个提纲，但是具体内容还要看各自的产品和业务的特点来定，我建议你可以做一下总结和思考，这个也必须是从实际出发，即使公布了全套的规范和细节，但是也不一定适用到每个生产环境上。遇到具体问题我们可以讨论，这里不展开说了。
关于Docker使用的思考和理解有哪些问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注创新互联行业资讯频道了解更多相关知识。