转载

站在运维的角度讲如何打造一个docker->mesos平台

摘要

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

Body

我们公司目前的状态

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

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

站在运维的角度讲如何打造一个docker->mesos平台

为什么有这样的分享?

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

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

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

当时打算大规模的使用docker平台的时候,你便需要考虑成本这一块的问题了:

  1. 业务
  2. 技术
  3. 人员
  4. 时间

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

适不适合目前的业务?优点在哪里?技术方案到底如何选型?到底投入多少人?投入多少时间成本?

其中每一条都几乎与钱有莫大的关系。

业务

这里需要做好业务上的分析,使用PAAS平台很大一部分都是从资源使用率出发的,我们公司也不例外。比如我们公司现在的部署结构存在非常大的浪费(单用户独享多实例),从而造成每种实例可能达到上千个(这里本来我很想用一张图诠释我们业务的复杂度,最后放弃了,我们的业务我估计得用快10张PPT。囧),使用docker资源管理平台

①是可以趁机将业务做划分,多用户共享实例,将实例横向化,从而减小业务的复杂度,而这点我们这里诟病非常深!

②是可以充分的利用资源。理论上成功之后,好处是非常之多:主机资源上的成本1年最起码能省下200W左右,业务部署结构不再那么复杂,运维、发布成本不再那么复杂、繁琐、可控性更高。

技术

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

现有的比较成熟、适合线上生产环境的个人认为是mesos。也可能是个人了解的有限:目前还没了解哪些公司在成熟有效的使用k8s、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等等,这里这里区分类别来讨论。

开源未做二次开发类:

比如mesos/zk/marathon/consul/nginx等,这些社区都会做比较规范的版本升级、迭代等,这类一般上功能都较为固定,”很少”需要做二次开发;

开源需要做二次开发类:

比如logstash等(里面有一些我们特殊的组件),这里基本上每个公司都有自己的版本控制方案;

以上2种为比较广的一些方案,我这里更希望提到一些docker相关的。

因为这里的坑是最多的:

①. docker版本:

docker版本升级还是比较快的,但是到底要采用哪一种应该是要规范好的,这里应该比较容易,但是未固定版本容易造成蝴蝶效应;

②、docker安装:

版本确认好,就是安装了。我们的做法是对docker storage、registry等配置做了规范,然后将安装封rpm,统一由运维在主机初始化时装好;对于storage、网络初始化的干货文章很多,我这里就不细说,我们存储用的是”Device Mapper”。--如果不这样做,如果公司开发的小组很多,造成的结果将会”有一千个哈姆雷特”。运维成本可想而知。

③、docker镜像:

除了docker版本需要控制,镜像更需要控制。很多人习惯了docker pull ,但是结果是一千个人出现了一万种哈姆雷特,镜像中包含的问题也是多之又多。另外镜像中的软件版本更是情况复杂,easy start是简单了,后面的维护、监控就别提了,压根是没办法做的。

我们这里的做法是开发镜像统一为centos7,针对开发语言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平台,不单单是技术达到相应的指标,就像做汽车,发动机做好了,其他零部件也必须要跟上,不然车永远是没办法安心上路的。

但是由于时间、人力、成本等的把控,又需要快速的上线,就要权衡技术方案和运维方便的成本,将能预见的一些事情提前规划好,才能安稳的渡过上线高问题爆发期,让平台平稳的过渡到稳定、健康的状态。

毕竟, 技术永远都在为业务服务

站在运维的角度讲如何打造一个docker->mesos平台

问答过滤过一些,提问的同学多多谅解

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随机分配的,不过可以针对端口段来做控制。一个机器可以开几千个端口,但是容器就开不了那么多啦。

原文  http://dockone.io/article/1355
正文到此结束
Loading...