《企业级容器云架构开发指南》—1.4.2　老牌的Cloud Foundry

1.4.2　老牌的Cloud Foundry

Cloud Foundry是PaaS平台中最古老的产品，其特点是整个功能分层比较好，PaaS平台所应该具备的功能特点基本上Cloud Foundry都包含。自从Cloud Foundry基金会成立以后， IBM、惠普、SAP等巨头纷纷加入，有点抱团取暖的感觉，但对于IBM、惠普、SAP来说，作为后来者选择加入基金会却是一个无奈的选择，Cloud Foundry只是巨头们PaaS战略的一部分而已，所以这些巨头在Docker时代又各自有了新的方向，Cloud?Foundry很可能逐渐没落。

目前不能在裸机上运行是Cloud Foundry的一个缺陷，因为当时的设计理念是遵循比较标准的IaaS、PaaS、Saas的分层构架而来的，底层必须有一个PaaS平台支撑，所以其必须基于开放的云构架才可以搭建PaaS。如图1-10所示的架构图，Cloud Foundry中位于最下面的BOSH层承担了PaaS平台和底层IaaS平台对接的功能，可以对接公有云或者私有云IaaS平台。

每个在Cloud Foundry中运行的应用都被称为Droplet，它也是容器化的。但Cloud Foundry没有使用Docker，因为Docker出来得晚，也没有用LXC，背后最主要的原因是LXC过于庞大，而Cloud?Foundry只需要其中的一小部分功能，并且要求很容易对应用进行测试，所以Cloud Foundry自己开发了一套容器框架——Warden，其与Docker类似。负责Droplet管理的Droplet Execution Agent（DEA）调用Warden接口完成Droplet对应的容器的创建和管理流程。DEA部署在所有物理节点上（来自IaaS层的资源），这就形成了DEA Pool——容器运行时的可调度资源池。

图1-10　容器化PaaS平台：Cloud Foundry

Cloud Foundry也提供了类似Docker的镜像打包工具，同时提供了包含Java、PHP等常见语言所开发的应用的标准化镜像打包工具。但Cloud?Foundry没有提供更多的基础中间件的镜像，也没有提供类似Docker公共镜像仓库的机制以供大家分享和下载镜像，每个用户需要自己制作打包项目中所用到的各种镜像。众所周知，打包制作镜像这种任务的工作量和技术难度都很高，因此也导致了Cloud Foundry当前的状态——问世很久却一直没有在各个行业当中得到大规模推广并赢得用户口碑。

那么运行在DEA Pool里的应用如何与外部的服务互联互通？这就需要通过Service Gateway和Service Connector提供的功能来连接对内和对外服务。例如，一个外部的Redis服务要先注册到Cloud?Foundry上，才能随后被DEA Pool里的应用所访问，因此Cloud?Foundry不是一个非常完整的PaaS平台，这是它最大的缺陷，但是PaaS平台必须具备的功能，如智能路由、用户认证及授权、健康检查、云控制等都相对完备地实现了。因此，Cloud Foundry作为PaaS的鼻祖产品，相对还是比较完善的。此外，目前Cloud Foundry最大的缺陷是没有用Docker，但其新的版本也开始对Docker进行支持，未来Docker也可以运行在DEA Pool里。