有容云：容器驱动的PaaS平台实现方案（下）

Posted 2020-08-02 有容云

编者注:

本文基于上海容器大会现场演讲内容，立足于实战跟大家分享了新一代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容器生态圈。