Docker技术族的生态，趋势，市场 @高效运维

Docker技术族的生态，趋势，市场 @高效运维

本文根据高效运维系列群「运维讲坛」的嘉宾分享整理而成。运维讲坛，邀请国内运维领域优秀技术专家作为分享嘉宾，其中线上分享每周一次，线下沙龙活动每月一次。

编辑

徐文慧@21v-北京（内容收集）老边（文章整理 & 发布）萧田国（审核）

嘉宾介绍

肖德时，北京数人科技有限公司CTO，负责云计算的研发及架构设计工作。关注领域包括Docker，Mesos集群， 云计算等领域。所在城市在北京。之前为红帽Engineering Service部门内部工具组Team Leader。

主题简介

今天的主题是《Docker技术族的生态、趋势、市场》。本来这个话题就是一个全局的话题，按照一般的讲法，也就是讲讲一些不痛不痒的统计数据，然后给大家展望一下Docker的未来，然后让大家紧跟时代的潮流拥抱Docker技术。

但这些都是美好的愿景，和现实是有差距的。我相信只有把这块“遮羞”幕布撕开，你才能体会到Docker带来 的变革和趋势。随之带来的市场才是一个清晰的市场，不然大家都还在原地转圈，寻找自己原来的位置。其实这种错位感直接导致大家对运维的忽视，总期盼什么牛掰的技术就万事大吉了。

所以总要有人来点破这个迷局，所谓不破不立大概就是这个道理。那么Docker对运维的未来意思，就是全方位的替换运维现有的工作内容。就是这么直接，完全没有余地的替换。

主题内容：

Docker是什么Docker核心技术Docker生态圈Docker趋势Docker市场

1、Docker是什么

这是在国内介绍Docker最普遍的一种说法。但对DevOps来说怎么看Docker呢?

其实用两个字就可以给运维讲清楚，那就是Docker最大的好处是隔离。Docker是程序员发明的工具，它让程序员感到最疯狂的事情就是不用操心环境了。可以随便配置，随便裁剪。

当他把这个消息传递给运维人员的耳朵里后，其实从运维的角度来说，其实一点意义都没有。因为从以前的技术来说，还是会有更复杂的环境需要我运维来管理、维护。忽略了Docker对运维的颠覆性创新：构建一整套无状态的基础设施。

这张图是Docker公司原生的图。很多人都是介绍它的好处，比如效率提高了。资源复用了，容易管理了。但这里的“很多人”全部都是开发人员。

运维人员要知道的是，这个东西的目的就是不需要运维。它是一个可控的分布式模式，加上合适的分布式系统就能完成管理。日常运维的工作完全可以由开发来完成也可以。

LXC/Libcontainer/Rocket engine目前就是标准化一个“包”。以前我们的包可以千奇百怪，等上规模之后，就是解决不了依赖。比如在Linux，你不可能同时安装两套pyhton，要改名字。

很麻烦。当你上了Docker，这些问题就解决了。这是本质的解决，和之前的方式不一样的地方。

Docker核心是一个操作系统级虚拟化方法，但核心的技术是利用Linux Kernel的隔离性来达到需要的虚拟化：隔离性、可配 额/可度量、便携性、安全性。

隔离性: Linux Namespace(ns)每个用户实例之间相互隔离, 互不影响。一般的硬件虚拟化方法给出的方法是VM,而Docker给出的方法是container,更细一点 讲就是kernel namespace。其中pid、net、ipc、mnt、uts、user等 namespace将container的进程、网络、消息、文件系统、UTS(“UNIX Time-sharing System”)和用户空间隔离开。

如果这些都实现了，很多运维的工作就真的不需要干了。但往往现实就是那么骨干，实话实说，更本没有解决。目前没有一家有SLA的企业敢直接上Docker解决生产问题。

2、Docker核心技术

Docker的核心技术是什么，从目前的项目中，docker，libcontainer，swarm, compose, kitematic, distribution全部都是开源的，而且我发现最先试用Docker技术的运维人员比开发多。

这真的非常有意思。开发者用Docker的目的就是取代运维，运维用Docker的目的其实就是远离那些重复性的工作。这里运维开始发生变革。

运维不能回避的问题就是Docker的易用性确实给实施带来了便利。但目前的Docker的不健全性，直接导致系统比原来的复杂度更高了。这里面的“技术含量”增加了。

但请大家不要忽略Docker的发展速度，因为它的目的就是替代运维，所以它逼着运维走向DevOps,在Docker的核心技术里面，你会发现它对安全性这一块是完全不管的，它直接把它丢给了Linux Kernel。

从这一块的设计来看，容器本身也是有弱点的。所以，出现类如Intel的Clear Container，就是基于qemu之上

3、Docker生态圈

我把整个Docker的技术都堆积出来，大家就可以看到这就是一个开发平台。和运维的生态圈关系最大的就是你手上的工具链都开始在往Docker上靠，最终，所以的工具都会成为这个生态圈的一员。

现在的科技界，是真正对开发者纵容的时代。当然我们也可以认为运维也是开发者。所以判断这个生态圈最重要的指标就是开发者。Docker宣传的这么流行，其实最终的实施者是运维人员。

这里就产生了一个怪圈：开发者鼓吹Docker好，但都不去动手真正部署。运维者爱好Docker，是大胆去尝试Docker的第一人。相信最终的结果就是开发和运维要产生结合。

4、Docker趋势

这是容器的关键路径，最重要的看点就是原来的容器做法是给Kernel打Patch，慢慢变成只是利用现有Kernel的特性去支持容器技术。

我把全球的容器生态圈也列出来，业界大佬：谷歌，amazon，微软在支持容器。两大OS发行版也在支持Docker。这个真的是大厂商的盲从，觉对的盲从。因为这个技术完全是“最没有技术含量”的技术。但历史就是这样，只要是易用的技术，越容易成功。

大家看一下这张图，有超过35%人计划用Docker，而其他工具将会被逐渐取代。因为Docker使用起来太简单了。

5、Docker市场

业界主流的云都开始支持Docker，但之前提到过Docker的核心技术还不过关。所有的坑还是由当前的运维来抗着。

谢谢大家的捧场，撕开Docker的华丽面纱，很多人不愿点破，今天破局给大家带来一些：决定docker成败的我觉得还是兼容，稳定，安全，这三个方面。但是我认为在生产环境大规模应用的路还很漫长。docker能有自己的一席之地，但无法代替VM，docker将成为部署多元化的选择。

谢谢大家。本次分享内容完毕。

Q&A环节

问题1：Docker容器技术对当前运维带来的挑战是什么？

答：主要的挑战是全面的替代当前运维的很多工作，但Docker的不健全性，又给运维人员带来更大的灾难。 目前运维人员也是非常希望能把这些基础工作用Docker替代的。所以目前的挑战就是要随时应对不可预估的 新问题。

问题2：如果将现有的虚拟机迁移到Docker，需要注意哪些？

答：现有的虚拟机的应用程序可以直接使用Docker打包隔离部署。在具体实施的过程中，肯定需要一个集群 平台来支持。目前这方面有mesos，k8s,swarm等等一系列的工具。注意的点就是需要做大量测试。

问题3：在线上业务怎么针对docker进行持续监控?

答：cadvisor可以查指标。还有别忘了Docker的rest API

问题4：在线上业务怎么用docker做持续化代码发布如何做?

答：例子：主要是使用jenkins的CI集成你的git repo，然后在你的代码里写一个Dockerfile，这样当 提交代码的时候，会trigger一个build，然后docker build去打包。

问题5、所谓的隔离，具体是指那些，是彻底的资源隔离吗

答：隔离是指Linux namespace，MNT、PID、NET、IPC、USER、UTS。技术上彻底的隔离，和虚拟化的隔离不一样，但隔离的很好。

问题6：一般新技术出现到成熟对行业产生颠覆都需要漫长的时间，很多很好的技术没能坚持到最后，go语言和docker都太新了，您认为哪些因素会支撑docker迎来大规模应用的曙光，现在除了研发测试环境以外还有哪些经典的应用场景？

答：其实Docker只是一个对外的技术。在容器技术上来讲Google已经在使用了。Docker虽然很新，但特性加的非常快。并且我们可爱的运维工程师在不断的尝试使用Docker，这是很可怕的诱惑。对于场景来说，应该 是成为下一代的部署的标准。它的好处就是把一些基础工作分给开发完成。让运维做更高级的事情。

问题7:我是初学docker的小白，平时接触centos较多，所以就在centos上练习，我发现至少要在centos6.6之上的版本，最好是centos7才行。请问大家平时用什么环境比较多？关于自学的材料或者相关书籍有啥推荐吗？多谢！

答：可以多参与运维群的讨论。

问题8，如果现在再来选，k8s和mesos你选哪个，why？

答：目前我所在的公司在做mesos的企业化支持，我肯定会选mesos。但其实这两者都非常优秀。目前最大的问题 是Docker还有很多坑。这个需要时间来等待。或者我们直接去贡献代码解决它。

问题9，如果想在运维中使用docker,应该如何下手

答：运维工作应该真正的体现价值。以往开发者把很多没有价值的工作让运维来做。这不对了。现在我们可以让 开发者直接打包成Docker。运维来考虑集群部署和架构设计、容量规划等高级话题。

问题10，docker中网络高可用，比如bonding，都在host层面实现？

答：docker的网络一定要SDN，目前docker有一个libnetwork把网络支持当成插件。之后网络SDN的支持可以 通过插件来实现。就不用host层了。等1.7出来后，你就可以上ovs bridge了。目前只能忍一下。

群友交流热议

Henry：docker 无法在Vmware中直接使用吧，已经Vmware虚拟化的环境在centos上使用？效率上影响如何？

张舵主：用应该是可以吧。效率不晓得。

北北：效率很差，我已经干过了。

明矾：很难有大发展。

张舵主：哦，不太清纯正是的生产环境是不是可以，比如大型的虚拟化平台。自己练习我还是windows+vmware+centos+docker这样的。这样没啥问题吧？有和我一样的吗？我是不是走弯路了啊！求指导。

北北：直接物理机跑吧。

唐一：练习环境这样搭配没有不合理啊。

明矾：大道至简，花哨的都是昙花。

Henry：感觉生产系统是不是centos’+docker，如果在云上怎么用？

张舵主：嗯，我最近就是这样练习，然后参考gitbook发布的《docker 从入门到实践》这本书。之前我在项目上遇到的情况是在一个系统下安装两个网管软件，这两个软件要求的ruby版本还有openssl版本都不一样，很难往一块弄。我的目标是通过docker，把一个软包隔离。目前还在自己研究当中。

空空：现在大多是六，七很少用，在六上用有什么局限？

张舵主：是的docker对内核有要求，centos要在6.6以上。而且不能直接yum安装。centos7可以直接yum安装了。

北北：我就用的7.1

张舵主：centos6.6要先搞定Epel源，然后再yum安装。

北北：直接7.1吧，反正centos不会会退了。

张舵主：嗯，确实是。不过现在生产环境用centos7的不多。

北北：建议还是用images玩，centos伤不起，我一个32g内存的机器，都跑不到12个centos。

如何一起愉快地发展

这是一个新的时代！每个人都有自己的声音，值得被尊重，并且有机会被尊重。

高效运维系列微信群于2015年4月底创建，已然成为国内高端运维圈子。现有会员800余名，其中运维总监及以上级别会员300多名。主力成员分布甚广，不仅来自互联网大厂，更有包括移动、银联、农业等各产业朋友。

来吧朋友，共襄盛举。