本文版权所有是InfoQ高效运维群,转载请到公众号转

公众号戳:infoqops

源起晓梦的一条链接http://card.weibo.com/article/h5/s#cid=1001603839871499289201&from=1052893010&wm=3333_2001&ip=10.209.17.50

这是一篇讲docker缺点的文章,其主要担忧是base img出现bug后将会导致整个docker image进行重构,这将会给运维人员带来巨大的运维压力,其次是由于运行的版本过多,运维人员不能很好的控制风险。

我的观点稍有不同,docker的作用是能让运维人员清楚的知道开发人员的环境,以便部署的时候比较容易定义版本问题,docker节约的是容灾资源的共享,根据1:1:1更健康的观点,1份运行资源,1份高峰资源,1份容灾资源。对于base bug我个人确实也挺头大的。。。

萧田国@触控则认为docker的时代会比预想中更快的到来,现实存在的细节问题可以不必纠结。

刘鹏@浙江移动在他们的业务中用dokcer使用了两组核心集群,并引入了1/3的流量,效果拔群。但他也表示了这也引入了监控和运维管理的一些问题。虚拟化已经在屋里机上多了一层,docker又在云OS上加了一层,从系统层级说复杂了很多,面临一系列的服务端口管理和网络问题。(我想说在后续docker版本支持ipv6,端口资源可以省心了)。据他透露他们在某业务上跑了快一年了,没出过大事。高可用在应用和部署架构支持,可以快速进行服务能力切换。不过分追求单个Contanier的能力及稳定性,总体思路是快速failover,踢出问题节点,由架构层面进行保障。 理论上和监控配套进行可以对问题节点的判断和自动踢出。 带着环境迁移,Scale out确实方便,前提是应用支持。 一年出了2-3次小问题,可以通过参数优化和版本升级解决。 往往是一台主机上的容器会有不同程度问题。 他建议根据宿主机的情况轻量,狼群攻击式部署。 部署呢则部署到干净的宿主机上,用在资源池中。

晓梦表示部署的话装干净的机器用docker干嘛(想想似乎也对!)。他表示主要用的是隔离性。

诸超@vip:狭义的cloud就是解决无状态的deploy和scaling问题。

晓梦:用传统办法puppet解决扩容的问题,也可以达到效果。

唐云吉@银联@魔都 运维云化后,管理和监控是个难点

诸超@vip 提问: 这里有多少人关注microservice

关胜@新浪 :1.不管有docker,无docker,puppet解决的是配置管理的事情;2.集群的管理,包括扩容都是需要通过集群管理系统去做的,一般集群底层都有一个任务调度的组件;3.对于环境问题:无论干净还是线上机器,对于无状态的app,包括web,rpc,前面都会有7层或者配置服务,高可用都是可以做的。docker解决的实例问题,本身无调度功能,CoreOS会有调度功能;4.docker出现,是的微服务架构更容易,但是这不是充分必要条件。微服务更多的是业务架构与拆分。相对是比较难的。

晓梦 : 这里讨论的是扩容问题。。。。 单纯冲扩容这个角度讲,这俩都能做,一个简单一个容易。 用docker还是一个负责的操作啊,而且带来的管理成本,就如文章里说的那样也是很高的。要不docker的生态圈也不能那么繁荣。

关胜@新浪 扩容是一个复杂的操作,并不是说puppet不能做,是结合多个工具才能完成的

刘鹏@浙江移动 : 我倒是任务所有的动态扩缩容难度系数高,只要涉及到服务的弹性扩展,必然涉及到一系列的配套组件。

诸超@vip kv系统相对容易一些

关胜@新浪 kv系统扩缩容要做的好,得有好的中间件货proxy,需要解决状态问题。没有这些的话,就是配置硬编码,或者配置中心,我觉得还是蛮复杂的。

关胜@新浪:像我们对于缓存的使用,已经多层多级,对于slave的扩容相对简单 。对于master的扩容,还会需要去预热。步骤还是比较多的。当然还是要看你的业务场景是否复杂。

至此,对于docker的使用,还是得看业务架构,我自己所部署的docker都只是环境,运行代码全部是启动时挂载,docker环境使用Dockerfile进行git版本管理,这样连同整个项目都可以以脚本化版本化进行控制。当然docker是相当稳定的,技术都是老的,不过对于上文提到的base bug,我觉得还是我个人的方案比较优良,仅仅对环境重构成本小,脚本化后其实运维人员的工作量并不多,倒是网络传输环境的耗资严重。