基于Cloud Foundry的PaaS开发与部署

摘要：基于的实践一综述参见还可参见基于的实践之集群部署单结点的部署由于提供的安装脚本，使用简单不再陈述，大家参照一下官网即可，在此主要谈谈多结点集群部署的要点。关于，大家可参考和。

　　1. 搭建CF运行环境并维护;

　　2. 部分代码修改和新功能扩充的工作;

　　3. 大量的应用部署测试，主要是rails/Java两类应用;

　　4. 支持新的Service尝试;

　　5. 其它待做事宜。。。

　　由于CF是PAAS平台，这里面先介绍个人对paas的粗略理解。Paas, Platform as a Service, 其主要目的是提供一个应用运行的平台，有了这个平台，开发者无需搭建应用运行环境和服务(MySQL/mongodb/Rabbitmq等)，包括硬件和软件(os/应用软件如tomcat/rails等)环境，开发者可专注代码开发，最终提供源码(或war包之类的)信息，上传至PAAS，即可运行，并可创建DNS直接提供服务，甚至可提供auto-scale，monitor，loadbalance等等运行webservice需要的一切功能。

　　简而言之，有了paas，开发者只需要提供源码，即可瞬间启动一个企业级的web service。

　　Paas主要为server级的应用提供运行平台，而不是提供强大的云计算能力，或者说不是提供分布式计算能力。当然，提供分布式计算能力也会被称为云计算，但不是我现在的方向。

　　CF做为一个PAAS平台，目前已支持了以上理解的大多数基础功能。但仍然有很多地方需要完善，比如router的负载均衡策略还很简单，对应用的监控还比较有限。但它的确给我们提供了一个非常漂亮的架构，使得我们有机会走近paas，而不是仍然不知道它该是什么样的状态。尽管，这个架构在性能方面表现的还有待推敲。

　　与CF一样类似的产品，比较火热的有heroko/openshift, 其它还有beantalk、google app engine等。

　　参见http://www.vmware.com/files/pdf/cloud/VMware-Taneja-Group-An-Overview-Of-The-Cloud-Market.pdf?

　　还可参见：http://socialcompare.com/en/comparison/platform-as-a-service-paas-for-cloud-applications-Scalable-cluster-of-services?

　　基于Cloud Foundry的PaaS实践之： Cloud Foundry集群部署

　　单结点的部署由于vmware提供的安装脚本，使用简单不再陈述，大家参照一下官网即可，在此主要谈谈多结点集群部署的要点。 (关于Cloud Foundry 的整体介绍，大家可参阅 深入 Cloud Foundry(上)?及 深入Cloud Foundry(下)?先 )

　　2011年7月时，搭建Cloud Foundry 集群时，一篇国外的博文给了两个建议：一种是在每个结点上分别安装各个组件;一种是在每个结点上安装全部组件，然后在每个结点仅启动部分组件，组件间通过配置相连，实践证明这是最方便的方法。如果是在AWS-EC2部署集群，可以将一个结点安装好后，做成AMI，然后用AMI瞬间launch一个集群，再配置一个各个组件的配置文件，一会功夫就可以建立起一个集群。

　　下面说一个组件互联的配置。

　　Cloud Foundry整体架构的核心是基于消息机制的组件互联(未必得当)，所有组件的互联通讯依靠nats-server, 这是一个用ruby实现A lightweight publish-subscribe and distributed queueing messaging system. 使用极其简单，大家参考下https://github.com/derekcollison/nats。了解了nats，就抓住了Cloud Foundry的总线，然后大家再逐个熟悉各个组件的功能，当然构建一个多结点的Cloud Foundry也就简单的多了。nats的单结点安装，只要安装好ruby运行环境后，执行gem install nats安装，再执行nats-server启动，默认监听4222。

　　所有组件的config目录下都有“组件名.yml”文件，将其中的"mbus: nats://10.134.226.8:4222/ "中的IP地址调整成启动nats-server的主机地址，如果是部署一个只有一个cloud_controller+health_manager结点，任意多个dea/router结点的集群的话，集群就配置完成了。

　　如果想启动多个cloud_controller和health_manager结点，还有两个工作要做：

　　创建文件存储共享和可跨主机访问的数据库。

　　数据库存储可使用rails框架支持的任何数据库，笔者推荐使用mysql，运行在两个主机上并配置Replication功能，将cloud_controller和health_manager的数据库配置均指向mysql-master;

　　文件存储共享，可选用NFS，但当云中主机数量很多的时候，NFS可能 效率不是最优，建议其它支持FUSE的分布式存储解决方案，比如moosefs;多个cloud_controler需要共享 droplets: /var/vcap/shared/droplets和resources: /var/vcap/shared/resources。以使用NFS为例，每个cloud_controller需要将nfs-server上的存储，mount到本机。PaaS系统真正运行起来，这两个目录增长会很快，因为存储着整个集群的应用程序副本和droplet副本，所以存储一定要大些。另外，整个集群，我们可以任意毁掉任何一台主机(当然大多数时候不是故意的)，再重新启动一个新的主机替代。但只要共享的文件存储和数据库数据不丢，整个集群就没有任何变化。所以，相信同学们一定会重视这两部分数据，定期备份到AWS-S3上，会HA啥的都不为过噢。

　　集群中多个router启动后，负载均衡是必不可少的，笔者使用过两个方案，一个是用Nginx，考虑到一个nginx并发功能支撑能力有限，可部署多个nginx;另外一种方案，可使用AWS的ELB，不过ELB给我们可配置的东西太少，好在AWS很专业，不妨一试，不过较好给几个留几个nginx混着用免得AWS再停电了，整个系统都挂了。大家有别的方案欢迎推荐哈。

　　另外一个需要特别关注的配置是本机IP，Cloud Foundry各个组件再向router注册时是根据配置提取本机IP，默认是127.0.0.1，必须改成实际IP，相关配置有：

　　cloud_controller.yml:local_route: 10.134.226.8

　　dea/config/dea.yml:local_route: 127.0.0.1

　　health_manager/config/health_manager.yml:local_route: 10.134.226.8

　　的代码最近未来得及看，但考虑到代码不断更新，但本文无法时时更新，建议大家以此类推。

　　对于配置文件的其它项，不影响集群的建立，在此不再多说，如果有问题可以与我联系。

　　介绍源码前，先介绍两个重要的内容。了解整个Cloud Foundry需要熟悉的内容很多，但最核心的东西是nats和event-machine. 关于nats上一篇已经做了介绍，大家可参考基于Cloud Foundry的PaaS实践(二) Cloud Foundry集群部署 ，安装一下执行个小示例程序便可一目了然。关于event-machine，大家可参考EventMachine-scalable-non-blocking-i-o-in-ruby 和 eventmachine_introduction_10.pdf 。简而言之，就是一个用很牛的算法(reactor)写的一个非阻塞的socket通信框架，有多种语言的实现，nats也用到。同样的，照着上面资料中的示例执行一下，就明白了。

　　有了以上的基础，我们可以开始共同看一下Cloud Foundry的核心，cloud_controller.

　　Cloud_Controller负责整个Cloud Foundry的用户管理/应用管理/服务管理，基于rails框架对外提供RESTFUL接口服务。我们可以通过分析一般rails应用的方法加以分析。rails应用的掌握个人喜欢通过MVC框架和RESTFUL接口把握。

　　首先，看一下cloud_controller/config/routes.rb:

　　按列从左至右依次为：http方法/访问路径/代码文件和函数信息/略。以第一行为例，如果cloud_controller接收到http get请求info路径信息，将使用cloud_controller/app/default_controller.rb文件中的info函数响应。以上供刚刚接触rails的同学参考。

　　了解了routers.rb的路由方法后，还可以使用wireshark工具，安装vmc(安装ruby后执行gem install vmc)，通过vmc help帮助执行vmc 命令的同时，用wireshark抓取http包，刚cloud_controller RESTFUL接口可完全把握。下面使用Linux的curl工具，显示示例包如下：

　　当然，这个应答信息显示的不够全面，大家还是wireshark，我这台电脑没装，暂时就不能截图了。另外，大家也可以使用Advance RESTclient，示例：

　　到此，我们已经可以把握全部restful接口，以及每个接口执行的路径，再列一下cloud_controller/app目录下的文件，一目了然。

　　在看代码之前，较好再看一下数据模型。我曾经画了个模型图，可惜暂时找不到了，先做个文字介绍吧。

　　cloud_controller的主要数据模型包括:

　　(临时画的简表，抱歉未添加表关系和示例数据，过两天要是翻到我写的手册就补上)。

　　表的内容不难，此处列出的只是比较主要的，可能会有变化，但相信这里的大部分东西不会大变。特别说明，service在Cloud Foundry中指的是System Service，比如Cloud Foundry会根据用户的需要，由用户执行vmc create-server mysql后，为用户创建一个mysql，然后执行vmc bind-service mysql-name app-name后，就将此服务和应用绑定，即应用可以访问VCAP_SERVICES环境变量，得到这个mysql实例的连接信息，包括用户名/密码/IP/端口啥的。这块目前Cloud Foundry支持API，用法更加简单，但原理如是。实现的信息会保存在services表中，连接信息会保存在binding_tokens表中，服务绑定信息会放在service_bindings表中，服务版本信息会保存service_configs中。大家可以执行一下命令，看看表中数据的变化即可顿悟。