【编者的话】大多数同学都是在技术角度来看待Docker平台，但是对于如何快速、良好、正确、健康的使用Docker/SaaS技术、运维维护却少有人提，到底搭建一个生产级的Docker平台需要结合哪些情况综合考虑、规划？本文将从运维的角度出发，结合真实的案例来讲述如何快速打造一个Docker平台。可能本文不是技术性的干货，但是提到的问题点或许都会成为平台路上的绊脚石。
我们公司目前的状态
大概从15年9月份开始正式启动Docker的Mesos平台；目前的进度是业务级应用的测试正在收尾（压力测试）。运维这一块一直是我来负责，踩的坑比较多，所以会在运维的角度来谈下如何高效、快速的搭建Docker平台。下面是目前我们用到的一些组件的架构图（细节的地方些许有些变动与不完善）。由于这套架构的每个组件基本都为开源，这里不做过多的细分、介绍。
为什么有这样的分享？
运维的角度不同，目前很多人都只关注技术本身，而非技术带来的价值；灾备方案等也很难完整的考虑，而且SRE/SLA等名词逐渐”火”了起来，所以我才思考打算分享这篇文档（某些地方写的还不是很完整，希望大家多多指出，给予谅解）。第一章：准备工作——背景（成本）
为什么要把成本放在第一位？想必没有老板会出于新技术而采用新技术，在意的肯定是技术带来的价值，远景上来看肯定是存在金钱的问题的，要么赚钱、要么省钱、要么就是名气带来的价值。O(∩_∩)O~当时打算大规模的使用Docker平台的时候，你便需要考虑成本这一块的问题了：
- 业务
- 技术
- 人员
- 时间
都知道Docker技术目前非常火，那么真的适不适合自己的公司，换句话说要说服自己的老板来做大换血，来做这种投入、方案；以上的四个是关联级的关系：
其中每一条都几乎与钱有莫大的关系。
适不适合目前的业务？优点在哪里？技术方案到底如何选型？到底投入多少人？投入多少时间成本？
业务
这里需要做好业务上的分析，使用PaaS平台很大一部分都是从资源使用率出发的，我们公司也不例外。比如我们公司现在的部署结构存在非常大的浪费（单用户独享多实例），从而造成每种实例可能达到上千个（这里本来我很想用一张图诠释我们业务的复杂度，最后放弃了，我们的业务我估计得用快10张PPT。囧），使用Docker资源管理平台：- 是可以趁机将业务做划分，多用户共享实例，将实例横向化，从而减小业务的复杂度，而这点我们这里诟病非常深！
- 是可以充分的利用资源。理论上成功之后，好处是非常之多:主机资源上的成本1年最起码能省下200W左右，业务部署结构不再那么复杂，运维、发布成本不再那么复杂、繁琐、可控性更高。
技术
技术方案理应也是从业务部署角度出发，现阶段是成熟的开源方便并“没有”，如何平稳的将现有的模式过渡到Docker平台之上便十分困难。现有的比较成熟、适合线上生产环境的个人认为是Mesos。也可能是个人了解的有限：目前还没了解哪些公司在成熟有效的使用Kubenetes、Swarm等一些别的平台方案。
技术方案综合对比的文章DockOne社区很多，这里就不做具体的介绍了。
我们这里采用Mesos最大的一个出发点是Docker采用host模式，避免了网络部分的技术投入。毕竟做网桥之类的方案，性能很快的出现各种瓶颈，毕竟很多方案都在试验阶段，之前阿里等也做过一些类似的分享，大家可以找来看一看。
除下方案，其他的方案就需要慎重考虑了，比较大的几点是运维方案，监控方案：这里涉及到扩容、异常响应等等。
人员
由于Mesos-Docker平台涉及的技术栈很广，人员到底要扩编到多少人，每个人的职责分工是什么？容易遇到的问题就是:- 不清楚每个组件需要投入多少人
- 人员离职
- 一些人搞完一些组件，然后就无事了
- other
同时由于Mesos这一套组件，编写的语言有多种，这里又要结合技术方案来选型，是否要针对特别的一些组件做二次开发等等，都需要考虑进去。而且一般上对这类人员的技能等要求也比较高，招人难度和成本也可想而知。
时间
这点应该是上边几个点都要考虑的，然后对比出成本。比如按照时间规划，这样来做是否达到了最初省钱的想法，这里是要有一个对比数据图。毕竟我们的目的是通过技术来减小成本。时间这一点需要附加的是要做好充分的规划，由于业务等外部因素很可能会对你本身的人员计划造成”动荡”。
第二章：规范
从事运维工作几年，见过很多这种情况，不管是什么工具、软件，看个Demo就拿出来用了，甚至还会做技术推广。然后最后这个东西出现一些功能、性能的问题的时候，把包袱丢给了运维or其他。所以在对技术方案做完大致路线后，第二件事就必须来做出相应的规范：
- 软件版本
- 升级、优化方案
- 异常处理职责
1. 软件版本
例如Mesos这一套，涉及到的组件有Mesos/Marathon/ZooKeeper/Consul/etcd/Registrator/Nginx/Docker/Logstash/Docker-Registry等等，这里这里区分类别来讨论。
开源未做二次开发类：
比如Mesos/ZooKeeper/Marathon/Consul/Nginx等，这些社区都会做比较规范的版本升级、迭代等，这类一般上功能都较为固定，”很少”需要做二次开发；
开源需要做二次开发类：
比如Logstash等（里面有一些我们特殊的组件），这里基本上每个公司都有自己的版本控制方案；
以上2种为比较广的一些方案，我这里更希望提到一些Docker相关的。因为这里的坑是最多的:
Docker版本：
Docker版本升级还是比较快的，但是到底要采用哪一种应该是要规范好的，这里应该比较容易，但是未固定版本容易造成蝴蝶效应；
Docker安装：
版本确认好，就是安装了。我们的做法是对Docker Storage、Registry等配置做了规范，然后将安装封RPM，统一由运维在主机初始化时装好；对于storage、网络初始化的干货文章很多，我这里就不细说，我们存储用的是”Device Mapper”。--如果不这样做，如果公司开发的小组很多，造成的结果将会”有一千个哈姆雷特”。运维成本可想而知。
Docker镜像：
除了Docker版本需要控制，镜像更需要控制。很多人习惯了docker pull ，但是结果是一千个人出现了一万种哈姆雷特，镜像中包含的问题也是多之又多。另外镜像中的软件版本更是情况复杂，easy start是简单了，后面的维护、监控就别提了，压根是没办法做的。
我们这里的做法是开发镜像统一为CentOS 7，针对开发语言Java，我们做了修改的JRE与JDK环境，以及对镜像里面Java内存的限制，以及一些常用工具的镜像。我们会有一套需求提交、交付的流程，这样就避免了开发到处的pull，什么问题都会出现的情况，出现的问题可以统一修复。
PS：很多人都会提出来有很多精简的镜像为什么不用？虽然容量小到几M，毕竟精简过，对镜像系统层的出来难度很大，如果在镜像上叠加，那么基础镜像一次小的切换将动辄”全身”做更换。然后我们在主机初始化阶段，会将基础镜像pull一次，这样的效果和精简镜像效果其实一样，每次都拉业务数据即可。
2. 升级、优化方案
升级的前提是安装要规范，然后是出于什么目的要升级（千万不能盲目跟着开源版本走），然后PAAS组件升级走OA，其实很多都可以动态升级，这一点比较简单；优化方案这里就比较杂了，难度也比较大。需要配合压力测试、监控来分析性能。里面涉及了很多组件的压测方案，这里就不一一列举了，这里与交付有着很大的关系。
PS：如果这里采用了一些Yum源来安装，建议将初始化的流程改掉，切记不要直接从官方等源上直接安装，这些地方版本更新后会造成你本地版本不一。所以建议没有Yum源的保存RPM包localinstall。
3. 异常处理
监控：监控这里目的是发现“何时变慢”；完善：这里的概念有点模糊，需要看场景来制定不同的方法策略。
PS：这里的方案会根据业务来制定，有点模糊。
第三章：交付
交付实际上就是上线的拍门砖，但是目前的情况是从PaaS到SaaS都没有明确的交付指标，也是我们目前遇到的瓶颈：测试过程不理想、风险性无法评估、需要测试的组件太多，没有完整的测试方案等等，所以方案基本上都在拍脑袋，耗时耗力。
PS：交付其实 1. 看产品重要程度；2. 看业务复杂程度；3. 看产品上线时间诉求；4. other，这些都决定着交付指标。
第四章：技术推广
如果说上边的都会在做方案的时候都能想到，但是技术推广很少有人想到。特别是开发部门众多的公司。怎么样合理的将技术、规范等等推广到各部门是极具挑战性的。实际操作中很容易遇到“写平台的看不起写业务代码的、我们很忙，暂时不需要这些“这种情况，造成沟通和技术推广的效果做的十分不好，费时费力。好处是现在的各种技术软文很多，不好的是hello world遍地都是，而且各有不同。如果先是出现了"哈姆雷特"，再去做规范，是根本来不及的。所以一个类似技术、平台的推广、规范的部门十分必要，当然这里面的一些能预见性的情况需要提前上层制定好。So：技术推广没做好反而是管理者的锅。总结
要做好Docker平台，不单单是技术达到相应的指标，就像做汽车，发动机做好了，其他零部件也必须要跟上，不然车永远是没办法安心上路的。但是由于时间、人力、成本等的把控，又需要快速的上线，就要权衡技术方案和运维方便的成本，将能预见的一些事情提前规划好，才能安稳的渡过上线高问题爆发期，让平台平稳的过渡到稳定、健康的状态。
毕竟，技术永远都在为业务服务。
Q&A
Q：您好，请问一下你们的监控采用的是什么方案？发现“变慢”后的动作是自动的还是需要人工介入的呢？Q：请问，你们环境的存储用的是本机存储还是分布式存储？
A：1、我们PaaS上的SaaS业务的框架，由平台部统一提供，框架本身集成了健康检查（存活状态，响应时间）；2、运维开发小组会针对于这些有一套监控；3、另外针对于变慢，我们有Zabbix、日志收集、trace系统统一来做数据展示、分析、比对报警。
Q：请问Docker 你们是如何做鉴权的？即控制哪些人可以使用Docker Registry 哪些又可执行push等操作？怎么实现的？谢谢！
A：由于我们的业务直接走的RDS，存在本地的只有日志，我们的日志是挂载本地，规范了存放的格式，统一收走来做日志分析、trace问题排查系统等。
Q：可以讲讲在CentOS 7跑Java的时候，对JRE 和JDK做了哪些修改吗？跑Java应用按理说JRE就够用了么？
A：1、首先鉴权分为业务层和PaaS层，业务层我们配套了框架及API GATEWAY/认证系统等来做业务上的鉴权；2、Docker层的我们这里做的比较简单：我们的Registry只做了简单的鉴权，由于我们只为内网服务，所以otheruser都具有pull权限，我们的push操作只有单独的几台机器、操作人员可以通过Jenkins操作（这里我们做了封装开发）。
Q：对于Java应用，如何设置DataSource？我的意思的测试环境和生产，如果用同一个image？
A：理论上JRE就够了，但是不排除一些其他需要javac等的嘛 O(∩_∩)O~；另外修改的最重要的算是内存细分的限制了（看业务要求，我们对单个容器使用的内存严格限制），以及一些第三方的APM性能监控插件。
Q：请问整个项目中的大概成本比例呢？如何定义各种成本？
A：针对于不同的环境，我们在用封装过的Jenkins来打相应的镜像，也就是不同环境的镜像在build的时候的操作，其实不一样。针对于环境信息的配置放在etcd中。
Q：请问，使用host模式，你们目前怎么实现对端口的分配控制？
A：这点比较难说，看公司的态度吧，比如百度和腾讯对于新技术的投入比例就远远不同。
以上内容根据2016年5月31日晚微信群分享内容整理。分享人陈延宗，杭州数云运维工程师，工作内容比较多、杂：Docker/基础服务/SRE等等。DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesz，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。
A：端口是由Marathon随机分配的，不过可以针对端口段来做控制。一个机器可以开几千个端口，但是容器就开不了那么多啦。
有疑问加站长微信联系（非本文作者）
