摘要：基于的實(shí)踐一綜述參見還可參見基于的實(shí)踐之集群部署單結(jié)點(diǎn)的部署由于提供的安裝腳本，使用簡單不再陳述，大家參照一下官網(wǎng)即可，在此主要談?wù)劧嘟Y(jié)點(diǎn)集群部署的要點(diǎn)。關(guān)于，大家可參考和。

　　1. 搭建CF運(yùn)行環(huán)境并維護(hù);

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

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

　　4. 支持新的Service嘗試;

　　5. 其它待做事宜。。。

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

　　簡而言之，有了paas，開發(fā)者只需要提供源碼，即可瞬間啟動(dòng)一個(gè)企業(yè)級(jí)的web service。

　　Paas主要為server級(jí)的應(yīng)用提供運(yùn)行平臺(tái)，而不是提供強(qiáng)大的云計(jì)算能力，或者說不是提供分布式計(jì)算能力。當(dāng)然，提供分布式計(jì)算能力也會(huì)被稱為云計(jì)算，但不是我現(xiàn)在的方向。

　　CF做為一個(gè)PAAS平臺(tái)，目前已支持了以上理解的大多數(shù)基礎(chǔ)功能。但仍然有很多地方需要完善，比如router的負(fù)載均衡策略還很簡單，對(duì)應(yīng)用的監(jiān)控還比較有限。但它的確給我們提供了一個(gè)非常漂亮的架構(gòu)，使得我們有機(jī)會(huì)走近paas，而不是仍然不知道它該是什么樣的狀態(tài)。盡管，這個(gè)架構(gòu)在性能方面表現(xiàn)的還有待推敲。

　　與CF一樣類似的產(chǎn)品，比較火熱的有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實(shí)踐之： Cloud Foundry集群部署

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

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

　　下面說一個(gè)組件互聯(lián)的配置。

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

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

　　如果想啟動(dòng)多個(gè)cloud_controller和health_manager結(jié)點(diǎn)，還有兩個(gè)工作要做：

　　創(chuàng)建文件存儲(chǔ)共享和可跨主機(jī)訪問的數(shù)據(jù)庫。

　　數(shù)據(jù)庫存儲(chǔ)可使用rails框架支持的任何數(shù)據(jù)庫，筆者推薦使用mysql，運(yùn)行在兩個(gè)主機(jī)上并配置Replication功能，將cloud_controller和health_manager的數(shù)據(jù)庫配置均指向mysql-master;

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

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

　　另外一個(gè)需要特別關(guān)注的配置是本機(jī)IP，Cloud Foundry各個(gè)組件再向router注冊時(shí)是根據(jù)配置提取本機(jī)IP，默認(rèn)是127.0.0.1，必須改成實(shí)際IP，相關(guān)配置有：

　　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

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

　　對(duì)于配置文件的其它項(xiàng)，不影響集群的建立，在此不再多說，如果有問題可以與我聯(lián)系。

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

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

　　Cloud_Controller負(fù)責(zé)整個(gè)Cloud Foundry的用戶管理/應(yīng)用管理/服務(wù)管理，基于rails框架對(duì)外提供RESTFUL接口服務(wù)。我們可以通過分析一般rails應(yīng)用的方法加以分析。rails應(yīng)用的掌握個(gè)人喜歡通過MVC框架和RESTFUL接口把握。

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

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

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

　　當(dāng)然，這個(gè)應(yīng)答信息顯示的不夠全面，大家還是wireshark，我這臺(tái)電腦沒裝，暫時(shí)就不能截圖了。另外，大家也可以使用Advance RESTclient，示例：

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

　　在看代碼之前，較好再看一下數(shù)據(jù)模型。我曾經(jīng)畫了個(gè)模型圖，可惜暫時(shí)找不到了，先做個(gè)文字介紹吧。

　　cloud_controller的主要數(shù)據(jù)模型包括:

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

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