本文第一部分介紹了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（上）