cloudfoundry 2.0 on CentOS 6 小结

概况

cloudfoundry 2.0 正式发布已经有一周多了，相信想研究它的人也不少。 但对于最新的2.0，官方仅给出了一种基于Iaas的部署方式，大批量的创建ubuntu 虚拟机，然后使用cloudfoundry的发行包（cf-release）批量部署cloudfoundry。

这个需要有openstack，Vsphere 等底层IaaS作为支持，如果没有IaaS, 那就只能自己摸索通过源代码安装 ，但相当一部分源代码基于ubuntu 发行版开发，如果物理机的操作系统不是ubuntu发行版，根本运行不起来。

笔者从cloudfoundry 1.0起就一直在研究它，但苦于没有IaaS，曾经将1.0版本适配到centos上( vcap )， 于是这次又对2.0干了同样的事情，但这次难度更大。

如果你是ubuntu系统（官方声明最好是10.04）基本所有组件安装后经过合理的配置，都可以正常运行。 但如果是其他linux发行版，以本文中的centOS为例，除了配置问题，还会碰到各种因为操作系统引起的bug需要修改源代码。

在安装成功后，我们还自行开发了一个cloudfoundry的web界面，详情：console

以下是一个维持cloudfoundry基本正常运行所必须组件的实现原理和安装配置细节，同时也包含一些在centOS等非ubuntu linux 发行版上修复BUG的提示。 粗略的技术细节都可以在各组件源代码代码的readme里面找到，各组件说明里面只会提一点readme里面没讲到的。至于更多的技术细节则需要靠各位自己阅读源代码了。

cloudfoundry 组件简介

Cloudfoudnry 1.0已于在2013年1月底停止开发与维护。现在网上许多cloudfoundry的文章讲的都是跟1.0有关的内容，在此指出一些主要的区别。

• 1.0中router使用的是nginx+lua+ruby server的方式，2.0使用了go语言gorouter，据称支持了websocket且极大提升了性能。
• 2.0中cloud contoller新增了quota，org，space等新的概念，更方便的进行权限和资源管理。
• 1.0中为应用打包使用的是stager组件，2.0中移除了该组件，将打包功能加入到dea中，并将所有语言的打包程序以submodule的形式放在buildpacks/vendors 目录下。
• 完全重写了health manager
• 1.0里 dea可以独立运行，一个dea负责的所有app都以子进程的形式挂在dea主进程下。但2.0之后dea强依赖于warden提供的安全容器来运行app了

下面是cloudfoundry 2.0的架构示意图，

NATS

CloudFoundry是一个多模块的分布式系统，支持模块自发现，错误自检，且模块间低耦合。其核心原理就是基于消息发布-订阅机制。

而NATS则是支持这个机制的最关键的消息系统，它是cloudfoundry中最核心的组件。

整个cloudfoundry的消息channel有上百个，无法在此一一列举，请参考nats链接组件的两个例子获得对这个组件最直观的印象

Router

负责处理分发所有的请求到相对应的模块，包括来自外部用户对app的请求和平台内部控制请求。

整个模块的主要逻辑就是处理来自这些请求的处理者的注册请求，注册逻辑已经在NATS中讲过了，不再赘述。router的安装和配置都非常轻松，仅需要修改下NATS的相关配置就可以启动了，参考 gorouter 的安装和配置

值得一提的是2.0用了go重写了1.0用nginx+lua嵌入脚本的router 改称gorouter 号称比1.0有4X的性能提升，如果属实，go前途无量。

Warden

warden 在操作系统上层提供轻量级的运行应用的虚拟容器，为平台提供安全支持。

warden及平台安全

DEA

接收来自cloud controller的指令，根据指令使用warden提供的虚拟容器对应用进行打包，运行等关键操作。

dea和buildpack

Cloud Controller

Cloud Controller是CloudFoundry的管理模块。对外提供平台全部的api

Cloud Controller

UAA

全称是User Account and Authentication，负责用户账户和验证

UAA

Health Manager

负责检查各个组件的状态

Health Manager

其他组件

• Services: cloudfoundry为应用提供的各类服务，如mysql，memcached，由于时间原因+非必要，我暂时没有支持。
• Syslog Aggregator：归集log的组件，非必要，也没有支持
• Collector： 监听nats中的各类消息来监控各组件的运行状态，非必要，也没有支持。
• cf： 官方的命令行客户端。gem install cf 即可。
• eclipse STS 插件： 官方的eclipse插件。跟cf一样也同样属于客户端性质。

总结：给cloudfoundry做centos的适配是个吃力不讨好的事情，费劲千辛万苦DEBUG却并没有添加什么新功能， 但在这个过程中不可避免的需要深入了解cloudfoundry的架构和细节，也算是不小的收获。 纵使以后用BOSH+IaaS安装cloudfoundry遇到bug也会轻松一点，不至于惊慌失措。

致谢

合作研究cloudfoundry的实习生：zhaodch