孙海龙的博客
记录笔记
CloudFoundry v2
2014-07-18 10:50:15   阅读932次

CloudFoundry 是业界领先的PaaS云平台,可以为应用提供运行平台,类似于运行着无数应用的炙手可热的HeroKu。最近发布的第二代,功能上有了极大的扩充,如 BuildPack, Service Broker v2, loggregator,并且用GoLang重写了大部分组件提升性能,如GoRouter,CLI,HM9000。本文带您走进这个大观园。还提供一个 MicroCFv2下载,满足您试一试的愿望,只此一家哦。

cf-trangle

CloudFoundry v1已经出现较长时间,在三年前EMC中国研究院就参与其研究。对CloudFoundry v1的研究可以参见彭麟《深入 Cloud Foundry》。 在CloudFoundry v2诞生前的三年里,一些事情发生了巨变。外部环境方面,AWS走向成熟,Heroku逐渐成功,摸索到了PaaS成功的道路。OpenStack风起云 涌,Docker带着小伙伴们异军突起。面对这些,CloudFoundry面临的竞争加剧,但同时也有了可以配合的伙伴。而CloudFoundry内 部也发生了变化,原先隶属于专攻虚拟化的VmWare,现在与时俱进,成为了专攻大数据的Pivotal的一部分。而CloudFoundry v2是CloudFoundry归于Pivotal的第一个版本,成为这家兴新大数据公司的战略一部分。

PivotalCycle

如果想试试CloudFoundry公有云,可以在官网上申请账户。下文主要针对自建CloudFoundry。

新架构

是骡子是马,看看架构就懂了。在看第二代的架构之前,我们回顾一下之前的架构。

cloudfoundry-architecture-v1

用户通过VMC Client将应用上传到Cloud Controller 上,Cloud Controller将应用部署到DEA Pool上面。用户可以通过Router访问到各自的应用,Health Manager查看各个APP状态,保证可以自动重启。同时Cloud Controller还提供了各种Services,如MySQL,Redis等等。

在上一代架构中,CloudFoundry呈现出大包大揽的方式,APP的部署也好,Service的提供也好,都自己做。虽然扩展Runtime 和Service并不麻烦,但是这需要“CloudFoundry”管理员的介入,租户是没有办法做这些的。另外私有云的玩家往往都有着定制 Runtime和Service的需求,内置的Service很难满足需要。当然还有一些问题,如Router性能不佳,协议匮乏。Health Manager单点。

在新的架构中,CloudFoundry有着更加开放的玩法。

cloudfoundry-architecture-v2

第二代CloudFoundry几乎将V1时代组件全部重写,满足新的需要。

APP方面,在上传应用的时候,用户可以同时上传一个BuildPack,这样租户可以根据自己的需要来部署应用,无需通知云管理员。 BuildPack是Heroku的部署机制,在社区有着丰富的资源。因此CloudFoundry和Heroku是兼容的。可以部署在Heroku上的 应用,也可以部署在CloudFoundry上。还有很多其他PaaS也使用BuildPack,BuildPack已经成为PaaS应用部署的事实标 准。

Serivce方面,不再内建Service,而是使用一个更加简洁的Service Broker和User Provided Service设计。用户可以将Service Broker使用现有的XaaS上面,如果OpenStack Trove, AWS RDS。Heroku 有很多小伙伴们 可以提供各种各样的 Service,比如监控服务Relic,国内也有很多,如监控宝。GAE式的PaaS证明关门玩Service是不行的,CloudFoundry走向 了开放的道路。另外User Provided Service可以让接上用户现有服务,如Oracle,保护现有资产。

大数据深入人心,CloudFoundry现在的loggregator可以让应用的日子流进Service中。实时数据分析成为可能。

新的的CloudFoundry对运行在IaaS有着天生的亲和力。BOSH可以非常方便的部署CF。Router的性能瓶颈得到解决。UAA可以提供第三方认证。Health Manager也不再是单点。

开放的App Runtime

开放的App Runtime的力量来自如Build Pack。我们可以浏览先App 部署的全过程。

  1. 用户使用使用CF PUSH命令上传应用

  2. CLI告知CCNG创建一个应用

  3. CCNG在数据库中加入该应用的记录例如应用名称,BuildPack选择

  4. CLI上传程序

  5. CCNG将程序存起来

  6. CLI启动应用

  7. 由于应用尚未部署,所以CCNG找一台DEA,在该DEA内执行BuildPack来部署应用

  8. DEA输出运行BuildPack的信息

  9. BuildPack执行完毕,输出是一个DropLet文件(编译打包的结果),DEA将该文件存起来

  10. DEA将打包情况汇报给CCNG

  11. CCNG选择一个DEA来部署应用

  12. 应用在DEA中运行,运行结果输出到CCNG

可以看到,BuildPack和APP一样都是在一样的环境(DEA)中执行的。BuildPack非常简洁,只需要三个脚本。

  • bin/detect 用来判断该BuildPack是否支持该程序

  • bin/compile 用来编译,类似Maven的mvn compile

  • bin/release 用来打包,类型Maven的mvn package

现在CloudFoundry内建了三个主要BuildPack,Java BuildPack是自制,Ruby和NodeJs都是沿用Heroku的

得益于Heroku的流行,第三方的BuildPack就数不胜数了。可以在Heroku buildpacks 和 CloudFoundry Commmunity 中找到很多。

Build Pack有一个问题就是每次编译都需要从外网下载依赖,巨大JRE文件和不稳定的网络会使部署失败。不过最近的发布中提供了Build Pack Cache功能,可以有效解决这个问题。在内网中搭建一个Cached Proxy也是不错的办法。

开放的Service

CF-Relase是CloudFoundry的发布包,我们可以对比下V1和最近的发布包。


v1v2(依据v155)
CloudFoundry Core组件数量2921
Service数量24 0

可见在v1版本中有大量的组件是在做Service,摊子铺的很大。而V2中将这个包袱放下,提交给各种第三方XaaS了。连接XaaS和 CloudFoundry的中间组件被称为CloudFoudry  Broker。v2的Service Broker和v1的完全不同。V2中的设计如下。

一个Service Broker 需要实现5个API接口,包含三方面

  • Service发现。租户可以向ClouldFoundry提交Add Service 命令,参数是URL。然后ClouldFoundry去调用该URL,发现该URL包含哪些Service

  • Service创建/删除。自动化的创建Service。

  • Service绑定/解绑定。将Service的一些访问参数设定成APP的环境变量。

Service Broker的部署可以很灵活。既可以作为CloudFoundry的组件,也可以作为CloudFoundry的APP运行在CloudFoundry上。官方提供了一些Service Broker 实现实例。

在企业生产环境中,Service的自动化创建并非易事。举MySQL例子,选择版本,机器,网络,存储,备份策略,高可用方案,搞上防火墙,打上 自定义补丁等等,一千个生产环境有一千种个MySQL玩法。在现在的玩法中,需要人介入的环节太多,太有必要。不存在一招鲜吃遍天的自动化创建方法。 User  Provided Service 就是来调和这个矛盾。让Cloud Foundry不强依赖自动化的创建Service。

User  Provided Service 很简单,就是用户在创建Service的时候,输入Service访问参数。如用户名,密码,CloudFoundry把这参数存起来,在绑定的时候注入到环境变量中。下面会演示。

亲昵的大数据

国内的CloudFoundry玩家大多有开放平台的计划。作为开发平台的运营者,不只要提供一个稳定,开放的平台,获得应用的数据,就等于把握住了脉搏。Pivotal做为一家大数据公司,接手CloudFoundry的一个大改进就是增加了Loggragtor模块。

 

Loggregator有是数据的中转站。数据可以来自应用和CloudFoundry的自身组件。和SysLog不同,Log根据APP分离,所以产生的数据是为APP服务,而不是为CloudFoundry系统本身服务。

引入了Loggregator后,用户在创建Service的时候,Service可以返回一个SysLog URL。当该Service绑定到某一个应用,该应用的Log会顺着这个URL源源不断流入。这个Service可以说Splunk也可以说 Pivotal Analytics. Heroku也有了这个机制。用户的大数据应用就可以无缝接入了。

Loggregator提供推(SysLog),拉(WebScoket)两种方式来获得数据。新的CF CLI就是使用Loggregator的WebSocket来获得APP的Log信息。

部署-MicroCFv2福利

不避讳的说,部署CloudFoundry v2的难度大于v1。

在v1中有dev_setup,提供一个基于Chef的一键脚本可以轻松部署。而v2中依赖BOSH,一个一站式的解决方案。可以将CloudFoundry部署在VSphere,OpenStack和AWS上。

目前看来有三种部署方式

  • 使用BOSH,BOSH比较重,运行起来就要费一些心力。但运转起来后可以提供健康监控,扩容的支持。

  • 使用IaaS自带的部署机制,可以使用VSphere OVF,OpenStack  Heat,Aws Cloudformation等技术。部署方便,但绑定IaaS。

  • 手动一步步安装。最灵活,也最费力。可以考虑和Puppet等机制结合。

由于官方不再提供新版本dev_setup,试一试CloudFoundry的成本变得很高。笔者提供了一个MicroCFv2镜像,请使用7-zip解压

MicroCFv2下载 (基于v154)

运行MicroCF

  1. 安装VMware Player

  2. 下载MicroCFv2

  3. 使用该镜像启动一台虚拟机

  4. 使用用户名/密码(admin/admin)登录

检查网络,正常情况下虚拟机会通过DHCP获得IP地址。记下IP。编译应用需要访问外网。

1

2

3

admin@atsg2-sh199:~/env$ ifconfig

eth0      Link encap:Ethernet  HWaddr 00:50:56:98:7f:0a  

          inet addr:10.32.170.199  Bcast:10.32.170.255  Mask:255.255.255.0

部署一个Java APP

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

admin@atsg2-sh199:~$ cd /home/admin

admin@atsg2-sh199:~$ cf login      

API endpoint> api.cf.com

Username> admin

Password> admin

 

admin@atsg2-sh199:~$ cf push helloworld -p helloworld.war

App started

urls: helloworld.cf.com

 

     state     since                    cpu    memory        disk          

#0   running   2014-02-06 11:52:18 PM   0.0%   60.8M of 1G   95.1M of 1G

 

admin@atsg2-sh199:~$ curl helloworld.cf.com

<h1>helloworld</h1>

创建一个Service

1

2

3

4

admin@atsg2-sh199:~/env$ cf create-user-provided-service oracle-db-mine -p '{"username":"admin","password":"pa55woRD"}'

OK

admin@atsg2-sh199:~/env$ cf bind-service helloworld oracle-db-mine            

OK

部署一个Ruby APP,并查看环境变量

部署Ruby APP,需要访问网络。
这个APP可以显现他自己的所有环境变量。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

admin@atsg2-sh199:~$ cd /home/admin/env

admin@atsg2-sh199:~/env$sudo  bundle install

admin@atsg2-sh199:~/env$ cf push

requested state: started

urls: env.cf.com

     state     since                    cpu    memory          disk          

#0   running   2014-02-07 12:14:18 AM   0.0%   18.1M of 128M   53.2M of 1G  

admin@atsg2-sh199:~/env$ cf bind-service env oracle-db-mine            

OK

admin@atsg2-sh199:~/env$ cf restart env

OK

admin@atsg2-sh199:~/env$ curl env.cf.com

...

VCAP_APP_HOST:

{  "user-provided": [

    { "name": "oracle-db-mine",

      "label": "user-provided",

      "tags": [],

      "credentials": {

        "password": "pa55woRD",

        "username": "admin"

      },

      "syslog_drain_url": ""

}]}

...

设置浏览器

你可以使用浏览器访问你部署的应用。需要给浏览器设置HTTP代理。IP为MicroCFv2的IP,端口是8123.如:

这样就可以使用浏览器了。




-----------------------------------------------------
转载请注明来源此处
原地址:#

-----网友评论----
暂无评论
-----发表评论----
微网聚博客乐园 ©2014 blog.mn886.net 鲁ICP备14012923号   网站导航