在2017游戏行业全球同服和安全攻防技术沙龙上，来自心动网络的吴涵分享了《浅谈docker业务运维》。他主要从运维职责（部署阶段、运行阶段）、潜在的问题、选择docker的原因、docker集群、docker监控、docker未来六个方面以运维人员的角度分享了docker的使用经验。
以下内容根据直播视频整理而成。
大家对于docker已经不陌生了，docker产品在很多领域都比较火。心动网络从2015年开始接触docker，发现docker的整个产品模式比较适合游戏领域公司的快速发展模式，包括打包部署和发布都契合需求。
以前（比较大众的时期），运维同事都需要做一些部署阶段的工作，比如系统安装、编译环境、代码上传、执行编译、启动脚本。这些工作都需要运维人员在线上进行大量的手动操作，中间会出现许多问题需要人工进行定位和排查。
在部署完成之后，运维人员需要做服务运行阶段的工作和维护，包括配置更新、代码更新、系统更新、监控采集、故障处理。这些都是在整个运行时期，运维人员需要时刻关注的问题。
在接触docker之前，心动网络也是以传统模式来部署业务和维护业务的，也遇到很多潜在问题。比如：编译环境迭代更新导致库版本升级使编译出现兼容性问题；在机器数量比较庞大的情况下去上传代码，导致代码有泄露的风险；开发部、安装部的版本出现问题，导致代码编译无法通过；在编译完成之后需要把整个服务打包，需要写启动脚本使其每次都能自己运行；代码管理方面，用到svn或者git仓库管理工具，有办法去切换版本，但是发布二进制服务的时候需要很麻烦的做很多标签来定位服务对应的维护版本；服务运行之后，监控服务的运行状态比较困难；做大量工作之后发现最终高投入换来了低效率。
在内部的测试环境使用docker之后，发现docker有很多优势：一次打包，各处运行；编译和运行环境分离；服务端只需安装docker运行组件；docker镜像标签用作版本管理；api调度管理容器，实时监控容器的运行状态；多种语言支持的sdk，可以与业务深度结合；部署模式统一，易于维护。使用docker之后，大幅减少了在部署和监控上的精力，把更多的时间花在对接更高级的业务运行模式上。底层的很多东西直接使用docker，时间成本大幅减少。
在机器节点非常庞大的情况下，由于docker是单机的服务，所以会出现一些问题。心动网络的测试环境都是以小量机器为规模，不是特别注重节点之间的管理，但是上线之后，在庞大的集群（以百、千为计量单位）中需要一个能够统一管理的模式，即需要docker集群模式。
在对比之后，最终选择了docker内置的集群模式docker swarm。swarm在docker1.12之前是以独立进程的方式运行的。在docker1.12之后，官方把swarm集群模式集成在docker engine中。swarm采用去中心化设计，分为很多角色，比如manager和worker，在各个节点之间的通信都是ts加密的，可以保障一定的通信安全。swarm支持服务编排，可以把多个服务打包成一个application来发布，比如采用web+db的模式。可伸缩性是指，比如定义集群里的一个启动数量为10，swarm会根据预定的启动值以自动调度的策略来保证整个集群的预设值能够始终满足需求。swarm具有自愈能力，很多服务是无状态的或者微服务，在一个集群里会有很多的容器，其实本地是不留存信息的，而是集中化的存在缓存或者数据库中，这些容器可以看作是一个runtime环境，只负责处理不负责存储，自愈能力是针对这些服务出现crash之后可以自动的在其他可用节点上再去启动新的容器来弥补已经crash的容器，保证整个集群里的数量符合预期值。swarm支持滚动更新，当滚动失败或者更新失败之后，需要进行回退，但是有些回退的操作比较复杂，需要回退所有的配置文件，基于docker的滚动更新是比较方便的，因为是作为容器来发布，更新失败后，只要上一个版本的容器还存在就可以无缝切换过来，整个runtime的环境可以保证一致。
关于docker监控，官方一直没有给出一个比较好的方法，反而是很多第三方的开源项目在实现docker监控。此时就需要对docker api的调度非常熟悉，但是很多时候大家只是想能够很快的起一个服务能够调用docker的api把数据存储在自己的存储中，通过前端的页面转接出来。
docker本地cli有docker state指令，可以关注比较通用的监控参数，包括cpu、内存、io使用率、网络使用率等。在有一定研发能力的基础上，可以考虑使用docker remote
api自己去抓监控数据，通过某种方式展现出来。google cadvisor是比较成熟的第三方项目，可以和docker无缝贴合，能够监控单台物理机上面所有容器的状态，其本身是不存储数据的，但是支持加载后端的存储把数据写到存储中。shipyard是docker的一个核心成员开发的，带ui，本身不是做监控的，是作为docker front-end web前端去管理docker，也包含了对docker api的调用，可以作为一个简单的监控工具来使用。
docker并不是完美无缺的，在以下方面期待改进：docker对高密度写入场景并不是特别友好，不是作为存储直接写入数据到容器中，还需要通过加载第三方的volume或者本地的主机目录关联到容器里面来实现，对数据库写入优化不适合；docker
daemon api是中心化设计的，使用时如果docker daemon发生crash，会导致所有的api不可用，此时不管通过命令行还是remote api都不能管理上面的容器，只能非常麻烦的重启docker daemon，造成业务的闪断或者各种各样的问题；api是完全没有验证的，只要抓到api地址就可以通过特定的协议交互，在内网环境问题不大，但是在外网开放api的风险成本比较高。