有容云:容器驱动的PaaS平台实现方案(下)

编者注:

本文基于上海容器大会现场演讲内容,立足于实战跟大家分享了新一代PaaS平台构建中遇到的问题、当下主流PaaS平台解析、企业交付经验及心得体会等。文章较长,分为上、下两个部分,本文为下篇。

前文阅读请点击:容器驱动的PaaS平台实现方案(上)

下面我花一点时间跟大家分享下比较干货的东西。比如说容器的网络,之前我们也听了一些专家谈到Flannel,Calico 等等,但是我不知道大家有没有注意到,国内外在谈容器网络的时候更多的时候会再谈Overlay网的构建,比如IPSec、VXLAN等等,都是标榜所谓的SDN思路,其实也就是隧道技术的构建。去年的时候我跟很多朋友去谈,大家都说很好啊很先进啊,但是今年再去谈的时候发现大家已经不感冒了。大家对容器已经有了深入的认识,已经开始考虑现实的问题。这里有几个故事分享给大家。

我们南区的一家银行客户,他们为什么会不喜欢Overlay呢,他们说的是因为网络团队不具备Troubleshooting Overlay网络的能力; 而北区一个银行客户,他们道理是说我们已经采用了其他SDN的解决方案,我不希望你在里面再打个洞。还有上海的一个客户,不喜欢任何形式的Overlay,因为它性能drop得很厉害。基于各方面的考虑,我发现越来越多的客户不喜欢用Overlay的容器网络。而我觉得最根本的原因,无论我们作为厂商跟客户交流还是客户自己去谈容器项目或者启动容器项目时,我想源动力更多的是来自于开发部门、运维部门,很少有网络部门牵头说我要弄容器。对于网络部门来说,当你去沟通需要搞什么容器或者更牛的技术的时候,他们的反馈会是只要不改变已有的网络你怎么搞都行,但是如果你想动我的网络我是不会同意的,所以我想这是个很现实的问题。我们的思路是说,Overlay网络很好,但是我们基于现实考虑,怎样构建一个跟传统IT网络相兼容的容器网络。

另外一方面是容器的存储,大家都在谈,容器最好应用在无数据状态的场景。但是如果大家对容器是非常有信心的态度的话,我相信早晚有一天我们所有的业务,包括我们所有的有状态应用或是无状态应用,都会跑在容器里面。或者说这些问题早晚有一天是要解决的。我们有容云内部有个项目,就是要解决好容器数据的问题。比如,是否可以由程序员来指出他的程序希望跑到什么类型存储上去,当应用部署到容器平台上的的时候,系统可以自动识别到由程序员提供的存储使用标签,比如说你希望把Application运行在IO性能很高的存储上,那我们的
存储控制器就能自动把 应用程序接驳到SSD这边来。如果我们看到你的数据标签是希望支持一个每天晚上12点的自动拍照,那我们的存储控制器会自动帮你做这些工作。现在我们在做这方面的工作的原因之一是,传统的storage方案都不是天然为Docker去开发的,这些storage都不是Native 的container storage。所以我们在做的就是从零开始构筑一个自己的存储体系,一个分布式存储,我们的分布式存储完全是根据Docker或者说容器云的场景来开发的。这个产品将在今年下半年发布。

下面我们来聊聊基于CaaS的PaaS平台体系架构。但是并不是所有架构都长这个样子,这只是个示例而已。大家都很熟悉,在刚才在上一张胶片中也见到过,下面我们就一起来看看PaaS offering能力构建,比如说大数据分析体系,大数据的一些插件,还有一些中间件,这些都需要在一个良好CaaS平台上构建起来的PaaS能力。

对于一个企业的私有镜像仓库来说,它不仅仅是经过CI进行代码构建镜像并管理起来那么简单,他还涉及到一些权限的概念在里面。比如说,经过CI之后,你希望你默认生成的Docker镜像是在企业私有镜像仓库Dev的这样一个隔离空间之内,因为你肯定希望你的企业有一个统一的镜像库,其次你不希望你的镜像被任何人都可以拉去。比如你现在通过CI自动生成的一个镜像,还未经过测试,处于Dirty状态,你肯定不希望这种Dirty状态的镜像被你Ops的同事拉取下来并且部署到本地生产环境中。即使是手误你也不希望他这么做,所以一个良好的企业私有镜像仓库管理应该配套一个基于项目或者是基于权限的管理。比如说我的CI生成的镜像包默认是在一个叫Dev的空间内,我的Ops的团队现在并不能把它拉下来。但是在经过充分测试通过以后,产品经理做一个Action,把镜像从Dev转移到Staging或是Production
空间,经过这个动作之后Ops才能把它部署到生产环境中去。

再往上可能会涉及到一些软件版本管理,比如刚提到的灰度发布、开发者门户等等, 越往上可能每个企业都需要一些个性化和定制化的内容,这里不再详述。

这张图早上在梁博士的分享上相信大家也看到了,这里我们只是用它来做个举例。因为我们看到越来越多的产品有了这种功能,基于Docker的易于部署和平台无关性特点,建造出来的Catalog应用商店模式,我相信这个趋势未来会越来越多,我们已经看到很多产品都在做这个功能了。简而言之就是一个基于固定模式的配置,或者说文件的定义,可以把一个系统整个打包到应用商店上,图形界面可以把它看成是PaaS平台的看板,每个图标代表了一种构建应用或者中间件的PaaS能力,比如我们CICD、大数据处理的能力等等,利用以容器为基础的轻量级的PaaS平台,这种平台能力的构建我们可以自己把控,而不是说一个厂商他发布了这个软件你才有。打个比方,我们需要一个接口,这种接口可能现在还没有,但是我们可以自己去开发,或者说某一天你看到网上有人已经开发了,那你就可以直接把它拿过来放在你的应用商店上,就可以去用。这是我们整个构建PaaS
offering能力的想法,我们正在做这个事情,我也相信未来这个市场会越来越繁荣。

我举个具体的例子来说,不管是对于Rancher还是对于我们有容云来说,我们怎么从技术角度做到应用市场让每个人贡献,去交换和共享你的应用呢?这里有个最关键的地方:Docker镜像没有什么出奇的地方,但是需要一个方式把你整个的业务系统描述清楚,你可以看到你的系统是分几层的。

比如我们看到,上面有一个WebLogic的中间件产品,大家可以看到它是分层的;上面有个负载均衡,最下面有个Weblogic容器的实例,镜像来至于什么地方等都描述得很清楚。当然,Docker-Compose就可以帮我们做这个事情,但实际上,Docker-Compose无论是第一个版本还是现在的版本,他在描述整个系统全貌的时候语法还是有些晦涩,他有一些功能是描述不清楚的。

比如说,我希望我的负载均衡能够有一个基于Cookie Insert的会话保持的能力,我希望对我的Weblogc上的某个应用进行健康检查的判断、包括访问页面时我希望得到什么反馈等等。你会发现你的应用程序属性越高级,你就越需要一个更具体的、特殊化的方式去实现,而不是Docker本身自带的组件。

对于高级属性的东西Docker-Compose往往是默认它并不能给到你。而Rancher的做法在业界也是属于比较创新的,也有很多人在效仿,就是在默认的Docker -Compose基础之上扩展出一个附加一个Rancher compose的附加属性配置,这个附加配置会更详细的定义配置,比如说我的负载均衡的算法是什么样子,我的健康检查策略如何,我的集群节点有多少个成员等等,这样的话如果把这两个文件放在一起,他就构成了一个完整的IT系统,无论PaaS的能力插件,是还传统的后台系统,都定义的很清楚,我把它定义为PaaS
Offering的能力组件,或者说是一个应用商城

接下来我们可以在部署的时候用定义的能力做一些具体配置。大家看到我在部署是基于WebLogic上应用的时候,并不是说要把你WebLogic的空的domain部署出来,而是要把你的业务部署出来,要把你的业务可以跑在环境上,这才是我要做的事情。在我实际部署的时候,你只要在配置表单中告诉我你的WAR包在什么地方,你的JDBC信息是怎么样的,那么接下来在实际部署的时候,你的应用连同支撑它运行的环境完全可以一键部署出来。而不是像传统部署流程那样需要来来回回的流程,现在你只需要一步,到应用商店上去,选择你需要的应用,把你的应用位置告诉我,把你的JDBC信息告诉我,然后配置好点击,就能帮你完成。

而且最酷的不是说这是我们产品本身的功能,而是任何人都可以贡献的,这个功能模块大家也可以去编写和贡献,你可以做得比它更好,而且有了模块之后可以分享,比如说我把我的地址信息告诉我的朋友,他的系统中只要配一个我的商店的接口,它打开自己的系统是也能看到我应用上店上的模块,而且我的应用商店模块有了改变之后,他只需要刷新下他的应用商店门户,也可以同步看到更新。所以我们比较看好的是这种基于容器镜像的能力模块,基于上层交互的社区建设.然后还有一个AutoScale模块,AutoScale也是PaaS模块中必不可少的一块,默认的Rancher没有这方面的能力,但是我们刚才提到的开放式的框架,我们可以自己设计一个这样的能力模块,它可以对你的集群做监控。

其实其他平台也能做到这个功能,这里我们只是举个例子。比如你的CPU、内存压力在变化,然后你的AutoScale能力模块可以监测到压力变化,同时触发一个动作,把集群规模扩容。大家都知道的是,无论哪个平台扩容之后,同时进行负载均衡,把CPU降下来这已经不是什么新鲜事。但是这里缺乏的是AutoScale能力对你业务指标的能力,比如说今天是监控CPU,我改下我的模块就能去监控你的业务指标了。

传统厂商他们也开始推出基于容器的Load Balancing的能力模块,Citrix已经有了这样的产品,也许有一天F5也会推出基于容器版本的负载均衡能力,是否说有一天我们在做PaaS平台的时候,可以为我的用户提够一个选择,是来自于Citrix或是F5的负载均衡模块,这是行业内的一种趋势。

刚才我们也提到一些更好的场景,比如说高可用数据库,我们希望部署这么一个场景,给程序员一个商品,我点击一下这个商品就能获得高可用的数据库。那么可能这个商品是类似图上的MySQL
数据服务,那么其实这个是今天有容云应用商店上已有的一个能力,你可以点击一键部署,高可用的MySQL就部署出来了。

接下来呢我们来谈谈容器的日志和告警,当然由于时间关系,我不再一 一细讲。这是我们有容云之前做日志研发的时候考量的其他国内外厂商情况。我知道很多人对日志和告警这一块也很感兴趣也在看,我分享给大家的是大家在选择的时候有几个地方可以注意一下。你选择的解决方案是一个托管模式还是一个部署在企业内部的On-Premise模式,这个是很重要的指标。

我们发现很多国外的好的解决方案比如说Sysdig都是默认采用的托管模式。就是说你把你的Engine 部署在本地,然后把你的数据弄到美国去,你需要注册一个账号,登录去看你的数据。他们的系统做得很好,但就是这条我们就把他们否了,因为国内用户最讨厌的就是把自己的数据弄到国外去。国内很多厂商在做托管形式的云监控,这也许是一个路子,这样的厂商之后我们也会跟他们进行合作。以上这些系统都各有特点,我们自有版本集成了两个模块,一个是Splunk,一个是ELK+Zabbix. 接下来大家很关心的容器日志,它能不能去收集管理呢?能不能像传统模式一样,有一个集中式的服务器,把所有容器相关的日志都上传上来?

我的个人理解是至少有几个方面需要你关心,第一,Docker环境产生的日志,比如容器启停这样的事件等等。第二个方面是容器本身的output,放在标准输出,Docker要求大家最好把程序都改掉,改成日志打到标准输出上。这里不评判是好是坏,但是我相信我们今天上容器的大部分应用厂商还在采用第三种模式:我把我的日志写在应用文件夹下的
App.log的模式。对于这种模式怎么来传输呢,这是一个很现实的问题。如果把你的日志处理Agent放在你的Docker容器里面去,就会使你的容器变大,所以我们就自己开发了一个方案,这里面用到的两个技术,一个叫伙伴容器技术,一个叫数据卷共享的技术。我相信对于Kubernetes也有一个类似的方案,  无论如何我在侵入你的主容器的情况下提供一个伙伴容器,这个伙伴容器能把分散的日志上传到集中式日志服务器上去,然后做一个比如分析排障,报表统计等等的工作。

最后我们聊下容器的安全性,相信这也是大家非常关心的一个话题。之前我们谈过很多客户,虽然目前还没太多客户谈到容器安全的话题,但是我相信未来肯定会有很多用户去关心,相比较传统安全产品和方案,我们有容云相信一个专为容器开发的安全产品是必要的,也符合趋势。我们也计划在今年下半年推出相关产品,大家可以关注下有容云的官方微信号。

谢谢大家!

温馨提示

对Docker容器技术或容器生产实施感兴趣的朋友欢迎加群454565480讨论。我们汇集了Docker容器技术落地实施团队精英及业内技术派高人,在线为您分享Docker技术干货。我们的宗旨是为了大家拥有更专业的平台交流Docker实战技术,我们将定期邀请嘉宾做各类话题分享及回顾,共同实践研究Docker容器生态圈。

时间: 2024-10-13 19:27:20

有容云:容器驱动的PaaS平台实现方案(下)的相关文章

有容云:容器驱动的PaaS平台实现方案(上)

编者注: 本文基于上海容器大会现场演讲内容,立足于实战跟大家分享了新一代PaaS平台构建中遇到的问题.当下主流PaaS平台解析.企业交付经验及心得体会等.文章较长,分为上.下两个部分,本文为上篇. 嘉宾介绍: 马洪喜,有容云联合创始人兼首席架构师.此前担任Rancher Labs中国区技术负责人.Citrix公司资深架构师.Oracle公司虚拟化产品开发经理等职务,在容器云.IaaS云.桌面云建设方面拥有较为丰富的经验. 本次大会的大部分朋友都是以用户身份分享了自己家的故事和经验,我作为厂商代表

有容云:微服务容器化的挑战和解决之道

注: 本文根据6月是18日七牛云微服务课堂-微服务容器化的挑战和解决之道演讲内容整理而成,演讲者:有容云联合创始人兼首席架构师马洪喜,与大家一起探讨了如何通过容器技术将微服务和 DevOps 落地. 嘉宾介绍: 马洪喜,此前担任 Rancher Labs 中国区技术负责人.Citrix 公司资深架构师.Oracle 公司虚拟化产品开发经理等职务,在容器云.IaaS 云.桌面云建设方面拥有丰富的经验. 单体架构 VS 微服务架构 传统单体架构存在各种各样的问题,如加载编译耗时长.代码管理复杂.横向

有容云——窥探Docker中的Volume Plugin内幕

编者注: 本文根据有容云技术实施团队原创分享内容整理.对Docker技术感兴趣.或对本文中细节需继续探讨的朋友,欢迎加入我们参与讨论! 特别鸣谢中生代技术群分享支持. 注:本期分享由张朝潞原创,有容云整理发布,转载请注明出处 作者介绍: 张朝潞,有容云(Yourun Cloud)平台存储架构师.曾工作于UIT,华三,腾讯,专注分布式存储的研究和开发,对云计算存储解决方案方面有很深的技术造诣和行业理解. 本次交流将与大家分享Docker Volume plugin相关的内容.今日主题是窥探Dock

中国东信基于Kubernetes的容器云PaaS平台

"中国-东盟信息港"是按照国家"一带一路"倡议总体布局要求.建设更为紧密的中国-东盟命运共同体.21世纪海上丝绸之路的一个信息平台:http://www.caih.com.东信基于Rancher Kubernetes架构和建设了他们的容器云PaaS平台,在云原生.容器化.微服务.CICD.DevOps等方面的都有了相关实践和应用. 6月28日,负责中国东信容器云PaaS 平台的研发和建设.中国-东盟信息港的研发总监王志雄出席了Rancher Labs举办的Conta

中国人寿如何基于容器搭建金融PaaS云平台

6月28日,Rancher Labs在北京举办了Container Day 2018容器技术大会.在大会上,Rancher Labs CEO及联合创始人梁胜博士.中国人寿研发中心开发五部副总经理王川.技术处高级经理郑晓勇.开发五部云计算架构师张青南.ZStack CEO及创始人张鑫进行了一场圆桌讨论. 本文整理摘取自圆桌讨论环节的内容,由中国人寿的嘉宾分享了中国人寿使用容器技术.搭建金融PaaS云平台的心路历程,以及存储.网络.CI/CD.微服务.数据库拆分等具体技术细节和经验. 中国人寿容器使

有容云:梁胜-如何让Docker容器在企业中投产(下)

编者注: 本文是对上海容器大会有容云专场梁胜博士直播视频的文字回播,力求高度还原当天演讲内容未加个人观点,如在细节部分略有出入欢迎留言指正.(文章较长,分为上.下两个部分) 前情提要: 在上篇中梁博士讲了容器技术短时间内爆发的根本原因,容器在企业中投产的必要性.必然性以及容器投产四种场景中的前两种:新一代的私有云.混合云环境:企业应用商店和一键部署:本篇将介绍最后两种场景:多环境.多资源池的DevOps流水线,构建轻量级PaaS服务,以及微服务.容器云等方面的内容,阅读前文清点击:梁胜 | 如何

体验搜狐PaaS平台搜狐云景-自动调度(Autoscale)

今天,收到一封「搜狐云景」送邀请码的邮件,价值 200 rmb,立马前往官网简单了解一下,这个玩意儿是搜狐公司云战略的一个产品,一个 PaaS 平台,简单了解了一下特性: 1.自由定制运行环境,这表示支持多语言环境,官网说支持 Python.Java.PHP.Lua.Ruby.Node.js 等语言,这对于我这 Python 码农来说是利好啊,200 rmb可以在这平台跑跑博客了. 2.灵活自定义调度,这表示用户可以根据自身应用规模设置调度规则,这种高大上的技术目前只在 AWS 的 E2C 上看

搜狐云景paas平台实践之路

前言: 搜狐云景作为搜狐的paas平台,在2014年5月22日的云计算大会上正式发布了公测.初测,注册用户必须先申请邀请码参与公测会赠送用户100元电子券,经过实名认证之后会再赠送100电子券,目测可以对试用用户基本app够跑半年. 除了用户中心的一些基本安全信息设置和各种账单外,我想主要对其控制台的使用进行研究一番. 废话不多说,在绑定邮箱并充值10元成正式用户之后,无阻挡进行各种测试吧. dashboard很清新干净,是一个对用户基本消费情况和使用资源服务的基本概览. -----------

有容云:梁胜-如何让Docker容器在企业中投产(上)

编者注: 本文是对上海容器大会有容云专场梁胜博士演讲视频的文字回播,力求高度还原当天演讲内容未加个人观点,如在细节部分略有出入欢迎留言指正.(文章较长,分为上.下两个部分) 在美国的Dockercon大会中,大会主题是怎么样让Docker容器在企业中投产.大家一直在讲这个关于投产的话题,但其实这里面有一个很关键的问题,Docker是一项不错的技术,但是要变成生产力,仅仅是一些研发人员或者是互联网公司能把容器用好还远远不够.怎样让广大企业能够把容器用起来,能够进一步加快自己内部软件开发及部署的速度