Cloudfoundry的部署工具BOSH介紹

咱們知道在使用dev_setup部署cloudfoundry過程當中存在不少的重複工做，分機運行腳本不只效率低下，且cloudfoundry版本不能控制。這對於大規模的生產環境來說，部署運維的工做量很是龐大，在這種狀況下極大的限制了cloudfoundry推向產品化的發展。爲了解決這個問題，Vmware本身研發了BOSH做爲自動化部署cloudfoundry，它可以給cloudfoundry的部署帶來極大的便利。

   官方文檔給BOSH的定義是：BOSH是一個針對大規模分佈式系統的部署和生命週期管理的開源工具，其基礎是「a tool of release engineering"。由其定義能夠看出，雖然BOSH的誕生出自cloudfoundry的部署難題，但BOSH能作的不僅是部署cloudfoundry這一個產品。別的分佈式系統只要提供給bosh一個release，BOSH同樣能夠作到系統的部署和生命週期的管理。因此，這裏不要陷入一個誤區。

   這篇文檔適合剛開始接觸BOSH，並對cloudfoundry相對了解的開發人員。本文的基礎是BOSH的官方文檔，其中加入了我對相關概念的認識。其中的不足之處，還望指正。

    主要介紹了以下的幾部份內容：

 

1. BOSH架構及各組件介紹
2. BOSH關鍵名詞概念
3. BOSH運行機制

   主要參考資料：

 

 

1. 官方BOSH文檔https://github.com/cloudfoundry/oss-docs/blob/master/bosh/documentation/documentation.md（信息量很大）
2. Dr.Nic的BOSH神級入門教程彙總https://github.com/drnic/bosh-getting-started 

 

  看完本文若是你想着手開始部署BOSH的話：

 

1. 若是你使用的IaaS是vsphere，官方提供了vsphere的BOSH部署教程。http://cloudfoundry-doc.csdn.net/deploy/vSphere.html
2. 若是是使用的IaaS是AWS，能夠參考：http://blog.cloudfoundry.org/2012/09/06/deploying-to-aws-using-cloud-foundry-bosh/
3. 若是是在openstack上嘗試搭建，能夠看我寫的：《在openstack上使用Bosh部署cloudfoundry集羣（上）》

    

4. 若是使用了除上述三種平臺以外的IaaS，就須要涉及CPI的開發。有關CPI的知識，能夠看我寫的：

 

一  BOSH架構及各組件介紹

咱們先來看BOSH的總架構圖，有一個直觀的概念：     

 

對Cloudfoundry相對熟悉的讀者能夠發現，BOSH在總體架構上跟CF有着很多類似之處。圖中的Message Bus組件沒有明確指出這裏使用的是哪種消息中間件，實際上BOSH仍使用了NATS作消息部分的處理。主要的組件有以下幾個，咱們逐一分析。

• CLI

CLI相似於CF的vmc，是用戶客戶端的一個命令終端，它提供了BOSH的命令界面。命令的格式是：

$ bosh [--verbose] [--config|-c<FILE>] [--cache-dir <DIR>]
      [--force] [--no-color] [--skip-director-checks] [--quiet]
      [--non-interactive]

有關CLI的完整命令介紹能夠參見BOSH官方文檔的BOSHCommand Line Interface部分。

• Director 

Director組件是BOSH的核心，其做用是負責虛擬機的建立、部署和其餘軟件和服務生命期的管理。若是和CF類比的話，Director扮演的角色有點相似於CF的cloud_controller。

• Agent

Agent運行在已經建立出的VM上，每一個BOSH建立的虛擬機都一個Agent。它是BOSH在VM上的代理，經過從Director獲取配置信息，使虛擬機分配不一樣的角色。好比，在部署cloudfoundry集羣的時候，我須要添加一個DEA節點。這時BOSH先會建立並啓動一個VM，其中也運行着BOSH的Agent。而後Director就會發送一個命令到VM的Agent，明確告知這個VM須要安裝有關DEA的組件和軟件包，以及詳細的配置信息。Agent就會根據這些信息建立一個配置好的DEA節點，這樣VM就分配好了角色。

• Health Monitor

HealthMonitor從Agent接收狀態和生命週期信息，而且能夠發送警告報警。這裏的Health Monitor是一個簡單的事件機制，當一個組件更新時，不會產生報警。

• Blobstore

Blobstore是用來存儲用戶上傳的Release。用戶經過CLI的上傳Release指令，經過Director將Release存儲到Blobstore中。當你對上傳的Release進行部署時，BOSH將在Blobstore中排列這些編譯包和存儲結果。當BOSH部署一個job到VM上時，Agent將從Blobstore中拿出指定的BOSH Jobs和相關的資源包。

BOSH也使用Blobstore做爲大型有效載荷的中間存儲，好比日誌文件，Agent處超過消息總線最大尺寸的輸出。

如今有三種Blobstore支持BOSH：Atmos、S三、simple blobstore server。

 

• db

BOSH用來存儲有關VM的元數據的數據庫。

 

 

• IaaS interface

這裏就是BOSH CPI（Cloud Provide Interface）的部分。CPI封裝了一套IaaS的API，它使得BOSH可以經過對CPI的調用從而實際調用IaaS的API。CPI包括了下面的方法：

 

 

create_stemcell / delete_stemcell
create_vm  / delete_vm  / reboot_vm
configure_networks
create_disk / delete_disk / attach_disk / detach_disk

有關的詳細分析，請見文章開頭的參考文檔4

 

二 BOSH關鍵名詞概念

• stemcell

一個集成了Agent的VM模板，BOSH建立的VM就是以這個模板來進行建立的。Director經過CPI建立VM以前須要上傳stemcell，也就是說stemcell處於部署過程的開始階段，它初始化了BOSH的運行環境。stemcell在建立VM時會傳遞網絡和存儲的配置，以及NATS和Blobstore的位置

• Releases

BOSH是一個release engineering的工具，其面向的對象天然是Releases。BOSH 的一個Release包含了源碼，配置信息和啓動腳本等內容。

目錄	內容
jobs	有關job（做業）的定義
packages	有關資源包的定義
config	release的配置文件
releases	最終的release
src	源代碼
blobs	大的源代碼包

 

jobs：jobs是packages的具體實現，其中包括了運行資源包的二進制文件的配置和啓動腳本，官方的翻譯是「做業」。job和VM的關係是一對多的關係，也就是說每個VM上只能對應一個job。拿Cloudfoundry的release舉例來講，總共有包括Cloud_controller，DEA，health_manager，router，NATS等jobs。每當一個VM啓動後，Agent就根據Director分配的job，讓VM擔當不一樣的任務。BOSH使用了monit監視job的進程。

pakages：packages是一個源代碼和編譯安裝腳本的集合。

src：包含了package裏的源代碼。

blobs：最終的release會放置於releases文件下面，可是可能會出現文件目錄下出現過多的腫脹二進制文件。因此，這裏會把這些較大的文件放在blobs裏，而後在上傳到blobstore時一塊兒上傳過去。

這裏可能會有一個理解誤區。看到Release這個單詞，可能會有一種感受是BOSH是將整個release上傳到blobstore而後進行部署。實際上並非這樣。BOSH的一個release也是一個工程，對於這個工程，還須要使用命令bosh create release以後BOSH才能使用。因此，BOSH的Release也須要生成最終的一個release，而後在上傳到Blobstore中。

此外，在一個BOSH的release裏，一般都使用git進行源碼管理。

 

三 BOSH運行機制

 

 

 這張圖很好的說明了BOSH的運行機制。右邊是cloudfoundry的release，它包含了cloudfoundry的jobs。上面在介紹組件時已經講到一些，在這裏咱們在詳細總結一下關鍵的幾個運行步驟。

• VM的鏡像Stemcell

在BOSH部署的整個週期處在最上環的是stemcell的上傳。首先開發人員經過命令bosh download stemcell將官方提供的stemcell下載到本地，而後BOSH經過調用CPI的create_stemcell方法，將本地的stemcell上傳至IaaS的鏡像存儲。這時，BOSH已經具備了一個VM的模板，其中有最關鍵的bosh agent。

• 部署過程當中的package編譯

Director首先會查看是否存在編譯的版本，若是不存在，Director就會啓動一個VM做爲編譯機。從blobstore中取出後編譯，而後將編譯好的package放在blobstore裏。在這裏，package的編譯依靠的是一個叫作packaging的腳本，它跑在編譯機上，會從agent中獲得兩個變量：BOSH_INSTALL_TARGET和BOSH_COMPILE_TARGET。第一個變量說明在何處安裝package生成的文件，會被設置成/var/vcap/data/packages/<package name>/<package version>；第二個變量說明哪一個文件包含了源代碼。

• 新增節點的建立

BOSH會根據主配置文件bosh_manifest.yml獲得新增節點的job信息以及相關網絡和資源池信息，並根據這些信息配置部署新增節點。

咱們仍是拿上面說到的DEA的例子。這時BOSH先會調用CPI，根據網絡資源池等信息建立並啓動一個VM，其中也運行着BOSH的Agent。而後Director就會根據job的信息發送一個命令到VM的Agent，明確告知這個VM須要安裝有關DEA的組件和軟件包，以及詳細的配置信息。Agent就會根據這些信息建立一個配置好的DEA節點，這樣VM就完整的部署完成。

因此咱們看出，bosh_manifest.yml是整個BOSH的關鍵配置信息，詳細的對分佈式系統（cloudfoundry）的部署進行了安排計劃。目前因爲龐大系統的部署信息量較大，manifest的配置是一個比較麻煩的工做，不過在未來相信這一點必定會進行改善。下面是基於vsphere部署bosh的一個manifest模板：

https://github.com/cloudfoundry/oss-docs/blob/master/bosh/tutorial/examples/bosh_manifest.yml

 

從總體上看，BOSH的運行主要是Director和blobstore的交互，director和agent的交互。其中設計的精妙之處在於stemcell內嵌agent的作法，從而作到VM執行不一樣的部署任務。因此，學習BOSH應在嘗試搭建的基礎上，儘可能搞懂bosh agent和director交互的原理，才能理解BOSH在實現release engineering的設計思路。從而才能進一步爲本身研發CPI，實現cloudfoundry的自動部署鋪平道路。