CloudFoundry v2简介
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的力量来自如Build Pack。我们可以浏览先App 部署的全过程。
可以看到，BuildPack和APP一样都是在一样的环境(DEA)中执行的。BuildPack非常简洁，只需要三个脚本。
现在CloudFoundry内建了三个主要BuildPack，Java BuildPack是自制，Ruby和NodeJs都是沿用Heroku的
得益于Heroku的流行，第三方的BuildPack就数不胜数了。可以Heroku buildpacks 和 CloudFoundry Commmunity 中找到很多。
Build Pack有一个问题就是每次编译都需要从外网下载依赖，巨大JRE文件和不稳定的网络会使部署失败。不过最近的发布中提供了Build Pack Cache功能，可以有效解决这个问题。在内网中搭建一个Cached Proxy也是不错的办法。
CF-Relase是CloudFoundry的发布包，我们可以对比下V1和最近的发布包。
可见在v1版本中有大量的组件是在做Service，摊子铺的很大。而V2中将这个包袱放下，提交给各种第三方XaaS了。连接XaaS和CloudFoundry的中间组件被称为CloudFoudry Broker。v2的Service Broker和v1的完全不同。V2中的设计如下。
一个Service Broker 需要实现5个API接口，包含三方面
Service Broker的部署可以很灵活。既可以作为CloudFoundry的组件，也可以作为CloudFoundry的APP运行在CloudFoundry上。官方提供了一些Service Broker 实现实例。
GitHub repo service在企业生产环境中，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信息。
不避讳的说，部署CloudFoundry v2的难度大于v1。
在v1中有dev_setup，提供一个基于Chef的一键脚本可以轻松部署。而v2中依赖BOSH，一个一站式的解决方案。可以将CloudFoundry部署在VSphere，OpenStack和AWS上。
目前看来有三种部署方式
使用BOSH，BOSH比较重，运行起来就要费一些心力。但运转起来后可以提供健康监控，扩容的支持。由于官方不再提供新版本dev_setup，试一试CloudFoundry的成本变得很高。笔者提供了一个MicroCFv2镜像。
MicroCFv2下载 (基于v154)
运行MicroCF安装VMware Player检查网络，正常情况下虚拟机会通过DHCP获得IP地址。记下IP。编译应用需要访问外网。
介于轻博客限制，无法粘贴代码。需要复制粘贴可以访问
颜开的博客
部署Ruby APP，需要访问网络。
这个APP可以显现他自己的所有环境变量。
你可以使用浏览器访问你部署的应用。需要给浏览器设置HTTP代理。IP为MicroCFv2的IP,端口是8123.如：
这样就可以使用浏览器了。
转载http://qing.blog.sina.com.cn/tj/88ca09aa33004ep8.html