背景
Cloud Foundry 是业界比较“资深”的PAAS云平台，它不仅支持多种框架、运行时环境，还支持在多种云环境进行部署，包括：AWS, Azure, GCP, OpenStack等。本文分享，基于阿里云进行开发、运维的实战经验。
部署Cloud Foundry首先要用到的工具是BOSH。BOSH是用来部署和管理Cloud Foundry集群的工具。 它定义了一系列管理和操作云资源的接口Cloud Provider Interface，各个云厂商需要适配自己的Provider，这就是本文的开发背景。为了让大家对BOSH和CPI有一个感性的认识，下面简要的介绍几个相关概念。
BOSH的组件结构如上图所示, 这里简单说明一下，详细说明见官方文档
- Director会解析部署命令和模板，然后调用CPI模块去创建VM（ECS）实例，实例信息会写到Registry上。
- 每个VM上装有Agent负责与Bosh交互，包括：处理Director下发的任务、上报VM的健康状态等。
- Agent从Registry拿到当前VM的信息，包括：ID, IP等。
- Director/HM和VM之间的通信是通过NATS发布和订阅消息。
重点： 这里的开发任务就是实现阿里云CPI Provider。
开发
Bosh Alicloud CPI是阿里云对CPI GO版本的实现，目前已开源，欢迎试用。
Alicloud CPI实现了对云资源以及Cloud Foundry生命周期的管理，组件结构如下图：
CPI这一层的职责比较规整，包括：模板解析、参数校验、API调用、容错与重试、返回值加工。不过，完美集成到Bosh中并高成功率的部署集群是一件很复杂的事儿，需要大量的验证和测试。
CPI Provider开发流程分为: 代码实现、Code review, 单元测试，集成测试，部署Bosh验证CPI，部署Cloud Foundry集群，在集群上部署应用。
Why DevOps
项目特点如下：
- 从事开源项目开发的小团队，没有专门的运维同学，天然的开发即运维。
- 立项之初组内没有Cloud Foundry的专家，需要快速的交付到社区去验证，得到反馈之后快速的进行迭代。
- Cloud Foundry的部署极其复杂，走一次部署流程消耗大量的人力和时间成本。需要用工具来加快开发和迭代部署的速度，减少重复的手工成本。
为了保证代码质量的前提下快速的进行迭代开发、构建、测试、部署，那么就需要一套实践方法来支撑整个流程。
How to DevOps
工具介绍
Cloud Foundry社区提供了ConcourseCI Pipeline支持各个模块的CI/CD流程, 当然这里也可以选择其他方案，比如：阿里云的CodePipeline。
所谓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个流程示意图：
Unit Test
- Source Code
-
Inputs:
- bosh-cpi-src: 项目源代码
-
Task:
- go get -v github.com/onsi/ginkgo/ginkgo 安装依赖
- ginkgo -r -skipPackage integration src/bosh-alicloud-cpi 运行unit-test
Build Candidate
- Source Code
-
Inputs:
- bosh-cpi-src: 项目源代码
- go-cpi-blobs: golang linux安装包，是运行CPI的基础依赖
- version-semver: 用来做版本控制
-
Task:
- 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: 用来存储构建物
Integration Test
- Source Code
-
Inputs:
- bosh-cpi-src: 项目源代码
- stemcell: bosh light stemcell, 配置Region和ImageId的对应关系。 同一个镜像在各个Region的分发。
- terraform-metadata: 用于测试的IaaS层基础环境，包括网络、安全组、负载均衡等。
-
Task:
- 初始化测试数据
- ginkgo src/bosh-alicloud-cpi/integration $(GINKGO_ARGS) -v 执行测试脚本
Bosh Acceptance Test
- Source Code
-
Inputs:
- pipelines: 准备进行BATs的配置文件仓库
- bats: BATs测试框架的源码仓库
- light stemcell: 维护各个region下镜像ID的配置文件
-
Task:
-
prepare-director
- 从meta-data获取，部署Bosh所需要的IaaS资源信息
动态生成用于部署Bosh的manifest文件 Source Code
-
deploy-director
- 部署Bosh Source Code
- 获取director信息，写入环境变量，供后面登陆Bosh使用 [Source Code]()
-
run-bats
- 动态生成manifest
- 部署一个batlight Job节点
- 执行bat测试
-
End-to-End Test
- Source Code
-
Inputs:
- bosh-cpi-src: 项目源代码
- blobs: 编译Job所依赖的二进制包
-
Task:
- 登陆Bosh
- 把依赖包打入Blob
- 打release包, 然后上传到Bosh
- 上传light-stemcell, cloud-config
- 部署Job
- 执行run-errand任务
Build And Destroy Director
- Source Code
-
Inputs:
- terraform-statement: terraform共享状态文件, 用来远程存储terraform执行结果
- main-tf: terraform编排模板
-
Task:
- terraform根据编排模板创建IaaS资源
- 对创建结果进行处理，生成JSON文件
- 把terraform状态文件同步到远程
最后
欢迎PaaS生态上的合作伙伴和开发者参与Cloud Foundry社区的建设，也欢迎大家来阿里云构建企业自己的PaaS平台。任何问题和建议可以在Github上提Issue。
