GitOps 提供了一种基于 Git 的操作理念，而 Tekton 和 ArgoCD 分别作为 CI/CD 工具，共同实现了这一理念在 Kubernetes 集群中的应用

Tekton不需要额外的机器和环境，jenkins需要。Tekton的CI 和 argoCD是分开的。jenkins混在一起。
ArgoCD 从Git拉取资源和配置，由于Git记录了所有历史变更，所以AgroCD 可以轻松回滚。

k8s只是jenkins 流水线中的一环，但是在tekton中，k8s是基础设施
Jenkins 支持各种编程语言和平台，不仅限于容器化应用。ArgoCD 使用 GitOps 模式管理 Kubernetes 集群状态，所有的集群状态变化都通过 Git 仓库进行版本控制。

工作流程：

• 代码提交：开发人员提交代码到 Git 仓库。
• CI 流程（通过 Tekton 实现）：Tekton 触发构建流水线，编译代码、运行测试、构建 Docker 镜像，并将其推送到镜像仓库。
• CD 流程（通过 GitOps 和 Argo CD 实现）：Tekton 更新 Git 仓库中的声明性配置（如 Kubernetes YAML 文件），Argo CD 检测到配置的变化后，将新的版本自动部署到 Kubernetes 集群中。

argocd部分，tekton ci 部分上传完images后，就用pipeline 中的 task 修改本地gitlab代码中的images镜像tag，在push代码，这样就能触发argocd 部分。比如下面：

- name: update-k8s-config
  taskRef:
    name: git-cli-task
  params:
    - name: repo-url
      value: https://gitlab.com/your-org/gitops-repo.git
    - name: commit-message
      value: "Update image to myapp:latest"
    - name: commit-branch
      value: main
    - name: user-name
      value: tekton-bot
    - name: user-email
      value: tekton-bot@example.com
  script: |
    git clone $(params.repo-url) repo
    cd repo/environments/prod
    sed -i 's/image: myapp:.*/image: myapp:latest/' deployment.yaml
    git config --global user.email "$(params.user-email)"
    git config --global user.name "$(params.user-name)"
    git add .
    git commit -m "$(params.commit-message)"
    git push origin $(params.commit-branch)

部署到prod, dev, test环境

在 ArgoCD 中，如何部署应用到不同的 Kubernetes 环境（如 prod、dev 环境）时，通常涉及以下步骤：

两套git代码，分别包含prod,dev的连接方式，部署代码，部署命名空间等，代码更新，自动部署

1. 配置多个 Kubernetes 集群

ArgoCD 可以管理多个 Kubernetes 集群，即便它本身只部署在一个主控集群中。每个集群（如 prod 和 dev）需要提前通过 ArgoCD CLI 或 Web UI 添加到 ArgoCD 的集群上下文中。

步骤：

通过 CLI 或 Web UI 将不同的集群添加到 ArgoCD 中，这一步将集群的 kubeconfig 信息传递给 ArgoCD。

# 添加 prod 集群到 ArgoCD
argocd cluster add prod-cluster

# 添加 dev 集群到 ArgoCD
argocd cluster add dev-cluster

这一步会将集群的访问信息保存到 ArgoCD 中，供后续的部署使用。

2. 配置 GitOps 仓库中的目录结构

在 GitOps 仓库中，通常会为每个 Kubernetes 环境创建不同的目录结构或分支，用于保存特定环境的配置文件。

例如，目录结构可能是这样的：

/gitops-repo
  ├── environments
  │   ├── prod
  │   └── dev

• environments/prod/：包含生产环境（prod）的 Kubernetes 部署文件。
• environments/dev/：包含开发环境（dev）的 Kubernetes 部署文件。

这些目录包含了 Kubernetes 资源的 YAML 文件，比如 Deployment、Service 等。

3. 创建 ArgoCD Application 对象

每个环境在 ArgoCD 中都会对应一个 Application 对象，Application 对象定义了应用程序的来源（Git 仓库的配置路径）和目标（部署到哪个集群和命名空间）。

生产环境（prod）的 Application 配置示例：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: prod-app
spec:
  project: default
  source:
    repoURL: 'https://gitlab.com/your-org/gitops-repo.git'
    path: 'environments/prod'
    targetRevision: HEAD
  destination:
    server: 'https://prod-k8s-api.example.com'  # 目标集群 API 地址
    namespace: 'production'                     # 要部署的命名空间
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

开发环境（dev）的 Application 配置示例：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: dev-app
spec:
  project: default
  source:
    repoURL: 'https://gitlab.com/your-org/gitops-repo.git'
    path: 'environments/dev'
    targetRevision: HEAD
  destination:
    server: 'https://dev-k8s-api.example.com'    # 目标集群 API 地址
    namespace: 'development'                     # 要部署的命名空间
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

4. ArgoCD 部署流程

ArgoCD 监控 Git 仓库中的配置文件，一旦检测到配置文件有更新，它会自动触发同步，将更新后的资源部署到对应的集群。

部署流程：

1. 监控变更：ArgoCD 持续监控 Git 仓库中的配置文件，路径例如 environments/prod 或 environments/dev。
2. 连接集群：根据 Application 对象中的 destination.server 字段，ArgoCD 自动连接到目标 Kubernetes 集群。
3. 同步配置：ArgoCD 将对应环境的配置文件应用到目标 Kubernetes 集群中的指定命名空间。

5. 完整的部署链条

1. GitOps 仓库更新：

   • 开发人员更新了 Git 仓库中的 environments/dev 目录，修改了开发环境的 Deployment 文件。

2. ArgoCD 检测到更新：

   • ArgoCD 自动监控 Git 仓库中的 environments/dev 路径，检测到更新后触发同步。

3. 连接到 dev 集群：

   • ArgoCD 根据 Application 对象中的 destination.server: https://dev-k8s-api.example.com，连接到开发环境的 Kubernetes 集群。

4. 应用配置：

   • ArgoCD 将更新后的 Deployment 等资源部署到 development 命名空间中，完成同步。

类似的流程也会在生产环境中执行，当生产环境的 environments/prod 目录下有更新时，ArgoCD 会连接生产集群并同步配置。

6. ArgoCD 如何识别不同的 Kubernetes 环境

ArgoCD 的 Application 对象通过两个关键配置来识别不同的环境：

1. source.path：指向 GitOps 仓库中不同的配置路径（如 environments/prod、environments/dev），对应不同的环境。
2. destination.server：每个 Application 对象都有唯一的目标集群的 API 地址，ArgoCD 会根据这个字段连接到不同的 Kubernetes 集群。

通过这些配置，ArgoCD 可以根据 Git 仓库的配置文件自动将应用部署到不同的 Kubernetes 集群环境中。

---

enkins 如何实现将应用部署到不同环境（prod, dev）的

关键在于集群外的jenkins主机获得了kubeconfig文件，也能使用kubectl连接到集群部署应用

1. 准备 Kubernetes 集群的访问凭据

为了让 Jenkins 可以从外部连接到不同的 Kubernetes 集群（如 prod 和 dev），首先需要准备每个集群的访问凭据（通常是 kubeconfig 文件）。可以通过以下步骤获取这些凭据：

• 在每个 Kubernetes 集群中，生成访问凭据（kubeconfig），可以使用以下命令导出 kubeconfig：

  kubectl config view --minify --raw > /path/to/kubeconfig-prod
  kubectl config view --minify --raw > /path/to/kubeconfig-dev
  

• 将 kubeconfig-prod 和 kubeconfig-dev 文件分别保存到 Jenkins 主机上。

2. 配置 Jenkins 凭据

为了让 Jenkins 使用这些 kubeconfig 文件连接到不同的集群，你可以通过以下方式将它们添加到 Jenkins 中：

1. Jenkins Dashboard -> Manage Jenkins -> Manage Credentials。
2. 添加凭据类型为 Secret file 或 Secret text，将不同的 kubeconfig 文件（例如 prod 和 dev）添加为 Jenkins 的全局凭据，分别命名为 kubeconfig-prod 和 kubeconfig-dev。

3. 在 Jenkins 中创建 Pipeline 作业

创建 Jenkins Pipeline 作业，用于自动化部署流程。

示例 Pipeline 配置：

假设你希望 Jenkins 能够根据不同的参数（例如 env 环境变量）来决定将应用程序部署到哪个集群。

pipeline {
    agent any

    environment {
        KUBECTL_PATH = "/usr/local/bin/kubectl"  // kubectl 命令路径
    }

    parameters {
        string(name: 'DEPLOY_ENV', defaultValue: 'dev', description: '部署目标环境 (prod/dev)')
    }

    stages {
        stage('Setup kubeconfig') {
            steps {
                script {
                    // 根据不同的环境加载对应的 kubeconfig
                    if (params.DEPLOY_ENV == 'prod') {
                        // 使用生产环境的 kubeconfig
                        withCredentials([file(credentialsId: 'kubeconfig-prod', variable: 'KUBECONFIG')]) {
                            sh """
                            export KUBECONFIG=${KUBECONFIG}
                            ${KUBECTL_PATH} config get-contexts
                            """
                        }
                    } else {
                        // 使用开发环境的 kubeconfig
                        withCredentials([file(credentialsId: 'kubeconfig-dev', variable: 'KUBECONFIG')]) {
                            sh """
                            export KUBECONFIG=${KUBECONFIG}
                            ${KUBECTL_PATH} config get-contexts
                            """
                        }
                    }
                }
            }
        }

        stage('Deploy to Kubernetes') {
            steps {
                script {
                    // 假设已经准备好 Kubernetes 资源的 YAML 文件
                    sh """
                    ${KUBECTL_PATH} apply -f ./deployment.yaml --namespace=${params.DEPLOY_ENV}
                    """
                }
            }
        }
    }
}

4. 详细的链条说明

1. Jenkins 任务触发：

• 管理员或开发人员手动触发 Jenkins Pipeline，指定要部署的环境（通过 DEPLOY_ENV 参数），比如 dev 或 prod。

2. 加载 kubeconfig：

• Jenkins 会根据 DEPLOY_ENV 参数决定使用哪个 kubeconfig 文件。
  • 如果 DEPLOY_ENV 是 prod，Jenkins 加载 kubeconfig-prod。
  • 如果 DEPLOY_ENV 是 dev，Jenkins 加载 kubeconfig-dev。
• Jenkins 使用 withCredentials 将对应环境的 kubeconfig 文件加载到 KUBECONFIG 环境变量中。

3. 连接 Kubernetes 集群：

• 使用 kubectl config get-contexts 命令验证 Jenkins 成功连接到目标 Kubernetes 集群。
• 通过 KUBECONFIG 环境变量，Jenkins 的 kubectl 命令会自动连接到指定的集群。

4. 部署到指定环境：

• Jenkins 使用 kubectl apply 命令将 Kubernetes 资源（例如 deployment.yaml）应用到指定的命名空间。
• kubectl 的 apply 操作会根据 YAML 文件中定义的资源更新或创建 Kubernetes 资源。

5. 完成部署：

• Jenkins Pipeline 完成任务，成功将应用部署到对应的环境（prod 或 dev 集群）。

5. 安全性注意事项

• Jenkins 通过凭据存储敏感信息（如 kubeconfig），确保这些信息不会暴露给不必要的人员。
• 配置 Jenkins 主机与 Kubernetes API 服务器之间的网络连接，确保 Jenkins 主机可以访问目标集群的 API。

6. 完整部署链条总结

1. Jenkins 主机 触发 Pipeline 任务。
2. 加载 kubeconfig：根据 DEPLOY_ENV 参数，加载不同集群的访问凭据（kubeconfig 文件）。
3. 连接 Kubernetes 集群：Jenkins 使用 kubectl 命令通过 kubeconfig 文件连接到目标 Kubernetes 集群（prod 或 dev）。
4. 执行部署：Jenkins 使用 kubectl apply 将应用程序部署到对应的 Kubernetes 集群命名空间。

通过这种方式，Jenkins 可以从外部的主机上连接和管理不同的 Kubernetes 集群，实现自动化的多环境部署流程。

---

1. tekton

Tekton入门部署
装的时候有两条漏网之鱼

vim TektonCD-Pipelines.yaml # 改下下面,去掉后面的sha256.我这里没删是为了留个纪念
#jiangmaoxi/base:latest 把这个改成 alpine:3.12 把别的sha256删掉，只留tag就行了，要不它总重新pull镜像
 # This is gcr.io/google.com/cloudsdktool/cloud-sdk:302.0.0-slim
            "-gsutil-image", "jiangmaoxi/cloud-sdk:latest@sha256:27b2c22bf259d9bc1a291e99c63791ba0c27a04d2db0a43241ba0f1f20f4067f",
            # The shell image must be root in order to create directories and copy files to PVCs.
            # gcr.io/distroless/base:debug as of February 17, 2022
            # image shall not contains tag, so it will be supported on a runtime like cri-o
            "-shell-image", "jiangmaoxi/base:latest@sha256:3cebc059e7e52a4f5a389aa6788ac2b582227d7953933194764ea434f4d70d64",

skopeo copy --all docker://gcr.io/google.com/cloudsdktool/cloud-sdk docker://jiangmaoxi/cloud-sdk
skopeo copy --all docker://gcr.io/distroless/base docker://jiangmaoxi/base

有run才能跑。step组成task，task组成pipeline。task和pipeline 都是 CRD

Tekton Triggers 是用于触发 CI/CD 流水线的组件。
它提供了一种机制，可以根据外部事件（如 Git 仓库中的代码提交、拉取请求或定时事件）来自动触发 Pipelines 的执行。

创建ingress-nignx
当把上面这个部署ingress-nginx的yaml文件里的LoadBalance 改成NodePort后

kubectl get svc -n ingress-nginx
NAME                                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             NodePort    10.233.13.142   <none>        80:31061/TCP,443:30608/TCP   133m
ingress-nginx-controller-admission   ClusterIP   10.233.13.240   <none>        443/TCP                      133m

[root@master1 tekton]# cat tekton-dashboard-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard-ingress
  namespace: tekton-pipelines
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: tekton.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097

然后在host里配置好 节点ip 域名。然后通过浏览器访问 http://域名: port

install tkn

tkn下载地址

tar -zxvf tkn_0.31.3_Linux_x86_64.tar.gz -C /usr/local/bin/ tkn
tkn version

---

Tekton + ArgoCD 自动化部署链条

Tekton 和 ArgoCD 可以结合使用，实现代码提交后自动化触发部署的流程。以下是一个通俗易懂的例子，展示 Tekton Triggers 如何捕获事件并通过 ArgoCD 进行部署。

场景：

开发者向 GitHub 仓库提交了代码，需要自动部署到 Kubernetes 集群中。我们将使用 Tekton Triggers 来捕获 GitHub 的 push 事件，并通过 ArgoCD 将应用部署到 Kubernetes 集群。

1. GitHub 提交事件

开发者在 GitHub 中推送（push）了新的代码。

2. Tekton Triggers 监听事件

• EventListener：Tekton 中的 EventListener 是一个 HTTP 服务，它监听来自外部（如 GitHub）的 Webhook 事件。在这个例子中，EventListener 正在监听 GitHub 的 push 事件。

  • 当开发者推送代码到 GitHub 时，GitHub 发送 Webhook 请求到 Tekton 的 EventListener 服务。

• Interceptor（拦截器）：接收到 Webhook 后，Interceptor 可以对事件进行过滤，比如仅处理特定分支的推送事件（如 main 分支），确保只有符合条件的事件被触发。

3. 事件处理和参数绑定

• TriggerBinding：事件通过 TriggerBinding 提取 Webhook 中的关键信息（如提交的分支名、提交信息等），并将这些信息作为参数绑定，传递给后续的流程。

  • 例如，TriggerBinding 提取的参数可以是 Git 仓库的 commit id 和 branch name。

• TriggerTemplate：TriggerTemplate 定义了要执行的 Tekton Pipeline 任务。它接收从 TriggerBinding 传递过来的参数，生成一个具体的 PipelineRun，用于执行 CI/CD 操作。

  • 例如，TriggerTemplate 中可以定义任务，执行应用的构建、测试，甚至推送镜像到镜像仓库。

4. Tekton Pipeline 执行

• Tekton Pipeline：触发的 Tekton Pipeline 任务可以包括编译、单元测试、打包应用等操作。任务完成后，可能会生成一个容器镜像并推送到镜像仓库。

5. 通过 ArgoCD 部署到 Kubernetes

• ArgoCD 同步应用：当镜像推送到镜像仓库后，GitOps 方式管理的 Kubernetes 部署文件（如 deployment.yaml）中的镜像版本也会更新到 Git 仓库。此时，ArgoCD 会检测到 Git 仓库中的配置变更。

  • ArgoCD 持续监控 Git 仓库，一旦检测到部署文件发生变更（例如镜像标签更新），它会自动同步这些配置到 Kubernetes 集群，将最新的镜像部署到集群中。

总结流程：

1. GitHub 提交代码：开发者推送代码。
2. Tekton Triggers 捕获事件：EventListener 捕获 GitHub Webhook 事件，Interceptor 过滤后触发 TriggerBinding 和 TriggerTemplate。
3. Tekton Pipeline 执行：执行一系列 CI/CD 任务，如构建、测试、推送镜像。
4. ArgoCD 同步应用：镜像推送后，ArgoCD 检测到 Git 仓库中 Kubernetes 配置变更，自动将应用部署到集群中。

这个链条实现了从代码提交到集群自动部署的全流程自动化，无需手动干预。

---

云笔记笔记

1. pipelineResource 包括git 的url还有 revision master
   harbor的地址还有用户名密码的 Secret 跟 名为build-sa的 ServiceAccout 关联

通过使用 ServiceAccount，你可以控制哪些 Pod 能够访问特定的 ConfigMap 或 Secret。
通过 ServiceAccount，Kubernetes 可以记录哪些 ServiceAccount 在什么时间点访问了哪些资源。这对于合规性和安全审计非常重要。
如果一个 Pod 没有显式指定 ServiceAccount，Kubernetes 会为它分配集群命名空间中的 default ServiceAccount。default ServiceAccount 通常没有赋予任何特权，除非管理员显式地给它分配了权限。如果 default ServiceAccount 没有被授予任何角色，它将没有权限访问任何 ConfigMap 或 Secret。

2. 基于时间戳生成 image tag 的Task
   在Task中，params是 Task需要输入的参数， results 定义 Task 在执行后生成的输出。step 定义了Task 的具体操作

3. 专门用来构建镜像的Task
   sidecar 是与主容器并行的容器，包括主容器没有的工具，sidecar与主容器共享网络、卷等。
   docker:dind 即 Docker-in-Docker镜像，它包含了一个docker 守护进程，dind 目的是让容器内能运行Docker 命令，甚至启动其他容器。
   可以通过sidecar 来启动 dind.
   tcp://localhost:2375：这个端口不使用 TLS（即不加密）。这是 dind 的非加密通信端口，通常用于测试环境或信任的网络内部。
   tcp://localhost:2376：这个端口使用 TLS（即加密）。这是 dind 的加密通信端口，使用 TLS（传输层安全协议）进行加密，适用于更安全的通信需求。 通过这个地址和sidecar，即dind通信，使用它的docker
   tcp://localhost:2376. dind 会自动生成证书并在 2376 端口上启用 TLS。

dind就是用在docker中构建docker, 可以指定构建docker使用的docker版本，这样可以避免污染主机的docker环境，而且提供了一致性的
可以使用 sidecar 容器来运行 dind。sidecar 容器与主容器在同一个 Pod 中运行，共享网络和存储卷。这样，主容器就可以通过网络与 sidecar 中的 dind 进行通信。

Task中的 resource 就是指的 PipelineResource，但是它已经是 deprecated(已弃用)
pipelineResource 与 Task共享输入输出，应该用 params 和 results来替代 PipelineResource.

4. 创建引用 Task的 pipeline
   kind: pipeline 中，params 就是task中用的参数值，然后下面根据名字引用 tasks，填上参数。

5. 引用Pipeline的 PipelineRun
   还加上了之前带有 Secret的 serviceAccount.要注意在pipeline的yaml中，params都是 default 值，真正传实际值在 PipelineRun这里。

先apply task.yaml, 然后是 pipeline.yaml，最后是 pipelineRun.yaml

GitLab触发任务构建

别用 TaskRun, PipelineRun了。提交代码自动触发吧。用 Triggers

EventListener （通过HTTP服务暴露出来）监听Webhook等事件，
在 EventListener 接收到事件后，它首先会调用 Interceptor 来处理或过滤事件。
Interceptor 过滤事件，只有特定的事件，比如GitHub推送事件才会被允许触发后续流程，捕获事件后发给相应的TriggerBinding（事件中的数据被提取并绑定参数）, TriggerBinding 将参数传给 TriggerTemplate, TriggerBinding 作用于特定的命名空间，ClusterTriggerBinding 作用于整个集群中。

安装好tkn 的时候，triggers 就已经装好了

EventListener 中 定义了 使用的 sa, interceptors (里面包含了gitlab的secret, push 事件)，还有bindings 和 Template.
创建完它后会生成一个svc，用来接收事件响应
Gitlab如果部署在集群内部，就用Service的DNS形式来访问 EventListener 即可，如果在外部，用NodePort 或者 Ingress.
每个 Service 都有一个 DNS 名称，通常是 service-name.namespace.svc.cluster.local，你可以在集群内部使用这个 DNS 名称来访问对应的服务。

Secret, WebHook 需要一个 Secret Token, 还有gitlab 登录的账号密码都要写在 Secret.yaml 里

ServiceAccout: 比如 具有 上面 Secret 的 Token和gitlab的 username 和 passwd
Role: 定义了在哪个命名空间中对哪些资源具有增删改查中的哪些权限
RoleBinding 将Role 绑定到了 某个 sa 上，然后 Pod 使用了这个 sa，就具有role 中定义的权限。

TriggerBinding 与 TriggerTemplate的绑定就是在EventListener那里提一嘴就完成了。
TriggerBinding的参数又来自于哪里？
来自于GitLab Webhook发过来的数据，从里面的body中提取的。

TriggerTemplate 里面的 params就提到了 TriggerBinding中的参数。
generateName: gitlab-run- 作用是指定taskRun的前缀名，后缀k8s 会自动生成
TaskSpec, 在没有预先定义Task，可以在这里定义
tt. 是从 TriggerBinding 中传递的参数前缀

这里面哪里表示pull代码了？把代码pull到哪里了？

resources:
  inputs:
    - name: source
      type: git

这里定义了一个名为 source 的输入资源，它的类型是 git。
这表示这个资源将从一个 Git 仓库中拉取代码。

image: ubuntu 表示在运行这一步骤时，会拉取并使用 ubuntu 镜像。
这个镜像会被拉取到执行 TaskRun 的节点（即 Kubernetes 中运行 Pod 的节点）上。

代码会被拉取到运行 TaskRun 的 Pod 中的特定目录。这个目录是由 Tekton 自动管理的，通常位于容器的文件系统中。

eventlistener 为 svc 和 pod 还有 eventlistener 资源
在集群内用kubectl get eventlistener地址访问，集群外用 Ingress

ingress nginx

目的在集群之外访问到 EventListener
部署ingress-nginx
将 ingress-nginx-controller 从NodePort 改成 LoadBalancer

ingress.yaml 中要指明用的是 nginx，host, svc的名字和端口

在dnsserver里添加 EventListener的域名解析

然后在gitlab的 Webhooks里填入域名和Secret token,就是你之前自己定的那个token

Gitlab 提交代码后，在k8s 中会出现 taskrun对应的pod, 查看这个pod 的日志，可以看到 showPath
它会在你触发 CI/CD 流水线时创建。TaskRun 会启动一个或多个 Pod 来执行定义的任务（如拉取代码、构建镜像、运行测试等）。
Pod 的终止：当 TaskRun 中的所有步骤执行完毕后，Pod 的任务就完成了。Kubernetes 默认会自动清理完成状态的 Pod，因此这些 Pod 会被终止并移除。

自动化流水线

Clone 代码 -> 单元测试 -> 编译打包 -> Docker 镜像构建/推送 -> kubectl 部署服务及回滚
每一步都是一个 Task

sa 用于harbor gitlab 认证，存储后端用 sc: nfs

clone代码的task直接去tekton官网下载，改动下即可使用

编译打包app阶段，workspaces 是pv或者emptyDir. 它用于不同任务之间共享文件和数据。只要使用相同的workspaces name，它们就将共享一个路径,在构建镜像的时候就能得到上一步中创建的二进制文件

DinD 是用来构建和推送镜像的。用DinD就得用sidecar.

在部署到k8s的时候也可以使用helm
Helm就在代码仓库中，已经在共享目录里了。早就clone下来了
helm Chart 里面包含了k8s所需的Deployment,service等和模板化的配置文件。
helm仓库是存储 chart的地方，可以使用 helm repo add 命令添加官方或自定义的 Helm 仓库。然后 helm repo update,更新本地Chart
修改values.yaml 更新Chart 配置，values.yaml里面就有你之前build 好的镜像

不用下面这么复杂，直接在pipelineRun中的overwrite_values那里指定值就行了。
使用简单的脚本来更新 values.yaml 文件中的镜像名称和标签。

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: update-helm-values
spec:
  params:
    - name: IMAGE_URL
      description: "The URL of the image repository"
    - name: IMAGE_TAG
      description: "The tag of the image"
  workspaces:
    - name: source
  steps:
    - name: update-values
      image: ubuntu
      script: |
        sed -i "s|repository:.*|repository: $(params.IMAGE_URL)|g" /workspace/source/values.yaml
        sed -i "s|tag:.*|tag: $(params.IMAGE_TAG)|g" /workspace/source/values.yaml

回滚

最好是我们手动去触发
也可以通过WhenExpressions 自动触发，通过helm-status获取部署状态来决定是否回滚
也是通过helm 的 rollback 实现的回滚

这次是真的流水线

pipeline中定义 workspace,Resource, Params 等，然后传递到Task中，pipeline中也引用了大量的Task，然后把之前写入值的参数传给task
workspace用的nfs

push代码后自动触发

就是用EventListener（里面带binding） 和 TriggerTemplate 代替 pipelineRun，一 push 代码就自动构建

ArgoCD

deploy和rollback 属于 CD 部分，这部分用ArgoCD 替换。
是一个在argocd 命名空间下的 pod。用到ingress-nginx 和 dnsserver 将argoCD svc暴露出去。为的是 argoCD的网页
有命令行工具 argocd, 用它可以修改网页登录passwd

有两个gitlab库，一个在CI 阶段的代码库，一个是在CD 阶段的 helm库

网页端部署CD项目
项目下创建 app,它可以指定部署哪个 helm的git

CI 推送到镜像仓库后，要手动修改代码仓库中的values文件，手动触发 Argo CD创建，回滚也是在ArgoCD中操作（有链路图的，点点就能回滚），不需要单独的Task 任务，这需要改造pipeline，自己写yaml

yaml就是上传代码之后，自动构建镜像，添加一个task用来修改helm values.yaml里的image值,然后使用helm 利用argocd部署app.回滚使用的是argocd的网页，点点即可回滚