目录

基于Kubernetes的云原生CICD之TeKton

CICI和GitOps快速入门

什么是CICD

CI/CD是一种在应用开发阶段引入的自动化实现较高频率向客户交付应用的方法.

  • 三个阶段:持续基础、持续交付、持续部署
  • 简单地来说就是自动化交付,代表了一组工具链来实现从源代码到交付给客户的
  • 这些关联的事务通常统一被称为CI/CD Pipeline.

CI和CD的关系

  • CI是指持续集成,它属于开发人员的自动化流程
  • CD指的是持续交付和持续部署,两者都事关Pipeline的自动化。

CICD Pipeline(流水线)

  • 为了交付新版本软件而必执行的一系列步骤
  • 一套专注于DevopsSRE方法来改进软件交付的实践
  • 加入了监控自动化来改进应用开发过程,尤其是在集成和测试阶段,以及在交付和部署过程中.

即便你可以手动的执行Pipeline的每个步骤,但是价值在于自动化.

CICD Pipeline要素

  • 构成Pipeline的步骤被划分了不同的子集,称之为Stage

    • Pipeline中典型的Stage包括
    • Build(构建):应用编译
    • Test(测试):代码测试
    • Release(发布):将应用交付到存储库
    • Deploy(部署):将代码交付到生产环境
    • ValidationCompliance(验证和合规):例如镜像的安全扫描
  • 传统的CICD是使用虚拟机的Pipeline而设计,但是云原生的Pipeline的价值实现带来的新的突破.

    • 采用Tekton项目,用户可以构建Kubernetes风格的Pipeline控制微服务的周期.

一个典型的GitOps Pipeline

  • GitOps模型中存在两个Git仓库
    • 代码仓库CodeRepo: 开发人员使用
    • 配置仓库ConfigRepo: 运维人员使用
      • 推送配置变更
      • 包括基础设施配置以及应用配置
  • 简要的工作流程
    • 开发推送代码到仓库
    • CI工具链完成测试和构建
    • CI工具链完成测试和交付(新版本IMAGE)推送到镜像仓库
    • ConfigUpdate将Image的变更配置信息推送到配置仓库
    • 最后根据分支和发布策略,完成应用部署

Tekton系统组件

  • Tekton Pipelines
    • Tekton最核心的组件,由一组CRD相关的Operator、Webhook共同组成
    • 需要部署并运行在Kubernetes集群上,作为集群的扩展使用.
  • Tekton Triggers
    • 触发器,可以触发Pipeline的实例化
  • Tekton CLI
    • 命令客户端,用于跟Tekton进行交互
  • Tekton Dashboard
    • Tekton的UI
  • Tekton Catalog
    • 社区贡献的构建块
  • Tekton Hub
    • 用于访问Catelog的图形界面

模型概念1

  • Step
    • CI/CD工作流的一个具体操作,例如Python Web app的单元测试,或者是Java程序的编译操作
    • 每个Step都会通过一个特定的Container运行
  • Task
    • 由一组Step组成的序列,按照定义的顺序依次运行于同一个Pod的不同容器中
    • 可以共享一组环境变量,以及存储卷
  • Pipeline
    • 由一组Task组成的集合,可按照定义以不同的方试运行
    • 一个Task的输出可由后面的Task引用

模型概念2

  • Input和Output resources
    • 每个Task或者Pipeline都有可能Input或者OutPut
      • 例如某个Task以image repo为input
    • Tekton支持如下几种类型的resources
      • git: 一个特定的git repository
      • Pull Request: 某个git repository上特定的PR
      • image: 容器镜像
      • Cluster:Kubernetes集群
      • Storage:存储的Object
      • CloudEvent

注意:Input和Output Resources已经被废弃,建议使用Parameters代替

Pipeline和Task上的数据共享

Pipeline上可能会存在数据共享的需要

  • 例如一个Task的多个Step之间,靠前一个Task生成的结果,需要由后面某个Step来引用
  • 一个Pipeline的多个Task之间,前面的Task的处理的结果,需要由后面的某个Task引用
  • 常见的解决方案有两种:ResultsWorkspace
    • Results
      • 由Task声明
      • 它将Task中Step生成的结果保存于临时文件中(/tekton/results/),而后由同一个Task中后面由Step引用,或者由他后面的Step引用
        • 文件名也能以变量的方式引用$(results.<NAME>.path)
    • Workspace
      • 由Task声明
      • 通常对应Kubernetes上的ConfigMap、Secret、emptyDir、静态PVC类型的卷,或者VolumeClaimTemplate动态请求的PVC
      • emptyDir的生命周期与Pod相同,因此仅能在一个TaskRun的各Step共享
      • 如果要跨Task共享数据,则需要使用PVC

部署Tekton

需要满足下列版本要求

  • Starting from the v0.24.x release of Tekton: Kubernetes version 1.18 or later
  • Starting from the v0.27.x release of Tekton: Kubernetes version 1.19 or later
  • Starting from the v0.30.x release of Tekton: Kubernetes version 1.20 or later
  • Starting from the v0.33.x release of Tekton: Kubernetes version 1.21 or later
1
2
3
4
5
# 由于我们的kubernetes集群是1.7.9 所以用0.23版本
wget https://storage.googleapis.com/tekton-releases/pipeline/previous/v0.23.0/release.yaml
# 你应该会用到如下两个镜像
gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/controller@sha256:e9128c33f5ee55c9d7fcafc914487a23dd0348e45bf14e644d71f8b73dae9061
gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/webhook@sha256:9842623ed07f6efc0dac227dab263e295f7ddc48ab029b20a7ee0ec1e66b0c4a