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

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

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

新架构

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

用户通过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几乎将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 部署的全过程。

用户使用使用CF PUSH命令上传应用
CLI告知CCNG创建一个应用
CCNG在数据库中加入该应用的记录例如应用名称，BuildPack选择
CLI上传程序
CCNG将程序存起来
CLI启动应用
由于应用尚未部署，所以CCNG找一台DEA，在该DEA内执行BuildPack来部署应用
DEA输出运行BuildPack的信息
BuildPack执行完毕，输出是一个DropLet文件(编译打包的结果)，DEA将该文件存起来
DEA将打包情况汇报给CCNG
CCNG选择一个DEA来部署应用
应用在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的

Java BuildPack 支持非常多框架和JVM语言。甚至包括new_relic，这给我们监控CloudFoundry上APP提供思路。
Ruby BuildPack
NodeJs BuildPack

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

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

开放的Service

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

	v1	v2(依据v155)
CloudFoundry Core组件数量	29	21
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

安装VMware Player
下载MicroCFv2
使用该镜像启动一台虚拟机
使用用户名/密码(admin/admin)登录

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

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

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

helloworld

创建一个Service

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可以显现他自己的所有环境变量。

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.如：

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

使用愉快。如果遇到问题，可以联系我。

5 thoughts on “CloudFoundry v2面面谈，内赠MicroCFv2福利”

a 说:

2014年2月12日于下午2:16

无法在win下解压缩

回复
- Kay Yan 说:
  
  2014年2月14日于下午8:03
  
  请用7zip
  
  回复
wangshuai 说:

2014年5月14日于上午11:36

输入 endpoint 的时候提示 connection refused “Invalid API endpoint.
Error performing request: Get http://api.cf.com/v2/info: dial tcp 127.0.0.1:80: connection refused”；为什么

回复
- wangshuai 说:
  
  2014年5月14日于下午1:53
  
  搞定了不好意思打扰
  
  回复
  - fang 说:
    
    2014年6月25日于下午4:19
    
    请问怎么搞定的？我也遇到这个问题了。
    
    多谢！
    
    回复

我自然

CloudFoundry v2面面谈，内赠MicroCFv2福利

新架构

开放的App Runtime

开放的Service

亲昵的大数据

部署-MicroCFv2福利

运行MicroCF

部署一个Java APP

helloworld

创建一个Service

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

设置浏览器

5 thoughts on “CloudFoundry v2面面谈，内赠MicroCFv2福利”

发表评论取消回复

新架构

开放的App Runtime

开放的Service

亲昵的大数据

部署-MicroCFv2福利

运行MicroCF

部署一个Java APP

helloworld

创建一个Service

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

设置浏览器

5 thoughts on “CloudFoundry v2面面谈，内赠MicroCFv2福利”

发表评论 取消回复

发表评论取消回复