继续浏览精彩内容
慕课网APP
程序员的梦工厂
打开
继续
感谢您的支持,我会继续努力的
赞赏金额会直接到老师账户
将二维码发送给自己后长按识别
微信支付
支付宝支付

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

慕斯卡3435833
关注TA
已关注
手记 7
粉丝 6
获赞 30

背景

图片描述

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状态文件同步到远程
打开App,阅读手记
3人推荐
发表评论
随时随地看视频慕课网APP