DevOps助力云原生应用开发实战分享

背景

Cloud Foundry 是业界比较“资深”的PAAS云平台，它不仅支持多种框架、运行时环境，还支持在多种云环境进行部署，包括：AWS, Azure, GCP, OpenStack等。本文分享，基于阿里云进行开发、运维的实战经验。

部署Cloud Foundry首先要用到的工具是BOSH。BOSH是用来部署和管理Cloud Foundry集群的工具。 它定义了一系列管理和操作云资源的接口Cloud Provider Interface，各个云厂商需要适配自己的Provider，这就是本文的开发背景。为了让大家对BOSH和CPI有一个感性的认识，下面简要的介绍几个相关概念。

BOSH的组件结构如上图所示, 这里简单说明一下，详细说明见官方文档

1. Director会解析部署命令和模板，然后调用CPI模块去创建VM（ECS）实例，实例信息会写到Registry上。
2. 每个VM上装有Agent负责与Bosh交互，包括：处理Director下发的任务、上报VM的健康状态等。
3. Agent从Registry拿到当前VM的信息，包括：ID, IP等。
4. 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 cpireleasename−−versioncpireleasename−−versionsemver --tarball cpireleasename−cpireleasename−semver.tgz 打release包,根据版本号生成release包名称
  mv cpireleasename−cpireleasename−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状态文件同步到远程