摘要：基于的實踐一綜述參見還可參見基于的實踐之集群部署單結點的部署由于提供的安裝腳本，使用簡單不再陳述，大家參照一下官網即可，在此主要談談多結點集群部署的要點。關于，大家可參考和。

　　1. 搭建CF運行環境并維護;

　　2. 部分代碼修改和新功能擴充的工作;

　　3. 大量的應用部署測試，主要是rails/Java兩類應用;

　　4. 支持新的Service嘗試;

　　5. 其它待做事宜。。。

　　由于CF是PAAS平臺，這里面先介紹個人對paas的粗略理解。Paas, Platform as a Service, 其主要目的是提供一個應用運行的平臺，有了這個平臺，開發者無需搭建應用運行環境和服務(MySQL/mongodb/Rabbitmq等)，包括硬件和軟件(os/應用軟件如tomcat/rails等)環境，開發者可專注代碼開發，最終提供源碼(或war包之類的)信息，上傳至PAAS，即可運行，并可創建DNS直接提供服務，甚至可提供auto-scale，monitor，loadbalance等等運行webservice需要的一切功能。

　　簡而言之，有了paas，開發者只需要提供源碼，即可瞬間啟動一個企業級的web service。

　　Paas主要為server級的應用提供運行平臺，而不是提供強大的云計算能力，或者說不是提供分布式計算能力。當然，提供分布式計算能力也會被稱為云計算，但不是我現在的方向。

　　CF做為一個PAAS平臺，目前已支持了以上理解的大多數基礎功能。但仍然有很多地方需要完善，比如router的負載均衡策略還很簡單，對應用的監控還比較有限。但它的確給我們提供了一個非常漂亮的架構，使得我們有機會走近paas，而不是仍然不知道它該是什么樣的狀態。盡管，這個架構在性能方面表現的還有待推敲。

　　與CF一樣類似的產品，比較火熱的有heroko/openshift, 其它還有beantalk、google app engine等。

　　參見http://www.vmware.com/files/pdf/cloud/VMware-Taneja-Group-An-Overview-Of-The-Cloud-Market.pdf?

　　還可參見：http://socialcompare.com/en/comparison/platform-as-a-service-paas-for-cloud-applications-Scalable-cluster-of-services?

　　基于Cloud Foundry的PaaS實踐之： Cloud Foundry集群部署

　　單結點的部署由于vmware提供的安裝腳本，使用簡單不再陳述，大家參照一下官網即可，在此主要談談多結點集群部署的要點。 (關于Cloud Foundry 的整體介紹，大家可參閱 深入 Cloud Foundry(上)?及 深入Cloud Foundry(下)?先 )

　　2011年7月時，搭建Cloud Foundry 集群時，一篇國外的博文給了兩個建議：一種是在每個結點上分別安裝各個組件;一種是在每個結點上安裝全部組件，然后在每個結點僅啟動部分組件，組件間通過配置相連，實踐證明這是最方便的方法。如果是在AWS-EC2部署集群，可以將一個結點安裝好后，做成AMI，然后用AMI瞬間launch一個集群，再配置一個各個組件的配置文件，一會功夫就可以建立起一個集群。

　　下面說一個組件互聯的配置。

　　Cloud Foundry整體架構的核心是基于消息機制的組件互聯(未必得當)，所有組件的互聯通訊依靠nats-server, 這是一個用ruby實現A lightweight publish-subscribe and distributed queueing messaging system. 使用極其簡單，大家參考下https://github.com/derekcollison/nats。了解了nats，就抓住了Cloud Foundry的總線，然后大家再逐個熟悉各個組件的功能，當然構建一個多結點的Cloud Foundry也就簡單的多了。nats的單結點安裝，只要安裝好ruby運行環境后，執行gem install nats安裝，再執行nats-server啟動，默認監聽4222。

　　所有組件的config目錄下都有“組件名.yml”文件，將其中的"mbus: nats://10.134.226.8:4222/ "中的IP地址調整成啟動nats-server的主機地址，如果是部署一個只有一個cloud_controller+health_manager結點，任意多個dea/router結點的集群的話，集群就配置完成了。

　　如果想啟動多個cloud_controller和health_manager結點，還有兩個工作要做：

　　創建文件存儲共享和可跨主機訪問的數據庫。

　　數據庫存儲可使用rails框架支持的任何數據庫，筆者推薦使用mysql，運行在兩個主機上并配置Replication功能，將cloud_controller和health_manager的數據庫配置均指向mysql-master;

　　文件存儲共享，可選用NFS，但當云中主機數量很多的時候，NFS可能 效率不是最優，建議其它支持FUSE的分布式存儲解決方案，比如moosefs;多個cloud_controler需要共享 droplets: /var/vcap/shared/droplets和resources: /var/vcap/shared/resources。以使用NFS為例，每個cloud_controller需要將nfs-server上的存儲，mount到本機。PaaS系統真正運行起來，這兩個目錄增長會很快，因為存儲著整個集群的應用程序副本和droplet副本，所以存儲一定要大些。另外，整個集群，我們可以任意毀掉任何一臺主機(當然大多數時候不是故意的)，再重新啟動一個新的主機替代。但只要共享的文件存儲和數據庫數據不丟，整個集群就沒有任何變化。所以，相信同學們一定會重視這兩部分數據，定期備份到AWS-S3上，會HA啥的都不為過噢。

　　集群中多個router啟動后，負載均衡是必不可少的，筆者使用過兩個方案，一個是用Nginx，考慮到一個nginx并發功能支撐能力有限，可部署多個nginx;另外一種方案，可使用AWS的ELB，不過ELB給我們可配置的東西太少，好在AWS很專業，不妨一試，不過較好給幾個留幾個nginx混著用免得AWS再停電了，整個系統都掛了。大家有別的方案歡迎推薦哈。

　　另外一個需要特別關注的配置是本機IP，Cloud Foundry各個組件再向router注冊時是根據配置提取本機IP，默認是127.0.0.1，必須改成實際IP，相關配置有：

　　cloud_controller.yml:local_route: 10.134.226.8

　　dea/config/dea.yml:local_route: 127.0.0.1

　　health_manager/config/health_manager.yml:local_route: 10.134.226.8

　　的代碼最近未來得及看，但考慮到代碼不斷更新，但本文無法時時更新，建議大家以此類推。

　　對于配置文件的其它項，不影響集群的建立，在此不再多說，如果有問題可以與我聯系。

　　介紹源碼前，先介紹兩個重要的內容。了解整個Cloud Foundry需要熟悉的內容很多，但最核心的東西是nats和event-machine. 關于nats上一篇已經做了介紹，大家可參考基于Cloud Foundry的PaaS實踐(二) Cloud Foundry集群部署 ，安裝一下執行個小示例程序便可一目了然。關于event-machine，大家可參考EventMachine-scalable-non-blocking-i-o-in-ruby 和 eventmachine_introduction_10.pdf 。簡而言之，就是一個用很牛的算法(reactor)寫的一個非阻塞的socket通信框架，有多種語言的實現，nats也用到。同樣的，照著上面資料中的示例執行一下，就明白了。

　　有了以上的基礎，我們可以開始共同看一下Cloud Foundry的核心，cloud_controller.

　　Cloud_Controller負責整個Cloud Foundry的用戶管理/應用管理/服務管理，基于rails框架對外提供RESTFUL接口服務。我們可以通過分析一般rails應用的方法加以分析。rails應用的掌握個人喜歡通過MVC框架和RESTFUL接口把握。

　　首先，看一下cloud_controller/config/routes.rb:

　　按列從左至右依次為：http方法/訪問路徑/代碼文件和函數信息/略。以第一行為例，如果cloud_controller接收到http get請求info路徑信息，將使用cloud_controller/app/default_controller.rb文件中的info函數響應。以上供剛剛接觸rails的同學參考。

　　了解了routers.rb的路由方法后，還可以使用wireshark工具，安裝vmc(安裝ruby后執行gem install vmc)，通過vmc help幫助執行vmc 命令的同時，用wireshark抓取http包，剛cloud_controller RESTFUL接口可完全把握。下面使用Linux的curl工具，顯示示例包如下：

　　當然，這個應答信息顯示的不夠全面，大家還是wireshark，我這臺電腦沒裝，暫時就不能截圖了。另外，大家也可以使用Advance RESTclient，示例：

　　到此，我們已經可以把握全部restful接口，以及每個接口執行的路徑，再列一下cloud_controller/app目錄下的文件，一目了然。

　　在看代碼之前，較好再看一下數據模型。我曾經畫了個模型圖，可惜暫時找不到了，先做個文字介紹吧。

　　cloud_controller的主要數據模型包括:

　　(臨時畫的簡表，抱歉未添加表關系和示例數據，過兩天要是翻到我寫的手冊就補上)。

　　表的內容不難，此處列出的只是比較主要的，可能會有變化，但相信這里的大部分東西不會大變。特別說明，service在Cloud Foundry中指的是System Service，比如Cloud Foundry會根據用戶的需要，由用戶執行vmc create-server mysql后，為用戶創建一個mysql，然后執行vmc bind-service mysql-name app-name后，就將此服務和應用綁定，即應用可以訪問VCAP_SERVICES環境變量，得到這個mysql實例的連接信息，包括用戶名/密碼/IP/端口啥的。這塊目前Cloud Foundry支持API，用法更加簡單，但原理如是。實現的信息會保存在services表中，連接信息會保存在binding_tokens表中，服務綁定信息會放在service_bindings表中，服務版本信息會保存service_configs中。大家可以執行一下命令，看看表中數據的變化即可頓悟。