深入Cloud Foundry（上）

深入Cloud Foundry（下）

这是下半部分。

原文链接：?http://qing.weibo.com/tj/88ca09aa33000975.html

原文作者：EMC中国研究院高级研究员 ?彭麟

?

本文第一部分介绍了CloudFoundry的整体架构，并在最后花了一点篇幅简介CloudFoundry的代码组织情况，以便于读者自己去研究源代码。笔者认为开源项目最大的好处在于：当你读懂源代码、理解总体架构后，能够成竹在胸，并吸收为己用（有点类似武侠小说中的“北冥神功”）。“为己用”就是本篇要说的内容：我们使用CloudFoundry搭建自己的私有PaaS平台。

在介绍CloudFoundry之前，先说明一下，VMware在企业云应用平台的产品线上，有另外一款产品，叫做VMwarevFabric Cloud Application Platfor[1]，这和Cloud Foundry属于两个产品，分别由两批团队开发。相比较来说，选择vFabric会更令人省心省力，毕竟作为商业产品，完善很多，而且发展已久，和STS[2]深度整合。如果企业以应用为目的，不希望开发上面耗费太多人力物力，不妨考虑一下；如果选择Hard模式，打算以CloudFoundry为基础搭建私有云，那就开始吧！

本文内容所提到的CloudFoundry版本较早，，所以不可能一直紧跟着CloudFoundry的更新，造成有些内容并不是针对最新代码库，虽然我会比较新代码库来写这篇文章，但是请一定不要把本文当作按部就班的安装说明书。

去年10月份开始，CloudFoundry的主代码vcap里面新增加了个目录叫做dev_setup，Cloud Foundry大方地公开了他们的部署代码，这样大大简化了我们把CloudFoundry部署在自建数据中心的难度。如之前Figo在VMwareCloud Forum提到的一样，CloudFoundry官方用Chef[3]作为部署工具 。Chef是OrchestrationEngine的一种，可以自动化管理、部署复杂的云环境。工作过程大概就是我们需要写一系列的“recipes”，这些“recipes”描述我们需要把我们的服务器部署成什么（Apache,Mysql还是Hadoop？），然后Chef可以自己执行这些配置。现在数据中心变得越来越庞大，原来那种通过自己写脚本完成自动部署的IT管理方式日渐不堪重负，帮助管理、部署数据中心服务器集群的中间件变得越来越重要，我们统称这类型工具为OrchestrationEngine.

回到正题，如果使用了新版的CloudFoundry，可以参考dev_setup目录和dev_setup/deployments目录下面的两个README文件。基本上使用提供的脚本来部署不同的CloudFoundry组件就是一条命令的事情。

但是既然我们命题为深入CloudFoundry，那就必须深入地了解整个CloudFoundry的部署过程。 在这之前让我们先回顾第一部分里面的CloudFoundry总体架构图：

?

?

?

?

从这里可以得到这个用户的apps的一些基本情况，包括appname、url、所使用的技术、instance数目、资源情况等等。

?

再举一个简单的例子，如果我想做一个Portal列出部署在我的PaaS里面的所有应用，这个API或许可以派上用场。

?

开发一个完善的PaaS不是我们研究院的主要任务，而且搭建一个私有云需要大量的开发量，我只是简单实现了一小部分。如果真打算搭建私有云平台，要做的工作还有很多。譬如ActiveState就基于CloudFoundry，做了一个商业版的PaaS,叫做Stackato[5]，它们也是在Monitor和Manage上面做了很多工作，值得参考一下。

上下两部分的深入CloudFoundry到这里就写完了。虽然命名为深入，其实很多地方只是简单带过，对CloudFoundry的分析也只到架构一层，还有很多内容可以挖掘，譬如开发自己的Runtime，嵌入新的Service等等，以后如果必要，我可以再写文章聊聊相关内容。第二部分简单介绍了CloudFoundry的安装，以及我们实验室里面的使用，希望对大家有帮助。

?

Cloud Foundry作为业内第一个开源的PaaS，我觉得它给我们打开了一扇研究云计算环境下平台架构设计的窗户，我相信围绕它的周边开发会有一片很大的空间可以让开源界进入，这篇文章只不过是抛砖引玉。