站在运维的角度讲如何打造一个 Docker-Mesos 平台

阅读 735
收藏 17
2016-06-03
原文链接:dockone.io

【编者的话】大多数同学都是在技术角度来看待Docker平台,但是对于如何快速、良好、正确、健康的使用Docker/SaaS技术、运维维护却少有人提,到底搭建一个生产级的Docker平台需要结合哪些情况综合考虑、规划?本文将从运维的角度出发,结合真实的案例来讲述如何快速打造一个Docker平台。可能本文不是技术性的干货,但是提到的问题点或许都会成为平台路上的绊脚石。

我们公司目前的状态

大概从15年9月份开始正式启动Docker的Mesos平台;目前的进度是业务级应用的测试正在收尾(压力测试)。运维这一块一直是我来负责,踩的坑比较多,所以会在运维的角度来谈下如何高效、快速的搭建Docker平台。

下面是目前我们用到的一些组件的架构图(细节的地方些许有些变动与不完善)。由于这套架构的每个组件基本都为开源,这里不做过多的细分、介绍。

为什么有这样的分享?

运维的角度不同,目前很多人都只关注技术本身,而非技术带来的价值;灾备方案等也很难完整的考虑,而且SRE/SLA等名词逐渐”火”了起来,所以我才思考打算分享这篇文档(某些地方写的还不是很完整,希望大家多多指出,给予谅解)。

第一章:准备工作——背景(成本)

为什么要把成本放在第一位?想必没有老板会出于新技术而采用新技术,在意的肯定是技术带来的价值,远景上来看肯定是存在金钱的问题的,要么赚钱、要么省钱、要么就是名气带来的价值。O(∩_∩)O~

当时打算大规模的使用Docker平台的时候,你便需要考虑成本这一块的问题了:
  1. 业务
  2. 技术
  3. 人员
  4. 时间


都知道Docker技术目前非常火,那么真的适不适合自己的公司,换句话说要说服自己的老板来做大换血,来做这种投入、方案;以上的四个是关联级的关系:


适不适合目前的业务?优点在哪里?技术方案到底如何选型?到底投入多少人?投入多少时间成本?
其中每一条都几乎与钱有莫大的关系。

业务

这里需要做好业务上的分析,使用PaaS平台很大一部分都是从资源使用率出发的,我们公司也不例外。比如我们公司现在的部署结构存在非常大的浪费(单用户独享多实例),从而造成每种实例可能达到上千个(这里本来我很想用一张图诠释我们业务的复杂度,最后放弃了,我们的业务我估计得用快10张PPT。囧),使用Docker资源管理平台:
  1. 是可以趁机将业务做划分,多用户共享实例,将实例横向化,从而减小业务的复杂度,而这点我们这里诟病非常深!
  2. 是可以充分的利用资源。理论上成功之后,好处是非常之多:主机资源上的成本1年最起码能省下200W左右,业务部署结构不再那么复杂,运维、发布成本不再那么复杂、繁琐、可控性更高。


技术

技术方案理应也是从业务部署角度出发,现阶段是成熟的开源方便并“没有”,如何平稳的将现有的模式过渡到Docker平台之上便十分困难。

现有的比较成熟、适合线上生产环境的个人认为是Mesos。也可能是个人了解的有限:目前还没了解哪些公司在成熟有效的使用Kubenetes、Swarm等一些别的平台方案。


我们这里采用Mesos最大的一个出发点是Docker采用host模式,避免了网络部分的技术投入。毕竟做网桥之类的方案,性能很快的出现各种瓶颈,毕竟很多方案都在试验阶段,之前阿里等也做过一些类似的分享,大家可以找来看一看。
技术方案综合对比的文章DockOne社区很多,这里就不做具体的介绍了。

除下方案,其他的方案就需要慎重考虑了,比较大的几点是运维方案,监控方案:这里涉及到扩容、异常响应等等。

人员

由于Mesos-Docker平台涉及的技术栈很广,人员到底要扩编到多少人,每个人的职责分工是什么?容易遇到的问题就是:
  1. 不清楚每个组件需要投入多少人
  2. 人员离职
  3. 一些人搞完一些组件,然后就无事了
  4. other


同时由于Mesos这一套组件,编写的语言有多种,这里又要结合技术方案来选型,是否要针对特别的一些组件做二次开发等等,都需要考虑进去。而且一般上对这类人员的技能等要求也比较高,招人难度和成本也可想而知。

时间

这点应该是上边几个点都要考虑的,然后对比出成本。比如按照时间规划,这样来做是否达到了最初省钱的想法,这里是要有一个对比数据图。毕竟我们的目的是通过技术来减小成本。

时间这一点需要附加的是要做好充分的规划,由于业务等外部因素很可能会对你本身的人员计划造成”动荡”。

第二章:规范

从事运维工作几年,见过很多这种情况,不管是什么工具、软件,看个Demo就拿出来用了,甚至还会做技术推广。然后最后这个东西出现一些功能、性能的问题的时候,把包袱丢给了运维or其他。

所以在对技术方案做完大致路线后,第二件事就必须来做出相应的规范:
  1. 软件版本
  2. 升级、优化方案
  3. 异常处理职责


1. 软件版本

例如Mesos这一套,涉及到的组件有Mesos/Marathon/ZooKeeper/Consul/etcd/Registrator/Nginx/Docker/Logstash/Docker-Registry等等,这里这里区分类别来讨论。
  1. 开源未做二次开发类:
    比如Mesos/ZooKeeper/Marathon/Consul/Nginx等,这些社区都会做比较规范的版本升级、迭代等,这类一般上功能都较为固定,”很少”需要做二次开发;
  2. 开源需要做二次开发类:
    比如Logstash等(里面有一些我们特殊的组件),这里基本上每个公司都有自己的版本控制方案;


以上2种为比较广的一些方案,我这里更希望提到一些Docker相关的。因为这里的坑是最多的:
  1. Docker版本:
    Docker版本升级还是比较快的,但是到底要采用哪一种应该是要规范好的,这里应该比较容易,但是未固定版本容易造成蝴蝶效应;
  2. Docker安装:
    版本确认好,就是安装了。我们的做法是对Docker Storage、Registry等配置做了规范,然后将安装封RPM,统一由运维在主机初始化时装好;对于storage、网络初始化的干货文章很多,我这里就不细说,我们存储用的是”Device Mapper”。--如果不这样做,如果公司开发的小组很多,造成的结果将会”有一千个哈姆雷特”。运维成本可想而知。
  3. 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:您好,请问一下你们的监控采用的是什么方案?发现“变慢”后的动作是自动的还是需要人工介入的呢?

A:1、我们PaaS上的SaaS业务的框架,由平台部统一提供,框架本身集成了健康检查(存活状态,响应时间);2、运维开发小组会针对于这些有一套监控;3、另外针对于变慢,我们有Zabbix、日志收集、trace系统统一来做数据展示、分析、比对报警。
Q:请问,你们环境的存储用的是本机存储还是分布式存储?

A:由于我们的业务直接走的RDS,存在本地的只有日志,我们的日志是挂载本地,规范了存放的格式,统一收走来做日志分析、trace问题排查系统等。
Q:请问Docker 你们是如何做鉴权的?即控制哪些人可以使用Docker Registry 哪些又可执行push等操作?怎么实现的?谢谢!

A:1、首先鉴权分为业务层和PaaS层,业务层我们配套了框架及API GATEWAY/认证系统等来做业务上的鉴权;2、Docker层的我们这里做的比较简单:我们的Registry只做了简单的鉴权,由于我们只为内网服务,所以otheruser都具有pull权限,我们的push操作只有单独的几台机器、操作人员可以通过Jenkins操作(这里我们做了封装开发)。
Q:可以讲讲在CentOS 7跑Java的时候,对JRE 和JDK做了哪些修改吗?跑Java应用按理说JRE就够用了么?

A:理论上JRE就够了,但是不排除一些其他需要javac等的嘛 O(∩_∩)O~;另外修改的最重要的算是内存细分的限制了(看业务要求,我们对单个容器使用的内存严格限制),以及一些第三方的APM性能监控插件。
Q:对于Java应用,如何设置DataSource?我的意思的测试环境和生产,如果用同一个image?

A:针对于不同的环境,我们在用封装过的Jenkins来打相应的镜像,也就是不同环境的镜像在build的时候的操作,其实不一样。针对于环境信息的配置放在etcd中。
Q:请问整个项目中的大概成本比例呢?如何定义各种成本?

A:这点比较难说,看公司的态度吧,比如百度和腾讯对于新技术的投入比例就远远不同。
Q:请问,使用host模式,你们目前怎么实现对端口的分配控制?

A:端口是由Marathon随机分配的,不过可以针对端口段来做控制。一个机器可以开几千个端口,但是容器就开不了那么多啦。
以上内容根据2016年5月31日晚微信群分享内容整理。分享人陈延宗,杭州数云运维工程师,工作内容比较多、杂:Docker/基础服务/SRE等等。DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

评论