云计算前沿—详解PaaS之Cloudfoundry

沈阅斌 2016-01-28 09:47:03

随着云计算的不断发展,IaaS已经不能满足用户的需求。作为一个能够简化开发、测试、部署、运维的平台,Pass受到了越来越多的关注。今天沈阅斌老师将为我们分享关于PaaS的一些亲身经验和体会,同时详细介绍PaaS技术中的Cloudfoundry。

目录


  • PaaS基本介绍

  • PaaS的价值在哪里

  • PaaS的技术选型

  • Cloudfoundry基本介绍

  • Cloudfoundry架构及相关组件

  • 基于Cloudfoundry扩展PaaS功能

  • Diego介绍


一.PaaS基本介绍


PaaS,平台即服务。是云计算的一种服务形式。其实并不是一个非常新的概念,像GAE、SAE很早就提供了类似这样的服务。不过在很长一段时间内,PaaS接受程度不高,在跟客户谈及云计算时,普遍都认为云计算就是IaaS,即基础设施服务。但是随着云计算的不断发展,用户发现光有IaaS,虽然简化了对基础设施资源的管理,但是对云计算的终端用户来说通过IaaS只是拿到了一个裸操作系统,要想开发一个软件并部署到云平台上,还需要做很多工作。包括代码的管理、持续集成、自动化测试、交付物管理、应用托管、中间件服务、自动化运维、监控报警、日志处理等等。用户希望通过一个平台能够真正简化开发、测试、部署、运维等工作,使得企业能够真正实现DevOps。


二.PaaS的价值在哪里


在我们接触PaaS之前,我们做开发时需要自己搭建各种环境,包括开发环境、测试环境,上线的时候需要搭建生产环境以及进行各种配置,上线之后还需要进行人工运维。有时候搭建环境是一件很麻烦的事情,比如搭建一个tomcat的集群或者是MySQL主从等。由于各种环境都是人工搭建,难免会出现环境的不一致,导致系统在某个环境下运行地好好的,但是部署到其他环境就无法正常运行的情况。


PaaS可以提供各种标准化或非标准的环境以及各种运维管理功能,用户可以在秒级按需获取各类资源和环境。所以PaaS最大的价值在于解放开发、测试、运维人员。虽然目前还不能完全做到这个程度,但它实实在在地降低了用户对应用软件的交付成本及时间。


通常我们所说的PaaS,包括MoPaaS,主要提供应用部署和托管服务。平台服务涵盖的范围包括,应用开发部署运行环境(如应用开发测试管理/工具等),服务组件池和管理(数据库、消息队列、缓存等),应用资源管理(开发运行管理应用、弹性伸缩等)。


三.PaaS的技术选型


其实我们刚接触PaaS的时候,并没有多少可以选择的PaaS技术,所以当Cloudfoundry推出的时候,我们毫不犹豫地选择了Cloudfoundry作为我们构建MoPaaS的基础框架。


最近几年,随着容器技术的飞速发展,比如Docker,目前构建PaaS的技术方案非常多,比如Cloudfoundry、Openshift、Docker+K8s、Docker+mesos+marathon、Cloudify等等,目前这些方案或多或少都在被企业采用。


至于哪种方案最优,个人觉得还是根据用户的具体需求来决定的。比如Cloudfoundry,虽然很多人认为比较重量级,但是在成熟度以及PaaS功能提供方面优于其他方案。再比如要构建一个基于Docker构建PaaS平台,那么像Docker+Mesos+Marathon就是很好的选择。


四.Cloudfoundry基本介绍


Cloud Foundry是一个工业级开源PaaS,它可以部署为一个云,并对外提供多语言多框架、应用运行环境及服务。个人认为,CF的社区相对还是比较活跃的,并且版本迭代比较快,一般1,2周就会发布一个小版本。而且CF在不断的改进和优化自身的架构,到目前为止已经经历了CF V1,CF V2以及CF V3。每一次大版本的发布都对CF进行了性能和架构上的优化。


我们接触PaaS的时候,CloudFoundry还不是很成熟,需要我们自己对CloudFoundry源码进行修改和BUG修复。比如那时候还没有引入容器进行资源隔离,只能通过对应用进程监控以及操作系统用户用户组的方式进行隔离,在这些方面我们需要做很多定制工作。


后来Cloudfoundry V2版本的推出,在稳定性、安全性方面做了大量提升,并且引入容器Warden(CF自带的)进行资源的隔离。这时候容器技术Docker也开始兴起,Docker在某些方面确实可以弥补CF的不足,所以我们在MoPaaS后来的版本中大量使用Docker等容器技术。比如一些轻量级服务的提供,可以通过Docker实现自动化部署及资源隔离和监控。


Cloudfoundry V3版本将推出新的运行时Diego,提供的容器叫Garden,将支持运行Docker镜像。


五.Cloudfoundry架构及相关组件



1、 软件路由和软负载均衡


Haproxy、Gorouter:

Router将平台流量分发给特定的组件,通常为Cloud Controller,或者运行在DEA节点上的应用。


2、 认证和授权


UAA、Login Server:

UAA与Login Server主要提供用户身份认证管理服务


3、 应用生命周期管理


Cloud Controller、Health Manager:

当开发者将一个应用push到cloud foundry后,Cloud Controller会存储应用文件,在数据库中创建应用的元数据记录,并指派DEA节点来stage及运行应用。Cloud Controller同时还维护了组织、空间、服务、服务实例、用户角色等记录信息。


监控应用以确认其运行状态(例如running\stopped\crashed等)、版本以及实例个数。HM9000根据运行应用的DEA返回的心跳(heartbeats)及droplet.exited消息来更新应用的实际运行状态。


确认应用的期望运行状态、版本及实例个数。HM9000从CCDB中获取应用的期望运行状态。


使应用的期望运行状态和实际运行状态一致。例如,如果实际运行的实例个数少于期望运行的实例个数,HM9000就会指示Cloud Controller启动准确的应用实例个数。


指示Cloud Controller修复任何应用状态的差异。


4、 应用存储和运行


Blob Store、Dea:

DEA负责管理应用实例,跟踪已启动的应用实例,并广播其运行状态的消息。


Blob store保存了应用代码、Buildpacks(应用依赖的runtime、web server、framework等的集合)以及Droplets(已完成stage的可直接在DEA上运行的应用包)。


5、 服务


Service Broker:

应用往往依赖于数据库或第三方服务。


当开发者需要创建一个服务实例并将其与某个应用绑定,该服务的Service Broker负责提供这个服务实例。


例如应用需要使用MySQL数据库服务,MySQL服务的Service Broker负责创建一个MySQL服务实例,并将该服务实例与应用绑定。


6、 消息


Nats:

Cloud Foundry使用NATS进行组件间的内部通信。


NATS是一种轻量级的、基于发布-订阅机制的分布式队列消息系统。


7、 日志和监控数据


Metrics Collector、App Log Aggregator:

计量数据收集器从各组件收集计量数据。运维人员可以使用这些信息对整个Cloud Foundry平台进行监控。


应用日志汇集器(loggregator)可以将应用日志输出给开发者。


在Cloudfoundry平台上,应用如何被部署运行的?



  1. 开发者切换到应用根目录,使用命令行工具cf CLI提交“push”命令。

  2. Cf CLI告知Cloud Controller创建一条该应用的记录。

  3. Cloud Controller将该应用的元数据存储至CCDB(例如应用名、实例个数,以及指定的buildpack等信息)。

  4. Cf CLI将应用文件上传至Cloud Controller。

  5. Cloud Controller将应用原始文件保存到blobstore中。

  6. Cf CLI提交应用“start”命令。

  7. 由于应用尚未stage,因此Cloud Controller会从DEA池中选择一个DEA对应用进行stage,负责stage的DEA会根据buildpack中的指令对应用进行stage(stage过程主要是为应用配置相关的语言runtime、web服务器、框架等,最终得到一个可以独立运行的应用包droplet)。

  8. 负责stage 的DEA会将stage过程的日志同步输出至cf CLI,开发者可以据此定位stage错误。

  9. 负责stage 的DEA将已完成stage的应用打包成一个称为droplet的压缩包,并将该droplet存储至blobstore。

  10. 负责stage的DEA向Cloud Controller报告stage工作已完成。

  11. Cloud Controller根据应用配置从DEA池中选择一个或多个DEA来运行已完成stage的应用(在DEA的warden容器中运行droplet)。

  12. 负责运行应用的DEA向Cloud Controller报告应用的运行状态。


Buildpack:


Buildpacks为应用提供框架及运行时支持。


Buildpacks通常会检查用户提供的应用代码以确定需要下载哪些依赖,以及该如何配置应用使其能跟绑定的服务进行通信。


当你Push一个应用,Cloud Foundry会自动检测(也可以在push时显式指定)要使用哪个buildpack,并将其安装至运行应用的DEA上。



表中所列为Cloud Foundry system buildpack。


开发者可以通过以下方式使用上述所列之外的buildpack:


1. 改造已有的buildpack;

2. 自己编写buildpack;

3. 使用Cloud Foundry社区提供的Buildpack;

4. 使用Heroku提供的第三方buildpack。


服务:


通过实现一组API被集成进Cloud Foundry 的服务称为受管理的服务。


用户可以按需创建相应的服务实例,并获取使用该服务实例的凭证。

ss


Service Broker标准APIs。


1. 获取服务目录

2. 创建服务实例

3. 绑定服务实例

4. 解绑服务实例

5. 删除服务实例


六.基于Cloudfoundry扩展PaaS功能


虽然Cloudfoundry已经提供了PaaS平台的基础框架,但是如果我们想要基于CF构建一个PaaS平台,并且能够给用户提供PaaS服务的话,还是需要我们做很多的定制化的工作,接下去我就简单介绍一下相关内容:


1、 应用运行环境扩展


通过修改和增加Buildpack实现,我们可以对Buildpack进行相关定制,包括修改中间件的版本、配置信息以及buildpack代码来实现更多的功能,比如安装APM的探针。然后将Buildpack打成离线包上传到Cloudfoundry。


如果需要扩展.NET运行环境,可以使用一个开源的.NET插件IronFoundry,因为.NET跟其他运行环境不一样,需要运行在Windows操作系统上面,所以要单独安装一个Windows的Dea(IronFoundry提供),并且将.NET Buildpack添加至Cloudfoundry之后完成扩展。


2、 服务中间件扩展


Cloudfoundry对服务中间件集成提供一种标准的接入方式Broker,对中间件部署、运维、监控,Cloudfoundry并没有提供很好的方式解决方案,需要我们自己实现。一些轻量级的中间件服务,如缓存,可以采用Docker进行部署和管理,数据库服务可以采用VM方式部署,然后通过Broker将服务注册到Cloudfoundry。


https://github.com/cloudfoundry-community/spring-service-broker.git


https://github.com/cloudfoundry-samples/github-service-broker-ruby.git


3、 可视化操作界面


Cloudfoundry提供了一套标准的Rest API,包括认证授权、组织空间管理、应用服务管理等功能。我们可以通过cloudfoundry提供的SDK可以非常方便的完成对CF的调用。


https://github.com/cloudfoundry/cf-java-client.git


4、 应用/服务监控


Cloudfoundry对应用的监控还是做了一些工作的,包括像health_manager,会实时采集应用的监控信息。通过Dea的Varz接口也可以采集到应用的监控信息。如果应用出现不健康的状态,CF会对其进行自动重启。对应用访问日志数据,Cloudfoundry在Gorouter节点上有进行记录,但是如果我们需要采集分析这些日志数据,那么我们需要修改Gorouter,将日志打到日志服务器上。对服务的监控,完全需要我们自己来做,如果只是一般的监控需求,可以采用对容器或者VM监控,如果需要获取服务中间件更加详细的监控数据,可以通过集成APM来实现。


5、 弹性伸缩


Cloudfoundry提供了对托管的应用进行弹性伸缩,包括纵向和横向的伸缩,但是只能通过手动的方式,如果需要根据规则和阈值进行自动伸缩,需要我们进行定制开发,通过对应用采集的访问数据、监控数据进行分析,满足阈值条件则进行伸缩。


6、 持续集成


Cloudfoundry对开发测试这块并没有提供太多的功能,不过我们可以采用目前比较通用的方案来实现持续集成。


采用Git/SVN托管代码;采用Nexus/Artifactory作为制品仓库;采用Jenkins作为持续集成工具,通过Jenkins提供的插件,可以将代码托管、制品仓库以及PaaS平台进行集成,实现从代码提交到部署上线一整套自动化流程。


7、 TCP协议的支持


Cloudfoundry默认只支持Http(s)协议,如果需要部署一个TCP协议的应用,那么我们需要定制一个TCP_Router。


https://github.com/cloudfoundry-incubator/cf-tcp-router.git


七.Diego介绍


Diego。(DEA in Go),Cloud Foundry的下一代容器管理系统。


在没有Diego的Cloud Foundry平台中,由Cloud Controller负责调度并管理DEA上的应用。


而Diego取代了DEA以及HM9000,并从Cloud Controller那接手调度及管理应用的职责。


Cloud Foundry V3具有全新的 Runtime, Diego。Cloud Foundry(v3) 主要由 CC,  UAA,  Diego,  Loggregator, Gorouter,  Buildpacks, 和Services和 Bosh等组件构成。新的Cloud Foundry可以无缝地提供Docker容器服务;在原有支持 Linux 平台的基础上,也将支持 Windows应用。


在新版Cloud Foundry中Diego将取代目前的DEA 。Diego解决了原Cloud Foundry架构功能上的的一些局限,包括:


1)功能间的强耦合。

2)DEA、HM和Cloud Controller之间的三角依赖关系。

3)应用范围只局限于Linux平台,对Windows不原生支持。我们也将在MoPaaS新版中采用CloudFoundry V3版本。


讲师介绍:


  •  魔泊云产品研发总监 。

  • 11年IT从业经验,J2EE技术背景。 

  • 2011年加入魔泊云负责MoPaaS产品研发和管理工作,是国内较早接触cloudfoundry等PaaS技术并从事相关研发的工作者之一。




小编精心为大家挑选了近日最受欢迎的几篇热文↓↓↓

(关注订阅号dbaplus,回复以下数字,即可获取相应文章)

 

回复001,看陈爱珍《从文艺女到技术咖,一位美女工程师的华丽转身》;

回复002,看丁俊的《【重磅干货】看了此文,Oracle SQL优化文章不必再看!》;

回复003,看胡怡文《PG,一道横跨oltp到olap的梦想之桥》;

回复004,看陈科《memcached&redis等分布式缓存的实现原理》;

回复005,看陆传胜《听阿里巴巴JVM工程师为你分析常见Java故障案例》;

回复006,看郑晓辉《存储和数据库不得不说的故事》;

回复007,看袁伟翔《揭秘Oracle数据库truncate原理》;

回复008,看OpenSkill陈荣华《时下最火搜索引擎:ElasticSearch详解与优化设计》;

回复009,看丁启良《LINUX类主机JAVA应用程序占用CPU、内存过高分析手段》;

回复010,看周李洋《面对Schema free的MongoDB,如何规范你的schema》。

 

活动预告