k8s tekton 实现CI流程，从git到docker registry

小白防忘。
在没学k8s之前一直使用的是jikens和docker watchtower实现CICD流程，在学习了k8s最后就决定使用tekton实现CI操作，tekton pipelines是一个k8s的扩展，定义了一组k8s自定义资源从而可以实现CI/CD工作（本文档只说明了CI的操作流程），因为基于k8s实现的所以使用起来也更加顺手。
首先梳理一下CI流程：

1. 从github中拉取代码
2. 将代码构建为docker 镜像
3. 将构建好的docker镜像push到docker registry

一共三个步骤，因为从github中拉取代码是tekton默认的一个行为，只要配置了inputs type为git，tekton会自动为我们拉取代码，所以只需要管理剩下的两个步骤。又因为构建、推送镜像可以使用kaniko工具实现docker镜像的构建和推送，所以最终只需要实现一个步骤就是使用kaniko工具。
根据需求梳理出所需要用的tekton工具：

• PipelineResource：配置git仓库地址，配置docker registry地址和镜像的名称以及版本号。
• ServiceAccount和Secret：因为使用的是私有docker仓库所以需要额外配置docker私有库的认证信息。
• task：使用kaniko工具构建、推送镜像。
• taskrun：运行配置好的task实现CI流程。

tekton所有可能需要用的配置文档（官方文档）
具体的配置yaml如下：
配置PipelineResource，设置git仓库地址和docker registry地址和镜像名称。
PipelineResource官方文档

#PipelineResource，配置文件源和输出源
#文件源为git仓库上的代码
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: tekton-git
  namespace: tekton-test
spec:
  type: git
  params:
  - name: url
  #仓库地址
    value: https://gitee.com/yustudy/k8s.git
---
#输出源docker镜像，最后会上传到自己搭建的私有registry中
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: tekton-image
  namespace: tekton-test
spec:
  type: image
  params:
  - name: url
  #docker镜像的名称
    value: 192.168.220.108:5000/set:v1 

配置docker registry的认证信息，因为我没有使用私有的git仓库，所以只配置了docker registry的认证配置。
配置ServiceAccount 和Secret
配置格式有两种，看你自己喜欢哪一种了，不管是配置git私有仓库认证还是docker私有仓库认证格都大差不差，官网示例git和docker私有库认证都在这里

#因为是私有仓库，所以需要配置仓库的认证信息
apiVersion: v1
kind: Secret
metadata:
  name: tekton-docker-passwd
  namespace: tekton-test
  annotations:
  #配置需要认证的registry地址
    tekton.dev/docker-0: http://192.168.220.108:5000
type: kubernetes.io/basic-auth
stringData:
#配置认证需要的账户密码，如果密码或者用户名为纯数字，则需要添加“”不然会报错
  username: yufang
  password: "123456"
---
#将认证信息加入到serviceAccount供taskrun使用
apiVersion: v1
kind: ServiceAccount
metadata:
  name: tekton-docker-account
  namespace: tekton-test
secrets:
- name: tekton-docker-passwd

准备工作做完就可以配置task了，task只管负责做什么，所需要的源文件等等都由taskrun提供。
kaniko官方文档
task官方文档

#部署task，使用kaniko工具构建镜像和推送镜像
#task中只负责定义资源，taskrun才是根据task所定义的资源去寻找具体的资源位置
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: tekton-task
  namespace: tekton-test
spec:
  params:
  #配置dockerfile的路径（dockerfile也在git仓库中）
  - name: dockerfilePath
    type: string
    description: build image file
    #这个文件的位置就是从git仓库拉下来的文件夹内，
    #如果dockerfile和代码不是平级的关系可以通过/的方式进入其他文件夹
    #default: $(resourecs.inputs.docker-source.path)/dockerfilePath
    #dockerfile的文件名会在taskrun中配置，比如我的dockerfile文件名叫setDockerfile
    #这里只需要指出dockerfile在哪个文件夹内就可以了
    default: $(resourecs.inputs.docker-source.path)
    #配置资源路径（其实就是代码的路径）
  - name: contextPath
    type: string
    description: The build context used by Kaniko
    #说直白一点就是你dockerfile构建镜像时需要的文件的地址，一般为代码。
    default: $(resourecs.inputs.docker-source.path)
    #配置输入源（从git上拉取代码），输出源（构建镜像并上传到私有库）
    #task中resources的意思就是定义该task需要用到的输入输出源，而具体的这个数据从哪里来需要在taskrun中配置
    #（具体怎么理解可以看官方文档，最好结合taskrun的文档一起看，因为task的文档只说了是定义输入输出源）
    #需要注意的是input和output的名称需要和taskrun中的input和output的名称相同
  resources:
    inputs:
    - name: docker-source
      type: git
    outputs:
    - name: builtImage
      type: image
  steps:
  - name: build-and-push
    #kaniko的镜像，这是别人上传的镜像，官方镜像不翻墙拉不到
    image: cnych/kaniko-executor:v0.22.0
    #映射主机的dockerconfig文件
    env:
    - name: DOCKER_CONFIG
      value: /tekton/home/.docker
    #覆盖掉原本的环境变量，如果想保留默认的环境变量可以将command参数换为args
    command:
    - /kaniko/executor
    #添加docker的地址
    - --dockerfile=$(params.dockerfilePath)
    #构成镜像的名称
    - --destination=$(resources.outputs.builtImage.url)
    #代码路径
    - --context=$(params.contextPath)
    #推送镜像时发送http请求，不推荐在生产环境中使用
    - --insecure
    #拉取镜像时使用http请求
    #- --insecure-pull
    #指定使用特定的私有库地址使用http请求，可以设置多个
    #- --insecure-registry=<registry-name1><registry-name2>
    #跳过tls认证和insecure用法相同
    - --skip-tls-verify
    #- --skip-tls-verify-pull
    #- --skip-tls-verify-registry=<registry-name1><registry-name2>

最后配置taskrun，运行刚才配置的task以及在为task提供具体的输入输出源。
taskrun官方文档

#taskrun 简而言之就是运行一次我们刚才创建的task
#因为每个task做的事情都是固定的，且每个task是无序的，
#所以把多个task有序的串起来就变为了pipeline，而pipelinerun就是运行一次pipeline
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: tekton-taskrun
  namespace: tekton-test
spec:
  #使用刚才配置的docker registry认证信息
  serviceAccountName: tekton-docker-account
  #指定使用哪个task
  taskRef:
    name: tekton-task
  #指明dockerfile的名称
  params:
  - name: dockerfilePath
    value: setDockerfile
    #指明构建镜像的源文件地址，（因为我把dockerfile放在了项目开发文件夹中，所以是同一个地址。）
  - name: contextPath
    value: $(resources.inputs.docker-source.path)
  #指定task中定义的输入输出源的具体配置
  resources:
  #设置输入源的名称
    inputs:
    #该名称需要和task中定义输入源的名称相同
    - name: docker-source
      resourceRef:
        #该名称为之前定义的pipelineResources的名称
        name: tekton-git
    #该名称需要和task中定义输出源的名称相同
    outputs:
    - name: builtImage
      resourceRef:
        name: tekton-image

tekton的一些常用命令：

kubectl get task -n tekton-test
kubectl get taskrun -n tekton-test
ubectl get pipelineResource -n tekton-test
#用得最多，主要看报错信息
kubectl describe taskrun tekton-taskrun -n tekton-test
kubectl logs taskrunPodName -n tekton-test -c 四种状态名称，用describe可以看到