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状态文件同步到远程