Director會解析部署指令和模闆，然後調用CPI子產品去建立VM（ECS）執行個體，執行個體資訊會寫到Registry上。
每個VM上裝有Agent負責與Bosh互動，包括：處理Director下發的任務、上報VM的健康狀态等。
Agent從Registry拿到目前VM的資訊，包括：ID, IP等。
Director/HM和VM之間的通信是通過NATS釋出和訂閱消息。
重點： 這裡的開發任務就是實作阿裡雲CPI Provider。
Alicloud CPI實作了對雲資源以及Cloud Foundry生命周期的管理，元件結構如下圖：
CPI這一層的職責比較規整，包括：模闆解析、參數校驗、API調用、容錯與重試、傳回值加工。不過，完美內建到Bosh中并高成功率的部署叢集是一件很複雜的事兒，需要大量的驗證和測試。
CPI Provider開發流程分為: 代碼實作、Code review, 單元測試，內建測試，部署Bosh驗證CPI，部署Cloud Foundry叢集，在叢集上部署應用。
項目特點如下：
從事開源項目開發的小團隊，沒有專門的運維同學，天然的開發即運維。
立項之初組内沒有Cloud Foundry的專家，需要快速的傳遞到社群去驗證，得到回報之後快速的進行疊代。
Cloud Foundry的部署極其複雜，走一次部署流程消耗大量的人力和時間成本。需要用工具來加快開發和疊代部署的速度，減少重複的手工成本。
為了保證代碼品質的前提下快速的進行疊代開發、建構、測試、部署，那麼就需要一套實踐方法來支撐整個流程。
所謂Pipeline就是一系列手工工作的集合，這裡包括：單元測試、建構Release包、內建測試、驗收測試、端到端測試、釋出正式Release包。簡單示意圖如下：
每一項任務就是一個Job, 每個Job由輸入、輸出和若幹Task組成。Task在運作時會拉取鏡像、啟動容器、拿到輸入、執行Task、輸出結果。
拿一次CI舉例，開發人員送出代碼到Git倉庫，Git會觸發Webhook通知CI Server；CI Server會檢查Pipelie配置，根據trigger規則觸發對應的Job，并下發給CI Worker；Work解析Tasks，拉取Docker鏡像啟動容器，執行Task；最後Work收集每個Task的結果傳回給CI Server。流程入下圖所示：
接下來介紹一下在CPI Pipeline中每個Job所負責的内容，對于類似的項目有一定借鑒意義。 CPI Pipeline包括5個主要流程，分别是Unit Test, Build Candidate, Integration Test, Acceptance Test, E2E Test。下圖是這5個流程示意圖：
<a href="https://github.com/aliyun/bosh-alicloud-cpi-release/blob/master/ci/tasks/unit-tests.sh">Source Code</a>
Inputs:
bosh-cpi-src: 項目源代碼
Task:
go get -v github.com/onsi/ginkgo/ginkgo 安裝依賴
ginkgo -r -skipPackage integration src/bosh-alicloud-cpi 運作unit-test
<a href="https://github.com/aliyun/bosh-alicloud-cpi-release/blob/master/ci/tasks/build-candidate.sh">Source Code</a>
go-cpi-blobs: golang linux安裝包，是運作CPI的基礎依賴
version-semver: 用來做版本控制
bosh2 add-blob ../go-cpi-blobs/go1.8.1.linux-amd64.tar.gz go1.8.1.linux-amd64.tar.gz 加載blob依賴
bosh2 create-release --name $cpi_release_name --version $semver --tarball $cpi_release_name-$semver.tgz 打release包,根據版本号生成release包名稱
mv $cpi_release_name-$semver.tgz ${DESC}/: 把建構物上傳到遠端位址
Outputs:
bosh-cpi-dev-artifacts: 用來存儲建構物
<a href="https://github.com/aliyun/bosh-alicloud-cpi-release/blob/master/ci/tasks/run-integration.sh">Source Code</a>
stemcell: bosh light stemcell, 配置Region和ImageId的對應關系。 同一個鏡像在各個Region的分發。
terraform-metadata: 用于測試的IaaS層基礎環境，包括網絡、安全組、負載均衡等。
初始化測試資料
ginkgo src/bosh-alicloud-cpi/integration $(GINKGO_ARGS) -v 執行測試腳本
<a href="https://github.com/cloudfoundry-incubator/bosh-cpi-certification/blob/master/shared/tasks/run-bats.sh">Source Code</a>
pipelines: 準備進行BATs的配置檔案倉庫
bats: BATs測試架構的源碼倉庫
light stemcell: 維護各個region下鏡像ID的配置檔案
prepare-director
從meta-data擷取，部署Bosh所需要的IaaS資源資訊
deploy-director
擷取director資訊，寫入環境變量，供後面登陸Bosh使用 [Source Code]()
run-bats
動态生成manifest
部署一個batlight Job節點
執行bat測試
<a href="https://github.com/aliyun/bosh-alicloud-cpi-release/blob/master/ci/tasks/run-e2e.sh">Source Code</a>
blobs: 編譯Job所依賴的二進制包
登陸Bosh
把依賴包打入Blob
打release包, 然後上傳到Bosh
上傳light-stemcell, cloud-config
部署Job
執行run-errand任務
<a href="https://github.com/aliyun/bosh-alicloud-cpi-release/blob/master/ci/tasks/build-environment.sh">Source Code</a>
terraform-statement: terraform共享狀态檔案, 用來遠端存儲terraform執行結果
main-tf: terraform編排模闆
terraform根據編排模闆建立IaaS資源
對建立結果進行處理，生成JSON檔案
把terraform狀态檔案同步到遠端