深入Cloud Foundry（下）

本文第一部分介绍了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总体架构图：

从图1中可以看出两点：

1、  CloudFoundry是完全模块化的设计，每个模块多带带存在、运转。CloudFoundry是基于Ruby开发的，那每个部分可以认为拿来即可运行，不存在编译等过程；

2、  我们需要配置换的应该是图中的箭头部分。换句话说就是如何把每个模块连接起来，使其成为一个完整的、分布式的系统。这点就是我们现在要做的事情。

如果你是用：

 

安装的CloudFoundry，那你的系统里面就应该包含了所有的子模块。

DEA, Health_Manager, Router这三个模块，代码结构比较接近：都有一个bin目录，毫无疑问里面就是可执行文件，但是打开着个文件会发现它只是个简单的link，真正的执行文件在lib下面，有对应的rb文件；而这几个模块的根目录下面都有一个config目录，里面有以模块命名的yml文件，这就是他们的配置文件。

而cloud_controller模块，之前已经说过它是个典型的RoR项目，里面的文件结构有点复杂，文件有点多，但是还是能找到config/cloud_controller.yml这个文件的；

接着就是service模块，这里会看到很多似曾相识的子目录，比如mysql,Redis, rabbit, mongodb。专业人士一看就知道是不同的服务，每个服务一个文件夹，点进这些目录看，又看到熟悉的结构了，比如bin,config, lib，很简单，和前面的DEA,Router等模块的结构一样。但是打开bin后，发现执行文件有点多，有个gateway,还有个node。（如果你是新的代码库，可能还看到个backup，顾名思义就是配置service备份工作的，不难理解，这里就不叙述了）

我们来聊聊Service模块的gateway和node。Gateway在一个servicenode里面负责处理restfulapi的相关事情，负责读入并初始化messagebus。Node是service的具体执行者，包括响应message，与底层service的交互等等。但是从配置文件来说，因为gateway负责解析初始化messagebus，所以与messagebus相关的配置信息反而放在了xxx_gateway.yml里面；而xxx_node.yml则是一些关于底层配置的信息，拿mysql_node.yml来说，就是一些max_long_query,max_long_tx这些信息。

如果我们要架构分布式的云环境，不应该选择在一台服务器里面安装所有的模块，下面简单介绍下做法：

通过研究源代码，我们知道CloudFoundry的主安装文件vcap_setup里是可以选择安装哪些组件的。所以安装全部组件应该是install这个脚本搞的鬼，我们去看看install[4]里面做了什么？

通过略读install脚本，发现它不难理解，且每一个步骤都有一个echo来说明。它分别做了以下动作：

1、  检测是否是Linux或者MacOS环境；

2、  安装依赖包；

3、  安装并启动RVM；

4、  安装Ruby；

5、  下载vcap；

6、  安装配置vcap；

7、  重启Nginx；

8、  安装Bundler。

其中注意这一行命令：

这里面的参数–a与-s。在vcap_setup的comments里面有如下定义，

也就是说，install脚本为了省去安装时的提问过程，剥夺了我们的自主选择权！那么解决方法就简单了——把这句改了，然后执行install，我们应该能看到安装脚本询问要不要安装Router？要不要安装CloudController？同样的，因为去掉了-s参数，所以在安装过程中会提示需要安装的Service类型。

下面是我们实验室中服务器的具体配置图，

Figure 2 Cloud Foundry 在ELC 实验室中的部署图

首先，我们手上没有硬件LoadBalancer，而且为了节约ip资源，我们决定只用一个外部ip，使用桥接，然后用Ngnix来做loadbalancer，所有的requests会转向4台Router。

我建议Router宜多一点，因为CloudFoundry当前的设计，Router的资源会很紧张，但是如第一部分说到那样，这问题会在以后的版本改善。目前还是多加点Router服务器吧。

然后CloudController我们用了3台，并且这三台也同时兼了Health_Manager的功能，因为CloudController主管的是控制流，资源占用不会太大。我一开始也觉得CloudController会很耗资源，因为从上一部分的工作描述来看，它负责的工作还是比较多的，但实际应用下来，结果和笔者想的相差很远。这部分需要的资源其实并不多，可能因为我们不是经常需要启动/关闭/删除instance。

后面是一个多带带的数据库服务器。在生产环境里用的是PostgreSQL，用其他也是可以的，在cloud_controller.yml里面修改就好。这是整套系统的单点，我也一度担心过，但据说CloudFoundry.com用的也是单点数据库，没存在太大问题。据说CloudFoundry在设计的时候已经注意到这里的数据流量问题。

接着是5台服务器用于Health-Manger，其中3台与CloudController公用。因为我希望多检测一点数据，用于后面的管理，所以在这里狠下了心。

DEA模块，也是5台服务器。这里算是app的主场，建议根据资源需求动态增加，CloudFoundry有很好的扩展性设计，如果某一模块吃不消了，都可以动态添加。

Service模块，同样给了5台。我们目前只用到Mysql，Postgresql和MongoDB。同样按照项目需要来加。其他Service暂时还没用上。

接着就是贯穿这套系统的MessageBus模块。CloudFoundry的所有模块都需要指定到这个MessageBus。它是基于NATS的，轻量级，很好用，但是有个问题是不支持HA/HP集群，也就是说无法配成多台Messagebus hosts。这部份据说正在开发，而既然CloudFoundry.com都能应付得了，我们私有云，一台server，应该足矣！

后面我们选几个模块看看具体的配置修改：

前面说到，我们用一台nginx来作为loadbalancer。我们整个服务器集群用的是虚拟机，这台虚拟机配双网卡，分别设为privatenetwork和vmnetwork，两网卡间采用桥接。这台服务器有双ip：10.32.105.165和192.168.1.178。我们进入这台机器，选择Nginx的一个原因是，只要安装CloudFoundry，因为Router组件是基于Nginx的，所以都会安装这个HttpServer，减少了我的工作。配置Nginx没什么特殊之处，我用了最简单的方法，设置一个upstream，采用RR来均衡负载。

Load balancer出来的request就会流到Router组件，Router.yml的配置相当简单：

需要改的只有mbus，就是把mbus指到我们的mbus服务器去。

Cloud_controller.yml看起来相当复杂，我们可以选择需要的配置修改：

 

按照配置文件里面的介绍，说这个可以不修改，默认为nil，我配置成了CloudController的ServerIp，用起来没出问题。

接着有两个重要的配置：

这两个目录是关于用户上传的apps（在Cloud Foundry里叫做Droplets），以及相关资源的目录。上一部分说到，在CloudController的当前实现，是采用一个NFS来存储这些Droplets，使它全局。所以我们在此之前，需要建立一个NFS，并且每个安装Cloud_Controller的服务器把这个NFSmount到/var/vcap/shared下。这点非常非常重要，否则会出现上文说的启动失败问题！

接下去，我们需要配一个，所有CloudFoundry组件都要配置的内容，mbus：

• 上一篇：云计算——IT界动荡中的希望
• 下一篇：深入 Cloud Foundry（上）