运维群Docker讨论
本文版权所有是InfoQ高效运维群，转载请到公众号转
公众号戳：infoqops
这是一篇讲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，我觉得还是我个人的方案比较优良，仅仅对环境重构成本小，脚本化后其实运维人员的工作量并不多，倒是网络传输环境的耗资严重。