DevOps功能实现解析

概述

过去传统的开发模式是开发团队研发了产品，后期的部署运维交给单独的运维团队负责。这种开发模式经常会导致一些混乱的问题，比如，前期开发时由于缺乏后面测试和部署时的及时反馈，一些小问题没有及时发现，导致后面错误累积，甚至积重难返，需要返工重做；也有可能前期开发时没有出现任何问题，但是到后面部署运维时一些基础环境变了，导致很多冲突产生，运维或开发团队又需要在短时间内解决该问题，耗时耗力，甚至可能拖延产品的上线日期。这种传统的开发模式虽然有分工明确，各司其职的优点，但是正因为如此，开发、测试和运维团队之间严重脱节，缺乏密切的合作，很多前期没有发现的小问题会在后期部署运维时集中爆发，大大提高了开发的成本以及延长了产品的迭代周期。针对现代软件越来越复杂，需求变化越来越快的趋势，人们提出了DevOps(Development&Operations)开发模式，它不是一种工具集，而是一套方法论，主张开发、测试和运维团队之间进行沟通、协作、集成和自动化，以综合协作的工作方式改善整个团队在交付软件过程中的速度和质量。

如果说DevOps是一种开发理念，那么CI/CD(持续集成、持续部署)管道就是其中的一种实践方式，它代表着发布流程自身的一个循环，从编写代码、构建镜像、测试代码、部署代码到后面生产环境重新测试和部署等，这是一个持续的过程，反复的过程。它使开发、测试和运维团队等一开始就以综合协作的方式绑定在一起，解决了前期开发得不到及时的测试、部署反馈以及运维在后期才开始介入等问题，避免了错误累积以及能够快速响应新的需求变化。常用的CI/CD工具有Jenkins、Drone和GitLab CI等等，由于系统平台使用的是Jenkins，我们就以Jenkins为例简单介绍下其相关概念。Jenkins是一个用java语言编写的开源工具，其CI/CD功能是通过一个叫pipeline的插件完成的。顾名思义，pipeline就是一套运行在Jenkins上的流水线框架，类似于工厂中的流水线作业。它将代码编译、脚本运行、镜像构建、测试、部署等功能集成在一起，为了清楚地划分不同的功能逻辑，一个pipeline被划分成了若干个Stage（称之为阶段），每个Stage代表一组相关的操作，比如：“build”，“Test”，“Deploy”等。其中每个Stage内又划分了多个Step（称之为步骤），它是最基本的操作单元，比如：创建目录、构建镜像、部署应用等等，由各类Jenkins插件提供具体功能。pipeline示意图如下所示：

魔方云DevOps实现

简单地说，魔方云是基于Kubernetes管理多种云的云平台管理系统，内部功能的设计基本上均是通过Kubernetes(以下简称k8s)提供的自定义controller功能来实现的，其基本逻辑就是根据业务需要抽象出多个CRD（Custom Resource Definition，自定义资源对象），并编写对应的controller来实现业务逻辑。

为了实现CI/CD功能，我们抽象出了多个CRD，跟pipeline相关的3个CRD：

• pipeline：记录pipeline运行时状态、仓库的认证信息、钩子触发配置以及项目代码地址等信息。
• pipelineExecution：每次pipeline运行时产生的执行实例（以下简称执行实例），运行完记录结果信息；
• pipelineSetting：整个项目下pipeline运行的设置信息，比如内存、CPU的限制，最大流水线并行运行个数等等。

跟源代码仓库（以下以gitlab为例）相关的3个CRD：

• sourceCodeProviderConfig：记录代码仓库的application id 和secret授权信息；
• sourceCodeCredential：记录代码仓库的oauth认证信息；
• sourceCodeRepository：记录代码仓库的每个具体的项目信息。

除了抽象出对应的CRD外，我们还需要编写对应的controller代码实现对应的业务逻辑，比如当pipeline运行时，我们需要产生pipeline执行实例，并实时同步其运行的状态信息等等。文章下面会详细介绍。

pipeline功能步骤有很多种类型，包括运行脚本、构建发布镜像、发布应用模板、部署YAML、部署应用等等。为了提供这些功能，我们采用Jenkins作为底层的CI/CD工具，docker registry 作为镜像仓库中心，minio作为日志存储中心等等。这些服务是运行在pipeline所在项目的命名空间下。综上，我们设计的CI/CD系统功能的实现逻辑如图所示：

如上，当触发pipeline执行逻辑时，会产生一个pipelineExecution crd，以记录本次运行pipeline的状态信息。当goroutine（syncState）发现有新的执行实例产生时，就会通过Jenkins引擎接口启动Jenkins server端流水线作业的运行，Jenkins server 端收到信息后会启动单独的一个Jenkins slave pod进行流水线作业的响应。同时，goroutine（syncState）会不断地通过引擎接口轮询pipeline执行实例的运行情况进而更新 pipelineExecution crd的状态，比如，运行成功或失败等等。当pipeline执行实例发生状态变化时，就会触发其对应的controller业务逻辑，进而通过Jenkins引擎接口与Jenkins server 通信进行不同的操作，比如，暂停流水线的运行，运行完清除不需要的资源等等。当流水线作业发生状态变化时，又会通过goroutine（syncState）更改pipeline执行实例的状态，进而又触发对应的controller业务代码进行不同的业务逻辑处理，往复循环，直到流水线运行结束。这就是整个pipeline执行时的一个逻辑流程。我们把整个pipeline模块的实现划分成了3个部分：

• crd：即上述提到的6个crd类型；
• 基础接口定义：即与Jenkins server通信的客户端，与代码仓库交互的客户端等等基础模块；
• controller：实现逻辑功能的业务代码。

CRD

我们首先介绍下3个与源代码仓库相关的crd。当我们首次配置pipeline时会进行代码仓库授权设置，填写的gitlab Application Id和secret等信息会被存入到sourceCodeProviderConfig这个crd中，下面摘取了一些主要的字段信息并添加了详细注释，敏感信息使用了‘*’代替。

apiVersion: project.cubepaas.com/v3
metadata:
  name: gitlab
  namespace: p-qqxs7
clientId: 89d840b****** // Application Id
clientSecret: a69657b****** // secret
enabled: true
hostname: gitlab.******.cn // 代码仓库的地址
projectName: c-llqwv:p-qqxs7
redirectUrl: https://******/verify-auth
type: gitlabPipelineConfig // 仓库类型

当配置完授权信息后，平台就会与源代码仓库进行交互，获取到仓库的oauth认证信息并填充到sourceCodeCredential crd中，同时会获取该仓库下所有的项目代码的信息并填充到sourceCodeRepository crd中。如下所示：

apiVersion: project.cubepaas.com/v3
metadata:
  name: p-qqxs7-gitlab-******
spec:
  accessToken: 65b4e90****** // 访问token
  displayName: ****** // 代码仓库的显示昵称
  gitLoginName: oauth2
  loginName: ****** // 代码仓库的登入用户名
  projectName: c-llqwv:p-qqxs7
  sourceCodeType: gitlab // 代码仓库类型, gitlab github ...

apiVersion: project.cubepaas.com/v3
kind: SourceCodeRepository
metadata:
  labels:
    cubepaas.com/creator: