Cloud Foundry：從開發到運維

[譯注]本文作者劉曉光   VMware 上海研發中心資深系統工程師。負責Cloud Foundry釋出管理和cloudfoundry.com運維支援。關注Linux、虛拟化、Infrastructure as a Service等技術領域。

代碼進入cf-release的過程

，這就是我們所說的cf-release。在撰寫本文時，最新Cloud Foundry release 版本為v127。

Cloud Foundry 由數十個元件構成，比如Router， Cloud Controller，DEA等。基本上每個元件都在自己獨立的git repository中進行開發和版本管理。而cf-release作為一個獨立的repository，和其它元件的repository是什麼關系 呢？實際上cf-release通過git中的submodule引用了其它的repository。進入cf-release的src目錄 （https://github.com/cloudfoundry/cf-release/tree/master/src），你就會看到哪些元件的

repository進入了cf-release，以及其對應的commit位置。Cloud Foundry 的每次釋出，其實就是各個元件在自己的repository中向cf-release輸出（bump）新的commit點，以使自己的新版本代碼進入 cf-release中，再由BOSH工具對新的代碼樹進行打包，生産新的release manifest 檔案的過程。

cf- release這個repository上的任何變更也是要經過Gerrit來審閱的。負責這個repository的審閱的工作是由SRE（Site Reliability Engineer）團隊來承擔的。SRE就是Cloud Foundry中的DevOps，負責線上環境cloudfroundry.com的部署、監控、故障解決，性能管理等工作。SRE 審閱時不會重複看那些已經在元件級repository上審閱和測試過的細節問題，而是從運維的角度，重點看這些元件的行為變更是否對線上環境造成負面影響，是否遵從了運維最佳實踐等問題。

cf-release部署到cloudfoundry.com的全過程

細心的cloudfoundry.com的使用者可能已經知道，cloudfoundry.com網站通常每周維護兩次，時間分别是周三和周五的上午。 每次維護我們都會把最新版的cf-release推送到cloudfoundry.com網站。下面就給大家詳細介紹一下整個部署過程。

每個新版本在正式部署前，都要經曆Dev環境測試，Staging環境測試，然後才能部署到生産環境。

<a href="http://cnblog.cloudfoundry.com/wp-content/uploads/2013/04/Picture1.jpg"></a>

1. Dev環境

在正式部署的兩個工作日前，cf-release repository的更新會暫時截止。SRE開始在Dev環境中對目前最新的cf-release進行測試。Dev環境是一個小型化的Cloud Foundry開發環境，運作在vSphere上，大概有40到50個虛拟機構成。 保證每個元件都獨立運作在一個虛拟機上。整個環境也是由BOSH進行管理。限于篇幅，這裡不對BOSH的用法做詳細解釋。大家如果有興趣可以參考 Cloud Foundry網站上的文章。

首先要建立一個新的cf-release。 用git pull同步一下cf-release repository最新的内容到本地。然後仔細檢查一下git log，確定從上一個版本到現在的新的變更都在項目的釋出計劃中，并且明确這些變更帶來的影響，以及是否要修改BOSH deployment manifest 檔案。

cd cf-release

git checkout master

./update

git log

這些都清楚了的話，就将master的内容合并的built分支中，執行bosh create release指令建立一個新的release。

git checkout built

git merge master

git push origin built

bosh create release

假設目前在cloudfoundry.com上運作的版本是v127（下同）。那麼剛剛建立出的release版本号會是v127.1- dev。

首先把 Dev環境初始化成v127。對于目前的Cloud Foundry版本來說，要用到50個虛拟機。其中一些關鍵元件的部署數量和功能見下表：

<a href="http://cnblog.cloudfoundry.com/wp-content/uploads/2013/04/Picture2.jpg"></a>

表1 Dev環境主要元件

用bosh upload指令上傳這個新的release到DEV環境，修改deployment manifest 檔案以采用新的release版本，當有元件的屬性發生變化時還要在manifest檔案中的properties部分做好相應的修改。然後用bosh deploy指令部署新的版本。BOSH會自動對比目前使用的release （v127）和即将部署的release（v127.1-dev）的差異，更新那些有變化的元件：

bosh upload release

bosh edit deployment

bosh deploy

部署完成後，執行前面提到的End-to-End測試工具Yeti，對目前的DEV環境做全面的測試。如果測試到任何問題，SRE會同相關元件的開發團隊一起排查，找到原因并修複問題。如果發現是軟體的bug，還要等修複bug後從頭進行前面的整個過程。

2. Staging環境

Staging環境作為生産環境的版本驗證和問題複現平台，在硬體型号、規模以及網絡環境等各個方面都非常接近生産環境。在正式部署的一天前，SRE會在該環境中對cf-release進行測試。

上。 執行git push将新的yml檔案上傳,并在目前位置加一個代表版本号的tag：

bosh create release –final

git add releases/appcloud-128.yml

git commit -a

git tag v128

git push –tags

這時所有人都可以從GitHub的repository中的built分支看見這個新的release了。經過其他人（通常是另外一個SRE）确認該release可用後，就可以把它合并到master了。

git pull –rebase

git submodule update –recursive

git merge built –no-ff

git push origin master

這個時候，新的cf-release就可以被公衆下載下傳并在自己的環境中部署了。後面的Staging環境和生産環境的部署，用的都是這個 GitHub中的版本。

Staging和生産環境的部署都要由至少兩名SRE一起完成。這樣做一方面是可以分擔工作量，但更主要的是避免人為錯誤的發生。在開始Staging環境的部署前，SRE會用一個腳本程式通過NATS向所有DEA發一個消息，獲得并儲存目前所有在DEA上運作的app清單。這樣做的目的是為了與部署後的情況進行對比。如果app的運作狀态發生明顯變化，很可能是新版本部署中發生了問題。部署的過程與DEV環境類似，相同的部分這裡就不再累述。

整個部署過程需要的時間依更新的元件多少以及這些元件的執行個體數量而不同。比如某個版本隻更新了stager的話，整個部署十多分鐘就可以結束。但如果新版本中有DEA的更新，則至少要幾個小時了。說到這裡，大家可能比較關心這麼長的更新過程是否會帶來長時間的系統停機。其實是不會的，BOSH采用的是滾動的更新方式，即每次隻更新一個元件。每個元件有多個執行個體時每次隻更新一部分。再加上元件設計時都考慮到了備援性和平滑更新的問題。是以在整個部署過程中，系統基本上都是可用的。對于極少數單執行個體元件，其負責的功能也隻會出現幾分鐘的不可用狀态。

部署完成後，SRE會再導出目前在運作的app清單并與之前的清單對比。 如果沒發現大的不一緻，接下來會用壓力測試工具對Staging環境進行15分鐘的壓力測試，并記錄一些性能資料。這些性能資料有助于讓我們了解各個版本對在性能上的差異。

同樣的，如果整個過程遇到任何問題，SRE和相關開發人員又要一起努力了。由于第二天就要進行生産環境的部署，這時如果發現了問題，時間就會非常緊張。好在這種情況并不多，而且我們的開發團隊也是非常給力，有問題通常能很快找到原因并修複。

3. 生産環境

由于前面做了這麼多準備工作，生産環境的部署也會水到渠成。一般來說絕大多數問題都會在前面兩個環境裡被測出過了，是以到了生産環境部署的時候就會順利很多了。部署過程大同小異，就不重複講了。但其實Staging環境和生産環境還是不大一樣，主要差異就在使用者的app上。生産環境上跑的是使用者真實的app，而 Staging環境上也有大量的app，卻隻是内部寫的一些測試程式。為了尊重使用者的權益，我們内部嚴格禁止将使用者的app程式代碼、資料甚至是log從生産環境導出到非生産環境。這就使得有些問題在Staging環境還是測不出來，非要到實際上線的時候才暴露出來。另外有些問題是要在程式運作了相對長的時間後才會暴露出來，是以部署完成也不能松懈。而下一輪新版本的部署工作也很快就開始了。

希望這些内容能對你了解Cloud Foundry社群和cloudfoundry.com有所幫助。希望能有更多的開發者關注Cloud Foundry，并參與到Cloud Foundry開發中來。