在上次推送的文章中（传送门），田琪老师分享了他的DockerCon 2015峰会见闻。在“QCon高可用架构群”中，田老师分享之后，几位专家也参与了讨论。他们是：
- 闫国旗：京东资深架构师，京东架构技术委员会成员，负责京东云基础服务建设，也参加了DockerCon 2015峰会。
- 王渊命：技术极客，协作IM服务@Grouk联合创始人，也是Docker深度实践者。
- 陈飞：微博资深架构师，微博平台Docker容器项目负责人。
首先，闫国旗也分享了他的参会感受：
这次DockerCon 2015主要围绕着这四大方向：开发平台、扩展、开放标准和商业支持。具体而言：
开发平台如田大师前面提到的内容，回顾近两年Docker在这一方面的努力，及一些产出。Docker Container/Docker
Registry/Docker Compose/Docker Machine/Docker
Swarm等。这些产品其实在去年都已上线。其实我们大家都也了解，本质上Docker的优势就是生态，所采用的技术都是各平台所提供的，充其量在这里Docker只能算一个“服务编排者“的角色，当然这个比喻可能不是很恰当。没有技术竞争力，被替代的可能性就会很高，正像Docker同CoreOS的竞争一样，在这里都没有太多的话语权。也许正是因为如此，才会走向开放之路。Docker将自己的runtime贡献给了runC项目，将appc合并进OCF。表面看起来是走向融合，但本质上如何，Solomen和Alex或许会有更多的感触.
不过Docker令我个人最不爽的就是Projet
Orca项目，基本上把会场外面那些基于Docker的创业公司逼向绝路。这是个人最不喜欢的地方。在DockerCon
2015会后，我们也有幸前往CoreOS的公司做了技术交流。对于Docker向CoreOS隔空喊话，他们也只能表示”呵呵“。
微博平台Docker容器化项目负责人陈飞也谈了他的看法和感受。
这次DockerCon，之前也只是通过PPT有些简单了解，今天田大师分享后，收益颇多。下面，谈谈个人粗浅的感受：
一是Docker的扩展机制，这个还是挺激动人心的，刚才田大师也提到，目前已经有network plugin和volume
plugin走在前面了。相信大家在这块是比较纠结的，一方面Docker本身可能不能满足一些场景，需要做一些定制扩展，如果改它源码的话，可能会造成与社区脱节的问题，相信有了这个机制，后续扩展会更加方便。二是Open Container
Project。在一定程度上“应该”会避免容器runtime标准的分化，以后应该可以放心来做容器的调度管理，而不用担心某一天底层运行时闹革命。不过感觉是各家貌合心不合。三是Shopify使用DNS来做服务发现，以及libnetwork的进展。不过libnetwork提到服务发现会是其基本功能，也是基于DNS实现的，非常cool，不过感觉它是不是有点想多了。
还有一个就是这次大会，貌似没有提Mesos和Kubernates，记得上次大会有提到Swarm和Mesos会有一个亲密接触，不知道现在进展如何了。大规模集群调度管理，Swarm还是处于pre-production的状态。Docker解决了单机namespace，cgroup等容器技术组合的复杂性问题，集群技术如何简化，这里机会应该蛮多。
Grouk联合创始人王渊命也谈到了他对这次大会的看法和感受。
大家好，我们是初创团队，主要在DevOps方向使用Docker，和持续集成流程打通。Docker给我们最大的便利是可以快速地复制出一整套系统，方便几套环境同时进行自动化测试。所以我的关注点也比较偏实践方向。主要关注网络以及容器编排工具。
看这次DockerCon，感觉这几方面很快应该会有成熟的解决方案出来。既然有了标准和插件扩展机制，可以各厂商，各社区一起努力了，自己DIY也容易些。这个很让我激动。
另外看到田大师分享的Docker
networking方面的抽象，感觉非常符合分布式系统架构的抽象。各种语言的分布式框架可以在Docker之上大有作为，或者分布式的概念在Docker之上也逐渐标准化？
讨论之后是问答环节，几位专家回答了观众的提问。
Q & A
请问Docker什么时候可以放心用在生产环境？需要先解决什么关键问题？
田琪：如果是私有云环境，我觉得现在放在生产环境是ready的，网络和存储问题相对需要多考虑，网络这块国旗可以给大家分享下，国旗是网络方面的专家。
陈飞：就像田大师说的，Docker基本已经相对成熟了，对于计算型服务的话，应该没什么问题。有状态服务需要考虑一下存储方面的问题。Projet Orca是个什么项目？国旗能否进一步介绍下。
闫国旗：Project Orca是一套自上而下的整合方案，上层提供面向用户的GUI，下层管理Docker Engine/Docker Swarm/Docker Compose等等。功能上支持服务编排、查看集群或容器状态、日志等等，大部分功能基本上和一些Startup的产品一致了。Docker在当前市场前景以及应用价值如何？
闫国旗：就当前环境来说，基于Docker生态的工具链，能极大提高生产力，build & ship。在类似的研发生产流程中，都可以引入。对于IO Bound类的业务，个人认为Docker还是没有准备好的。当然这里也不主要是Docker的问题，首先对于底层来说，IO的隔离，目前做的还不够。因此也导致了上层的Docker无能为力，说到这里，感觉又引出了那个话题。容器的未来究竟是OS Container还是App Container?方向不同，就决定着技术的走向不同。我相信国内大多数的小伙伴是因为Docker Image的特性，才对Docker感兴趣的吧。“Image特性”，可以理解为Docker镜像。但是oveylayfs/dm的介入，会引入更多IO层面的问题。从现在的生态圈来看，大家目前都把方向瞄准了APP Container。
王渊命：国旗的这个问题好，我刚开始用docker的时候就比较迷茫，既然已经在云上了，云也支持镜像，支持API调度，为啥还要Docker？不过现在我觉得Docker应该是 App Container。
闫国旗：但在这个场景，所谓的OS env，貌似就没那么必要了。
陈飞：个人觉得应该是App Container，内核容器技术出来的时候本身目的就是为了解决App间隔离问题。但是因为容器本身创建速度快，所以也有当做OS Container的，但是OS Container要解决的网络、存储等问题，恰好又是内核容器技术不具备的，所以Docker肯定也是弱项。
闫国旗：OS Container的网络，可以引入SDN来解决，存储在本地是比较难做的。或许在未来，很可能OS和APP的界限不再那么明显。嘉宾们对国内Docker的前景怎么看？
闫国旗：现阶段Docker在国内落地还是蛮快的。从红包的案例，到京东的大促，都出现了Docker的身影。主要也是因为使用Docker没有太高的技术门槛。田大师前文提到“Docker项目现在的情况和当初的OpenStack有些相像”， 大家觉得Docker会不会也重蹈覆辙？
王渊命：Docker解决的问题没有OpenStack那么大，应该不会搞到OpenStack 那么复杂吧。
洪涛（爱抢购CTO）：OpenStack的不成功很大程度在于架构的复杂性上，想当年，要配置一个可用的OpenStack没有一周时间是完全搞不定的，光这点就导致许多想玩OpenStack的人被挡在了安装成功这条线以外。Docker很方便部署，我们现在就把它当做App的容器，Docker怎么做资源分配？我们的Docker中有个应用内存泄露，干了260g内存。不能单独分配给某个Docker固定的内存或者网络？cgroup可以限制内存和网络是吗？这个能否做动态修改？比如写程序调用他改。
刘斌：Docker网络分配应该是以daemon为单位的。就是cgroup修改参数就可以了。Docker本事没有此功能，但实现不难。想问问各位大师，现在Docker都应用在哪些组件上面？是只有无状态App，还是DB、Cache和存储全面应用了？
闫国旗：现在Docker的主要场景依然还是无状态App，像部分Cache也跑在了上面。一些IO密集型的应用，特别是磁盘IO，使用Docker是否合适？
闫国旗：IO Bound类业务，从现阶段的测试结果上看，不是特别理想。小规模的使用问题不大，如果是大平台业务就是慎重了。就问题8，你们测过？大概比裸机慢多少？
闫国旗：这个不是慢的问题，是隔离的问题。IO隔离，IOPS或IO带宽的SLA。
陈飞：另外应用的时候，版本选择也很重要，像我们就遇到docker1.5和1.6版本在CentOS 6.5上，导致Kernel Panic的问题。现在有什么比较好用的Docker管理工具？
闫国旗：Swarm/Compose都算是Docker管理工具。当然Orca更完善一点。想问下田大师和国旗，这次交流，国外同行对Docker未来发展趋势怎么看，还有哪些机会？
闫国旗：从交流的结果上来看，国外的公司使用Docker更多是为了降低“部分流程”上的成本。正是出发点如此，所以才会有那么多的Startup参与进来。对于容器技术，我们也可以理解为是一种虚拟化技术。因此很多公司也希望自己的产品能向这个方向有所延伸。
田琪：我觉得厂商跟Docker还是关心的不太一样的。
感谢刘世杰@猎聘网的记录与整理，臧秀涛@infoq的校对与发布，其他多位编辑组志愿者对本文亦有贡献。读者可以通过搜索“ArchNotes”或长按下面图片，关注“高可用架构”公众号，查看更多架构方面内容，获取通往架构师之路的宝贵经验。转载请注明来自“高可用架构（ArchNotes）”公众号。 
版权声明：本文为博主原创文章，未经博主允许不得转载。