GVKun编程网logo

Tekton 与 Argo CD 结合实现 GitOps(tekton trigger)

13

如果您想了解Tekton与ArgoCD结合实现GitOps和tektontrigger的知识,那么本篇文章将是您的不二之选。我们将深入剖析Tekton与ArgoCD结合实现GitOps的各个方面,并为

如果您想了解Tekton 与 Argo CD 结合实现 GitOpstekton trigger的知识,那么本篇文章将是您的不二之选。我们将深入剖析Tekton 与 Argo CD 结合实现 GitOps的各个方面,并为您解答tekton trigger的疑在这篇文章中,我们将为您介绍Tekton 与 Argo CD 结合实现 GitOps的相关知识,同时也会详细的解释tekton trigger的运用方法,并给出实际的案例分析,希望能帮助到您!

本文目录一览:

Tekton 与 Argo CD 结合实现 GitOps(tekton trigger)

Tekton 与 Argo CD 结合实现 GitOps(tekton trigger)

前面我们使用 Tekton 完成了应用的 CI/CD 流程,但是 CD 是在 Tekton 的任务中去完成的,现在我们使用 GitOps 的方式来改造我们的流水线,将 CD 部分使用 Argo CD 来完成。

这里我们要先去回顾下前面的 Tekton 实战部分的内容,整个流水线包括 clone、test、build、docker、deploy、rollback 几个部分的任务,最后的 deploy 和 rollback 属于 CD 部分,我们只需要这部分使用 Argo CD 来构建即可。

首先我们将项目 http://git.k8s.local/course/devops-demo.git 仓库中的 Helm Chart 模板单独提取出来放到一个独立的仓库中 http://git.k8s.local/course/devops-demo-deploy,这样方便和 Argo CD 进行对接,整个项目下面只有用于应用部署的 Helm Chart 模板。

首先在 Argo CD 上面添加该仓库:

然后创建新应用,首先可以创建一个项目,在 Argo CD 中有一个 AppProject 的 CRD,表示应用程序的逻辑分组,它由以下几个关键属性组成:

  • sourceRepos:项目中的应用程序可以从中获取清单的仓库引用
  • destinations:项目中的应用可以部署到的集群和命名空间
  • roles:项目内资源访问定义的角色
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  # 项目名
  name: demo
  namespace: argocd
spec:
  # 目标
  destinations:
    # 此项目的服务允许部署的 namespace,这里为全部
  - namespace: ''*''
    # 此项目允许部署的集群,这里为默认集群,即为Argo CD部署的当前集群
    server: https://kubernetes.default.svc
  # 允许的数据源
  sourceRepos:
  - http://git.k8s.local/course/devops-demo-deploy.git

更多配置信息可以前往文档 https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/ 查看,项目创建完成后,在该项目下创建一个 Application,代表环境中部署的应用程序实例。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: devops-demo
  namespace: argocd
spec:
  destination:
    namespace: default
    server: ''https://kubernetes.default.svc''
  project: demo
  source:
    path: helm  # 从 Helm 存储库创建应用程序时,chart 必须指定 path
    repoURL: ''http://git.k8s.local/course/devops-demo-deploy.git''
    targetRevision: HEAD
    helm:
      parameters:
        - name: replicaCount
          value: ''2''
      valueFiles:
        - my-values.yaml

这里我们定义了一个名为 devops-demo 的应用,应用源来自于 helm 路径,使用的是 my-values.yaml 文件,此外还可以通过 source.helm.parameters 来配置参数,同步策略我们仍然选择使用手动的方式,我们可以在 Tekton 的任务中去手动触发同步。上面的资源对象创建完成后应用就会处于 OutOfSync 状态,因为集群中还没部署该应用。

现在接下来我们去修改之前的 Tekton 流水线,之前的 Pipeline 流水线如下所示:

# pipeline.yaml
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: pipeline
spec:
  workspaces: # 声明 workspaces
    - name: go-repo-pvc
  params:
    # 定义代码仓库
    - name: git_url
    - name: revision
      type: string
      default: "master"
    # 定义镜像参数
    - name: image
    - name: registry_url
      type: string
      default: "harbor.k8s.local"
    - name: registry_mirror
      type: string
      default: "https://ot2k4d59.mirror.aliyuncs.com/"
    # 定义 helm charts 参数
    - name: charts_dir
    - name: release_name
    - name: release_namespace
      default: "default"
    - name: overwrite_values
      default: ""
    - name: values_file
      default: "values.yaml"
  tasks: # 添加task到流水线中
    - name: clone
      taskRef:
        name: git-clone
      workspaces:
        - name: output
          workspace: go-repo-pvc
      params:
        - name: url
          value: $(params.git_url)
        - name: revision
          value: $(params.revision)
    - name: test
      taskRef:
        name: test
    - name: build # 编译二进制程序
      taskRef:
        name: build
      runAfter: # 测试任务执行之后才执行 build task
        - test
        - clone
      workspaces: # 传递 workspaces
        - name: go-repo
          workspace: go-repo-pvc
    - name: docker # 构建并推送 Docker 镜像
      taskRef:
        name: docker
      runAfter:
        - build
      workspaces: # 传递 workspaces
        - name: go-repo
          workspace: go-repo-pvc
      params: # 传递参数
        - name: image
          value: $(params.image)
        - name: registry_url
          value: $(params.registry_url)
        - name: registry_mirror
          value: $(params.registry_mirror)
    - name: deploy # 部署应用
      taskRef:
        name: deploy
      runAfter:
        - docker
      workspaces:
        - name: source
          workspace: go-repo-pvc
      params:
        - name: charts_dir
          value: $(params.charts_dir)
        - name: release_name
          value: $(params.release_name)
        - name: release_namespace
          value: $(params.release_namespace)
        - name: overwrite_values
          value: $(params.overwrite_values)
        - name: values_file
          value: $(params.values_file)
    - name: rollback # 回滚
      taskRef:
        name: rollback
      when:
        - input: "$(tasks.deploy.results.helm-status)"
          operator: in
          values: ["failed"]
      params:
        - name: release_name
          value: $(params.release_name)
        - name: release_namespace
          value: $(params.release_namespace)

现在我们需要去掉最后的 deploy 和 rollback 两个任务,当 Docker 镜像构建推送完成后,我们只需要去修改部署代码仓库中的 values 文件,然后再去手动触发 Argo CD 同步状态即可(如果开启了自动同步这一步都可以省略了),而回滚操作直接在 Argo CD 中去操作即可,不需要定义一个单独的 Task 任务。

定义一个如下所示的 Taks 任务:

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: sync
spec:
  volumes:
  - name: argocd-secret
    secret:
      secretName: $(inputs.params.argocd_secret)
  params:
    - name: argocd_url
      description: "The URL of the ArgoCD server"
    - name: argocd_secret
      description: "The secret containing the username and password for the tekton task to connect to argo"
    - name: commit_id
      description: "The commit ID to update"
    - name: app_name
      description: "The name of the argo app to update"
    - name: app_revision
      default: "HEAD"
      description: "The revision of the argo app to update"
  steps:
  - name: deploy
    image: argoproj/argocd
    volumeMounts:
    - name: argocd-secret
      mountPath: /var/secret
    command:
    - sh
    args:
    - -ce
    - |
      set -e
      echo "update commit id"
      argocd login --insecure $(params.argocd_url) --username $(/bin/cat /var/secret/username) --password $(/bin/cat /var/secret/password)
      argocd app sync $(params.app_name) --revision $(params.app_revision)
      argocd app wait $(params.app_name) --health

由于我们这里只需要修改 Helm Chart 的 Values 文件中的 image.tag 参数,最好的方式当然还是在一个 Task 中去修改 values.yaml 文件并 commit 到 Repo 仓库中去,当然也可以为了简单直接在 Argo CD 的应用侧配置参数即可,比如可以使用 argocd app set 命令来为应用配置参数,然后下面再用 argocd app sync 命令手动触发同步操作,这里其实就可以有很多操作了,比如我们可以根据某些条件来判断是否需要部署,满足条件后再执行 sync 操作,最后使用 wait 命令等待应用部署完成。

除了通过手动 argocd app set 的方式来配置参数之外,可能更好的方式还是直接去修改 Repo 仓库中的 values 值,这样在源代码仓库中有一个版本记录,我们可以新建如下所示的一个任务用来修改 values 值:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: change-manifests
spec:
  params:
    - name: git_url
      description: Git repository containing manifest files to update
    - name: git_email
      default: pipeline@k8s.local
    - name: git_name
      default: Tekton Pipeline
    - name: git_manifest_dir
      description: Manifests files dir
    - name: tool_image
      default: cnych/helm-kubectl-curl-git-jq-yq
    - name: image_tag
      description: Deploy docker image tag
  steps:
    - name: git-push
      image: $(params.tool_image)
      env:
        - name: GIT_USERNAME
          valueFrom:
            secretKeyRef:
              name: gitlab-auth
              key: username
              optional: true
        - name: GIT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: gitlab-auth
              key: password
              optional: true
      command: ["/bin/bash"]
      args:
        - -c
        - |
          set -eu
          echo Load environment variables from previous steps
          source /workspace/env-config
          git config --global user.email "$(params.git_email)"
          git config --global user.name "$(params.git_name)"
          git clone --branch master --depth 1 http://${GIT_USERNAME}:${GIT_PASSWORD}@$(params.git_url) repo
          cd "repo/$(params.git_manifest_dir)"
          ls -l
          echo old value:
          cat my-values.yaml | yq r - ''image.tag''
          echo replacing with new value:
          echo $(params.image_tag)
          yq w --inplace my-values.yaml ''image.tag'' "$(params.image_tag)"
          echo verifying new value
          yq r my-values.yaml ''image.tag''
          if ! git diff-index --quiet HEAD --; then
            git status
            git add .
            git commit -m "helm values updated by tekton pipeline in change-manifests task"
            git push
          else
              echo "no changes, git repository is up to date"
          fi

现在我们的流水线就变成了如下所示的清单:

# pipeline.yaml
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: pipeline
spec:
  workspaces: # 声明 workspaces
    - name: go-repo-pvc
  params:
    # 定义代码仓库
    - name: git_url
    - name: git_infra_url
    - name: revision
      type: string
      default: "master"
    # 定义镜像参数
    - name: image
    - name: image_tag
    - name: registry_url
      type: string
      default: "harbor.k8s.local"
    - name: registry_mirror
      type: string
      default: "https://ot2k4d59.mirror.aliyuncs.com/"
    - name: git_manifest_dir
      default: "helm"
    # 定义 argocd 参数
    - name: argocd_url
    - name: argocd_secret
    - name: app_name
    - name: app_revision
      type: string
      default: "HEAD"
  tasks: # 添加task到流水线中
    - name: clone
      taskRef:
        name: git-clone
      workspaces:
        - name: output
          workspace: go-repo-pvc
      params:
        - name: url
          value: $(params.git_url)
        - name: revision
          value: $(params.revision)
    - name: test
      taskRef:
        name: test
    - name: build # 编译二进制程序
      taskRef:
        name: build
      runAfter: # 测试任务执行之后才执行 build task
        - test
        - clone
      workspaces: # 传递 workspaces
        - name: go-repo
          workspace: go-repo-pvc
    - name: docker # 构建并推送 Docker 镜像
      taskRef:
        name: docker
      runAfter:
        - build
      workspaces: # 传递 workspaces
        - name: go-repo
          workspace: go-repo-pvc
      params: # 传递参数
        - name: image
          value: $(params.image):$(params.image_tag)
        - name: registry_url
          value: $(params.registry_url)
        - name: registry_mirror
          value: $(params.registry_mirror)
    - name: manifests
      taskRef:
        name: change-manifests
      runAfter:
        - docker
      params:
      - name: git_url
        value: $(params.git_infra_url)
      - name: git_manifest_dir
        value: $(params.git_manifest_dir)
      - name: image_tag
        value: $(params.image_tag)
    - name: sync
      taskRef:
        name: sync
      runAfter:
        - manifests
      params:
      - name: argocd_url
        value: $(params.argocd_url)
      - name: argocd_secret
        value: $(params.argocd_secret)
      - name: app_name
        value: $(params.app_name)
      - name: app_revision
        value: $(params.app_revision)

最后创建用于 Argo CD 登录使用的 Secret 对象:

apiVersion: v1
kind: Secret
metadata:
  name: argocd-auth
type: Opaque
stringData:
  username: admin
  password: admin321

最后修改 Tekton Triggers 中的 Template,如下所示:

# gitlab-template.yaml
apiVersion: triggers.tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
  name: gitlab-template
spec:
  params: # 定义参数,和 TriggerBinding 中的保持一致
    - name: gitrevision
    - name: gitrepositoryurl
  resourcetemplates: # 定义资源模板
    - apiVersion: tekton.dev/v1beta1
      kind: PipelineRun # 定义 pipeline 模板
      metadata:
        generateName: gitlab-run- # TaskRun 名称前缀
      spec:
        serviceAccountName: tekton-build-sa
        pipelineRef:
          name: pipeline
        workspaces:
          - name: go-repo-pvc
            persistentVolumeClaim:
              claimName: go-repo-pvc
        params:
          - name: git_url
            value: $(tt.params.gitrepositoryurl)
          - name: git_infra_url
            value: git.k8s.local/course/devops-demo-deploy.git
          - name: image
            value: "harbor.k8s.local/course/devops-demo"
          - name: image_tag
            value: "$(tt.params.gitrevision)"
          - name: argocd_url
            value: argocd.k8s.local
          - name: argocd_secret
            value: argocd-auth
          - name: app_name
            value: devops-demo

现在我们的整个流水线就更加精简了。现在我们去应用仓库中修改下源代码并提交就可以触发我们的流水线了。

可以看到当我们提交代码后,整个流水线构建会一直卡在最后的 sync 任务,这是因为我们执行了 argocd app wait $(params.app_name) --health 这个命令,需要等待应用健康后才会退出。

$ curl devops-demo.k8s.local
{"msg":"Hello Tekton + ArgoCD On GitLab"}

但实际上上面我们的应用已经部署成功了,只是 Argo CD 的健康检查没有通过,Argo CD 为几种标准的 Kubernetes 资源提供了内置的健康策略,然后将这些策略作为一个整体呈现在应用的健康状态中,比如会检查副本数是否正常,PVC 是否绑定等,而对于 Ingress 资源会检查 status.loadBalancer.ingress 列表是否非空,需要至少有一个 hostname 或 IP 值,而我们这里部署的 Ingress 中的值为空:

$ kubectl get ingress devops-demo -o yaml
apiVersion: extensions/v1beta1
kind: Ingress
......
spec:
  rules:
  - host: devops-demo.k8s.local
    http:
      paths:
      - backend:
          serviceName: devops-demo
          servicePort: http
        path: /
        pathType: ImplementationSpecific
status:
  loadBalancer: {}

所以健康检查一直不通过,在 Argo CD 页面上也可以证实是 Ingress 导致健康检查没通过:

这个时候需要我们去自定义 Ingress 资源的监控检查方式,Argo CD 支持用 Lua 来编写检查规则,修改 Argo CD 的 Configmap 配置文件:

$ kubectl edit cm -n argocd argocd-cm
# Please edit the object below. Lines beginning with a ''#'' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  resource.customizations: |  # 定制 Ingress 资源的健康检查方式
    extensions/Ingress:
        health.lua: |
          hs = {}
          hs.status = "Healthy"
          return hs
......

修改完成后,我们的应用就会变成健康状态了。

如果需要回滚,则可以直接在 Argo CD 页面上点击 HISTORY AND ROLLBACK 安装查看部署的历史记录选择回滚的版本即可:

可以查看整个 Tekton 流水线的状态:

$ tkn pr describe gitlab-run-vdlm6
Name:              gitlab-run-vdlm6
Namespace:         default
Pipeline Ref:      pipeline
Service Account:   tekton-build-sa
Timeout:           1h0m0s
Labels:
 tekton.dev/pipeline=pipeline
 triggers.tekton.dev/eventlistener=gitlab-listener
 triggers.tekton.dev/trigger=gitlab-push-events-trigger
 triggers.tekton.dev/triggers-eventid=eeda9157-5eb3-4399-be4b-88955cb56764

️  Status

STARTED         DURATION    STATUS
minutes ago   2 minutes   Succeeded

 Resources

 No resources

⚓ Params

 NAME              VALUE
 ∙ git_url         http://git.k8s.local/course/devops-demo.git
 ∙ git_infra_url   git.k8s.local/course/devops-demo-deploy.git
 ∙ image           harbor.k8s.local/course/devops-demo
 ∙ image_tag       332798d9e28422341fd64704ab9b54b944d77084
 ∙ argocd_url      argocd.k8s.local
 ∙ argocd_secret   argocd-auth
 ∙ app_name        devops-demo

 Results

 No results

 Workspaces

 NAME            SUB PATH   WORKSPACE BINDING
 ∙ go-repo-pvc   ---        PersistentVolumeClaim (claimName=go-repo-pvc)

  Taskruns

 NAME                                 TASK NAME   STARTED         DURATION     STATUS
 ∙ gitlab-run-vdlm6-sync-svmxl        sync        3 minutes ago   42 seconds   Succeeded
 ∙ gitlab-run-vdlm6-manifests-d297d   manifests   3 minutes ago   26 seconds   Succeeded
 ∙ gitlab-run-vdlm6-docker-g2tqx      docker      4 minutes ago   48 seconds   Succeeded
 ∙ gitlab-run-vdlm6-build-mkcrd       build       4 minutes ago   9 seconds    Succeeded
 ∙ gitlab-run-vdlm6-test-gjr4c        test        4 minutes ago   4 seconds    Succeeded
 ∙ gitlab-run-vdlm6-clone-57vpw       clone       4 minutes ago   8 seconds    Succeeded

最后用一张图来总结下我们使用 Tekton 结合 Argo CD 来实现 GitOps 的工作流:




K8S 进阶训练营


  点击屏末  | 即刻学习


扫描二维码获取

更多云原生知识





k8s 技术圈






文章转载自 k8s 技术圈点击这里阅读原文了解更多


  • 中国 KubeCon + CloudNativeCon 演讲提案征集|截止日期:7 月 25 日


CNCF 概况(幻灯片)

扫描二维码联系我们!




CNCF (Cloud Native Computing Foundation) 成立于 2015 年 12 月,隶属于 Linux  Foundation,是非营利性组织。 

CNCF云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。请长按以下二维码进行关注。

本文分享自微信公众号 - CNCF(lf_cncf)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与 “OSC 源创计划”,欢迎正在阅读的你也加入,一起分享。

Argo CD使用指南:如何构建一套完整的GitOps?

Argo CD使用指南:如何构建一套完整的GitOps?

随着Kubernetes继续将自己确立为容器编排的行业标准,为你的应用和工具找到使用声明式模型的有效方法是成功的关键。在这篇文章中,我们将在AWS中建立一个K3s Kubernetes集群,然后使用Argo CD和Vault实现安全的GitOps。你可以在以下两个链接中分别查看基础架构以及Kubernetes umbrella应用程序:

https://github.com/atoy3731/a...

https://github.com/atoy3731/k...

以下是我们将会使用到的组件:

  • AWS——这是我们将在底层基础设施使用的云提供商。它将管理我们的虚拟机以及Kubernetes工作所需的网络,并允许Ingress从外界进入集群。
  • K3s——由Rancher开发的轻量级Kubernetes发行版。它对许多alpha功能和云插件进行了清理,同时也使用关系型数据库(本例中是RDS)代替etcd进行后端存储。
  • Rancher——API驱动的UI,可以轻松管理你的Kubernetes集群
  • Vault——Hashicorp的密钥管理实现。我将使用Banzai Cloud Vault的bank-- vaults实现,它可以通过使用Admission Webhook将密钥直接注入pod中。这大大减轻了你在Git仓库中存储密钥的需求。
  • Argo CD——这是一个GitOps工具,可以让你在Git中维护Kubernetes资源的状态。Argo CD会自动将你的Kubernetes资源与Git仓库中的资源进行同步,同时也确保集群内对manifest的手动更改会自动还原。这保证了你的声明式部署模式。
  • Cert Manager或LetsEncrypt——提供了一种为Kubernetes Ingress自动生成和更新证书的方法。

让我们先从AWS基础架构开始。

前期准备

你需要在你的系统中安装以下CLI:

  • Terraform
  • Kubectl
  • AWS

同时,你还需要AWS管理员访问权限以及一个访问密钥。如果你没有,你可以使用信用卡创建一个账户。

最后,你需要一个可以管理/更新的托管域名,以指向你的基于Kubernetes弹性负载均衡器(ELB)。如果你还没有,建议你在NameCheap上开一个账户,然后购买一个.dev域名。它价格便宜,而且效果很好。

AWS基础架构

对于我们的AWS基础架构,我们将使用Terraform与S3支持来持久化状态。这为我们提供了一种方法来声明性地定义我们的基础架构,并在我们需要的时候反复进行更改。在基础设施仓库中,你会看到一个k3s/example.tfvars文件。我们需要根据我们特定的环境/使用情况更新这个文件,设置以下值:

  • db_username — 将应用于Kubernetes后端存储的RDS实例的管理员用户名
  • db_password — RDS用户的管理员密码。这通常应该在你的terraform apply命令内联过程中传递此参数,但为了简单起见,我们将在文件中设置它。
  • public_ssh_key — 你的公共SSH密钥,当你需要SSH到Kubernetes EC2s时,你将使用它。
  • keypair_name — 要应用于你的public_ssh_key的密钥对名称。
  • key_s3_bucket_name — 生成的bucket将在集群成功创建时存储你的kubeconfig文件。

如果你想修改集群大小或设置特定的CIDRs(无类域间路由),可以设置下面的一些可选字段,但默认情况下,你会得到一个6节点(3个服务器,3个代理)的K3s集群。

同时,你将需要创建S3 bucket来存储你的Terraform状态并且在k3s/backends/s3.tfvarsk3s/main.tf文件中更改bucket字段来与其匹配。

一旦我们更新了所有的字段,并创建了S3状态bucket,我们就开始应用Terraform吧。首先,确保你在AWS账户中有一个管理IAM用户并且你已经在系统上正确设置了环境变量或AWS凭证文件,以便能够与AWS API对接,然后运行以下命令:

cd k3s/
terraform init -backend-config=backends/s3.tfvars
terraform apply -var-file=example.tfvars

一旦你执行以上命令,Terraform会在apply成功后输出预期的AWS状态。如果一切看起来都符合预期,请输入yes。这时候由于RDS集群的原因,需要5—10分钟的时间来配置AWS资源。

验证你的Kubernetes集群

Terraform成功应用之后(再多等几分钟的时间确保K3s已经部署完毕),你需要使用以下命令从S3 bucket中抓取kubeconfig文件(替换你在example.tfvars中输入的bucket名称):

aws s3 cp s3://YOUR_BUCKET_NAME/k3s.yaml ~/.kube/config

这应该成功完成,让你现在能够与你的集群通信。让我们检查一下我们的节点状态,在继续之前,确保它们都处于就绪状态。

$ kubectl get nodes
NAME                         STATUS   ROLES    AGE   VERSION
ip-10-0-1-208.ec2.internal   Ready    <none>   39m   v1.18.9+k3s1
ip-10-0-1-12.ec2.internal    Ready    master   39m   v1.18.9+k3s1
ip-10-0-1-191.ec2.internal   Ready    master   39m   v1.18.9+k3s1
ip-10-0-2-12.ec2.internal    Ready    master   39m   v1.18.9+k3s1
ip-10-0-2-204.ec2.internal   Ready    <none>   39m   v1.18.9+k3s1
ip-10-0-1-169.ec2.internal   Ready    <none>   39m   v1.18.9+k3s1

我们也来看看Argo CD的状态,它是通过manifest自动部署的:

$ kubectl get pods -n kube-system | grep argocd
helm-install-argocd-5jc9s                        0/1     Completed   1          40m
argocd-redis-774b4b475c-8v9s8                    1/1     Running     0          40m
argocd-dex-server-6ff57ff5fd-62v9b               1/1     Running     0          40m
argocd-server-5bf58444b4-mpvht                   1/1     Running     0          40m
argocd-repo-server-6d456ddf8f-h9gvd              1/1     Running     0          40m
argocd-application-controller-67c7856685-qm9hm   1/1     Running     0          40m

现在我们可以继续为我们的ingress和证书自动化配置通配符DNS。

DNS配置

对于DNS,我通过Namecheap获得atoy.dev域名,但你可以使用任何你喜欢的DNS供应商。我们需要做的是创建一个通配符CNAME条目,以将所有请求路由到AWS ELB,它正在管理应用程序的ingress。

首先,通过访问你的AWS控制台获取你的弹性负载均衡器主机名称——导航到EC2部分并在左边菜单栏上点击Load Balancers。然后你应该看到一个使用随机字符创建的新LoadBalancer。如果你检查tag,它应该引用你的新Kubernetes集群。

你需要从该条目复制DNS名称。为我的域名访问NamecCheap 高级DNS页面,并输入*.demo.atoy.dev 的CNAME条目。 指向你从AWS复制的域名。你可以根据你的提供商/域名调整这个名称:

要验证它是否有效,你可以安装/使用nslookup来确保它解析到正确的主机名:

$ nslookup test.demo.atoy.dev
Server:  71.252.0.12
Address: 71.252.0.12#53

Non-authoritative answer:
test.demo.atoy.dev canonical name = a4c6dfd75b47a4b1cb85fbccb390fe1f-529310843.us-east-1.elb.amazonaws.com.
Name: a4c6dfd75b47a4b1cb85fbccb390fe1f-529310843.us-east-1.elb.amazonaws.com
Address: 52.20.5.150
Name: a4c6dfd75b47a4b1cb85fbccb390fe1f-529310843.us-east-1.elb.amazonaws.com
Address: 23.20.0.2

现在到Umbrella应用程序。

Argo CD和Umbrella应用程序

我们已经知道Argo CD已经部署好了,但现在我们要使用Argo CD的App-of-Apps部署模型来部署我们的其余工具套件。由于我们使用的是GitOps,你需要将k8s-tools-app仓库fork到你自己的Github账户上,然后我们需要做一些修改来匹配你各自的环境。

  1. 你需要为https://github.com/atoy3731/k... 进行全局查找/替换,并将其更改到之前fork的新存储库git URL。这使你可以管理自己的环境,让Argo CD可以从那里拉取。另外,需要确保你的Git仓库是公开的,以便Argo CD可以访问它。
  1. 在resources/tools/resources/other-resources.yaml中,更改argoHostand issuerEmail,使其与你的域名和邮箱相匹配。
  1. 在resources/tools/resources/rancher.yaml中,更改主机名称和邮件以匹配各自的域名和email。
  1. 在resources/apps/resources/hello-world.yaml中,将两个引用app.demo.aptoy.dev改为与你的域名一致。

一旦你做了这些更新,继续提交/推送你的更改到你的forked Github仓库。现在你已经准备好应用umbrella应用程序了。在本地克隆的仓库中执行以下操作:

$ kubectl apply -f umbrella-tools.yaml
appproject.argoproj.io/tools created
application.argoproj.io/umbrella-tools created

现在,Argo CD将开始配置所有其他工具,这些工具是仓库为你的集群定义的。你可以通过执行以下操作来获得已部署的应用程序的列表:

$ kubectl get applications -n kube-system
NAME                AGE
other-resources     56m
umbrella-tools      58m
rancher             57m
vault-impl          57m
vault-operator      58m
vault-webhook       57m
cert-manager        57m
cert-manager-crds   58m

你将不得不等待5分钟左右的时间,让一切都准备好,让LetsEncrypt生成暂存证书。一旦事情按预期运行,你应该看到两个生成的Ingress条目,你可以通过浏览器访问:

$ kubectl get ingress -A
NAMESPACE       NAME             CLASS    HOSTS                     ADDRESS                                                                  PORTS     AGE
cattle-system   rancher          <none>   rancher.demo.atoy.dev   a4c6dfd75b47a4b1cb85fbccb390fe1f-529310843.us-east-1.elb.amazonaws.com   80, 443   59m
kube-system     argocd-ingress   <none>   argo.demo.atoy.dev      a4c6dfd75b47a4b1cb85fbccb390fe1f-529310843.us-east-1.elb.amazonaws.com   80, 443   58m

现在你可以通过 https://rancher.YOUR-DOMAIN 浏览 Rancher,通过 https://argo.YOUR-DOMAIN 浏览 Argo CD。

NOTE 1:为了避免LetsEncrypt的任何速率限制,我们使用的是无效的暂存证书。这有一个好处是当你在你的浏览器访问Argo、Rancher或你的hello world应用程序,它会给你一个SSL异常。使用Chrome浏览器,在你的异常页面加载时输入thisisunsafe,它会让你绕过它。你也可以了解更新Cert-manager的ClusterIssuer,以使用生产级的可信证书。

NOTE 2:K3s预装了一个Traefik作为ingress controller,出于简单起见,我们直接使用它。

NOTE 3:首次登录Rancher后,你需要生成一个密码,并接受用于访问Rancher的URI。URI应该是预先加载在表单中的,所以您可以直接点击 "Okay"。

NOTE 4: 要登录Argo CD,它使用admin作为用户名,使用argocd-server pod名作为密码。你可以通过下面的操作来获得这个服务器的pod名(本例中是argocd-server-5bf58444b4-mpvht)。

$ kubectl get pods -n kube-system | grep argocd-server
argocd-server-5bf58444b4-mpvht                   1/1     Running     0          64m

现在你应该能够访问Argo CD UI,登录并查看,如下所示:

既然我们的工具已经部署完成,让我们在Vault中存储密钥,以便hello world应用程序提取。

在Vault中创建密钥

为了让事情变得简单,在你的工具库中有一个帮助脚本。运行以下命令来获取Vault管理员令牌和端口转发命令:

$ sh tools/vault-config.sh
Your Vault root token is: s.qEl4Ftr4DR61dmbH3umRaXP0

Run the following:
export VAULT_TOKEN=s.qEl4Ftr4DR61dmbH3umRaXP0
export VAULT_CACERT=/Users/adam.toy/.vault-ca.crt
kubectl port-forward -n vault service/vault 8200 &

You will then be able to access Vault in your browser at: [https://localhost:8200](https://localhost:8200)

运行输出的命令,然后导航到https://localhost:8200。输入上面的root token进行登录。

当你登录时,你应该在一个密钥引擎页面。点击Secret/条目,然后点击右上方的创建密钥。我们将创建一个demo密钥,所以添加以下内容并点击保存:

现在我们已经为hello world应用程序准备好密钥了。

部署Hello World 应用程序

现在,回到我们的父版本,让我们运行下面的代码来部署hello world应用程序:

$ kubectl apply -f umbrella-apps.yaml
appproject.argoproj.io/apps created
application.argoproj.io/umbrella-apps created

创建完成后,回到Argo CD UI,你先应该看到两个新应用程序,umbrella-apps和demo-app。单击demo-app,然后等待所有资源正常运行:

一旦状态都是healthy之后,你应该能够通过访问https://app.YOUR-DOMAIN 导航到你的应用程序。

让我们也来验证一下我们的Vault密钥是否被注入到我们的应用程序pod中。在Argo CD UI的demo-app中,点击应用程序的一个Pod,然后点击顶部的日志标签。左边应该有两个容器,选择 test-deployment容器。在日志的顶部,你应该看到你的密钥在两行等号之间:

测试GitOps

现在我们来测试一下Argo CD,确保当我们在仓库中做一些更改时它能够自动同步。

在你的工具库中,找到resources/apps/resources/hello-world.yaml文件,将replicaCount的值从5改到10。提交并推送你的更改到主分支,然后在Argo CD UI中导航回demo-app。当Argo CD达到它的刷新间隔时,它会自动开始部署其他5个应用程序副本(如果你不想等待,可以点击你的 umbrella-apps Argo应用程序 ** 中的刷新按钮):

清 除

如果你准备拆掉你的集群,你需要先进入AWS控制台、EC2服务,然后点击Load Balancers。你会看到Kubernetes云提供商创建了一个ELB,但不是由Terraform管理的,你需要清理它。你还需要删除该ELB正在使用的安全组。

清理了ELB之后,运行以下命令并在出现提示时输入yes

terraform destroy -var-file=example.tfvars

下一步是什么?

我们已经有一个很好的工具集来使用GitOps部署应用程序。那么下一步是什么?如果你愿意接受挑战,可以尝试在hello world应用旁边部署自己的应用,甚至尝试通过在应用manifest仓库中更新镜像标签来实现CI/CD。这样一来,当构建新的应用镜像时,新的标签就会在manifest仓库中自动更新,Argo CD就会部署新版本。

ArgoCD + KubeVela:以开发者为中心的 GitOps

ArgoCD + KubeVela:以开发者为中心的 GitOps

10 人将获赠 CNCF 士多 $100 礼券!

来参与 2020 年 CNCF 中国云原生调查

问卷链接(https://www.wjx.cn/jq/97146486.aspx




客座文章作者:Deng Hongchao,阿里巴巴软件工程师


介绍


Argo CD 是为 Kubernetes 提供的 GitOps 持续交付工具。它是 CNCF Argo 项目的一部分,该项目是一组 Kubernetes 原生工具,用于在 Kubernetes 上运行和管理作业和应用程序。

https://github.com/argoproj/argo-cd/


KubeVela 是一个基于 Kubernetes 和 OAM(开放应用程序模型,Open Application Model)的开源应用程序引擎。KubeVela 主要是为平台和运营团队设计的,以便在 Kubernetes 上轻松创建简单但面向开发人员的高度可扩展的抽象。对开发人员(也就是最终用户)隐藏了在 Kubernetes 上配置应用程序清单的很多复杂性,比如伸缩策略、部署策略和入口,但允许平台团队基于组织策略独立定制和控制这些配置。

https://github.com/oam-dev/kubevela


在这篇博文中,我们将分享基于阿里云的用例,使用 Argo CD 和 KubeVela 构建以开发者为中心的持续应用交付流水线的经验。


以开发者为中心的 GitOps 体验


理想情况下,开发人员希望专注于编写应用程序并将其代码推送到 git 仓库上,而不必担心 CI/CD 流水线以及配置和运行应用程序时的其他操作问题。Kubernetes 上一个非常流行的模式是将应用程序从 git 自动部署到生产环境中。这就是 Argo CD 的用武之地。它会持续监视 git 仓库的新提交,并自动将它们部署到生产环境中。Argo CD 应用仓库中预定义的 Kubernetes 部署清单文件来创建或升级在 Kubernetes 上运行的应用程序。这种模式被称为 GitOps,是在阿里巴巴的现代云原生堆栈中实现持续自动应用交付的关键。


虽然概念上很简单,但在将 GitOps 应用到更广泛的最终用户场景时,会出现几个重要的问题。第一个问题是,实际的生产应用程序是复杂的,需要开发人员理解如何配置许多不同类型的 Kubernetes 资源。第二个问题(与第一个问题相关)是,对于每个开发人员来说,学习如何正确配置和维护所有这些对象,同时遵守组织安全、遵从性和操作策略变得非常具有挑战性。即使是简单的错误配置也可能导致部署失败,甚至服务不可用。第三个问题是,当 Kubernetes 规范或组织策略发生变化时,必须更新所有应用程序清单以反映这些变化。对于一个可能拥有数千个应用程序和数百万行 Kubernetes 清单文件的 YAML 的组织来说,这是一项巨大的任务。这些问题产生了对应用程序抽象的强烈需求,该抽象将开发人员与不会直接影响其应用程序的平台和操作关注点隔离开来,并提供了一个锚来避免配置漂移。Kubernetes 的核心抽象,通过有意的设计,并没有为抽象应用程序提供一个标准的机制。


考虑到这个目标,KubeVela 被创建和设计为一个最小的、可扩展的应用程序引擎,供平台构建人员在 Kubernetes 上创建 “类似 PaaS” 的体验。具体来说,KubeVela 提供了简单而有效的抽象,将应用程序配置问题与平台和操作问题分离开来。下面是一个名为 appfile 的工件示例:



通过使用 appfile 并将其与 Argo CD 一起部署,开发人员只需要编写一个简单的应用配置,并将代码推送到 git。然后,他们的应用程序将被自动部署,并开始在目标 Kubernetes 集群上处理实时流量。在幕后,平台和运营团队有能力用 CUElang 模板预先定义和 / 或修改这些抽象的行为,并确保它们满足组织的安全性、遵从性和其他运营需求。

https://github.com/oam-dev/kubevela/tree/master/hack/vela-templates/cue


在下面,我们将更详细地解释上述 GitOps 工作流是如何工作的。


KubeVela 搭配 Argo CD


先决条件

对于平台运营者来说,唯一的 “技巧” 是使 KubeVela 成为 Argo CD 的自定义插件,这样它就能 “理解” appfile 格式。


注册插件

Argo CD 允许通过编辑 argocd-cm ConfigMap 集成额外的配置管理插件,如 Kubevela。


将以下文件保存为 argo-cm.yaml:

data: configManagementPlugins: | - name: vela init: command: ["sh", "-xc"] args: ["vela traits"] generate: command: ["sh", "-xc"] args: ["vela export"]

然后执行以下命令更新 argocd-cm ConfigMap:

kubectl -n argocd patch cm/argocd-cm -p "$(cat argo-cm.yaml)"


配置 argo-repo-server

Argo CD 有一个名为 argo-repo-server 的组件,它从 Git 中提取部署清单文件并呈现最终输出。在这里,我们将使用 vela cli 解析 appfile 并将其呈现到 Kubernetes 资源中。


首先,使用所需的 kubeconfig 证书创建 ConfigMap,以便与已经安装了 KubeVela 的目标 Kubernetes 集群进行通信:

apiVersion: v1kind: ConfigMapmetadata: name: vela-kubeconfig namespace: argocddata: config: | # fill your kubeconfig here

创建了上面的 ConfigMap,更新 argo-repo-server 以保存 vela cli 和凭证。


将以下补丁文件保存为 deploy.yaml:

spec:
template: spec: # 1. Define an emptyDir volume which will hold the custom binaries volumes: - name: custom-tools emptyDir: {} - name: vela-kubeconfig configMap: name: vela-kubeconfig # 2. Use an init container to download/copy custom binaries initContainers: - name: download-tools image: oamdev/argo-tool:v1 command: [sh, -c] args: - cp /app/vela /custom-tools/vela volumeMounts: - mountPath: /custom-tools name: custom-tools # 3. Volume mount the custom binary to the bin directory containers: - name: argocd-repo-server env: - name: KUBECONFIG value: /home/argocd/.kube/config volumeMounts: - mountPath: /usr/local/bin/vela name: custom-tools subPath: vela - mountPath: /home/argocd/.kube/ name: vela-kubeconfig

然后执行以下命令更新 argocd-repo-server 部署:

kubectl -n argocd patch deploy/argocd-repo-server -p "$(cat deploy.yaml)"

到目前为止,vela 插件应该已经注册,argo-repo-server 应该可以访问 vela cli,将 appfile 呈现到 Kubernetes 资源中。


在 Argo CD 中使用 KubeVela


现在,作为应用程序开发人员,你可以通过 GitOps 部署使用 KubeVela 指定的应用程序。通过 argocd 命令行创建应用时,要记住指定插件名:

argocd app create <appName> --config-management-plugin vela

让我们用 Argo CD UI 来演示一下。下面是一个包含 appfile 的仓库示例:

https://github.com/hongchaodeng/argocd-example-apps/tree/master/appfile


配置 Argo CD 来监视 Git 推送的仓库,包括初始状态:



任何推到仓库现在将自动检测和部署:



就是这样!现在你可以创建 / 修改 appfile,推送到 git,Argo CD 会自动将它们部署到你的 Kubernetes 集群,所有这些都是通过神奇的 GitOps!


了解更多


所有上述设置和配置均可在此仓库中获得。KubeVela core 和 Argo CD 目前正在阿里巴巴的 web 应用平台上生产应用,并已用于内部和公共云服务上的数万个应用程序。请尝试一下,让我们知道你的想法!

https://github.com/oam-dev/kubevela/tree/master/docs/examples/argo


CNCF Slack #kubevela 频道:

  • https://slack.cncf.io/

ArgoCD Slack 频道:

  • https://argoproj.github.io/community/join-slack


点击【阅读原文】阅读网站原文。


扫描二维码联系我们!




CNCF (Cloud Native Computing Foundation) 成立于 2015 年 12 月,隶属于 Linux  Foundation,是非营利性组织。 

CNCF云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。请长按以下二维码进行关注。

本文分享自微信公众号 - CNCF(lf_cncf)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与 “OSC 源创计划”,欢迎正在阅读的你也加入,一起分享。

ArgoCD + KubeVela:以开发者为中心的GitOps

ArgoCD + KubeVela:以开发者为中心的GitOps

10人将获赠CNCF士多$100礼券!
来参与2020年CNCF中国云原生调查

Image

问卷链接(https://www.wjx.cn/jq/9714648...)


客座文章作者:Deng Hongchao,阿里巴巴软件工程师

介绍

Argo CD是为Kubernetes提供的GitOps持续交付工具。它是CNCF Argo项目的一部分,该项目是一组Kubernetes原生工具,用于在Kubernetes上运行和管理作业和应用程序。

KubeVela是一个基于Kubernetes和OAM(开放应用程序模型,Open Application Model)的开源应用程序引擎。KubeVela主要是为平台和运营团队设计的,以便在Kubernetes上轻松创建简单但面向开发人员的高度可扩展的抽象。对开发人员(也就是最终用户)隐藏了在Kubernetes上配置应用程序清单的很多复杂性,比如伸缩策略、部署策略和入口,但允许平台团队基于组织策略独立定制和控制这些配置。

在这篇博文中,我们将分享基于阿里云的用例,使用Argo CD和KubeVela构建以开发者为中心的持续应用交付流水线的经验。

以开发者为中心的GitOps体验

理想情况下,开发人员希望专注于编写应用程序并将其代码推送到git仓库上,而不必担心CI/CD流水线以及配置和运行应用程序时的其他操作问题。Kubernetes上一个非常流行的模式是将应用程序从git自动部署到生产环境中。这就是Argo CD的用武之地。它会持续监视git仓库的新提交,并自动将它们部署到生产环境中。Argo CD应用仓库中预定义的Kubernetes部署清单文件来创建或升级在Kubernetes上运行的应用程序。这种模式被称为GitOps,是在阿里巴巴的现代云原生堆栈中实现持续自动应用交付的关键。

虽然概念上很简单,但在将GitOps应用到更广泛的最终用户场景时,会出现几个重要的问题。第一个问题是,实际的生产应用程序是复杂的,需要开发人员理解如何配置许多不同类型的Kubernetes资源。第二个问题(与第一个问题相关)是,对于每个开发人员来说,学习如何正确配置和维护所有这些对象,同时遵守组织安全、遵从性和操作策略变得非常具有挑战性。即使是简单的错误配置也可能导致部署失败,甚至服务不可用。第三个问题是,当Kubernetes规范或组织策略发生变化时,必须更新所有应用程序清单以反映这些变化。对于一个可能拥有数千个应用程序和数百万行Kubernetes清单文件的YAML的组织来说,这是一项巨大的任务。这些问题产生了对应用程序抽象的强烈需求,该抽象将开发人员与不会直接影响其应用程序的平台和操作关注点隔离开来,并提供了一个锚来避免配置漂移。Kubernetes的核心抽象,通过有意的设计,并没有为抽象应用程序提供一个标准的机制。

考虑到这个目标,KubeVela被创建和设计为一个最小的、可扩展的应用程序引擎,供平台构建人员在Kubernetes上创建“类似PaaS”的体验。具体来说,KubeVela提供了简单而有效的抽象,将应用程序配置问题与平台和操作问题分离开来。下面是一个名为appfile的工件示例:

Image

通过使用appfile并将其与Argo CD一起部署,开发人员只需要编写一个简单的应用配置,并将代码推送到git。然后,他们的应用程序将被自动部署,并开始在目标Kubernetes集群上处理实时流量。在幕后,平台和运营团队有能力用CUElang模板预先定义和/或修改这些抽象的行为,并确保它们满足组织的安全性、遵从性和其他运营需求。

在下面,我们将更详细地解释上述GitOps工作流是如何工作的。

KubeVela搭配Argo CD

先决条件

对于平台运营者来说,唯一的“技巧”是使KubeVela成为Argo CD的自定义插件,这样它就能“理解”appfile格式。

注册插件

Argo CD允许通过编辑argocd-cm ConfigMap集成额外的配置管理插件,如Kubevela。

将以下文件保存为argo-cm.yaml:

data:
 configManagementPlugins: |
 - name: vela
 init:
 command: ["sh", "-xc"]
 args: ["vela traits"]
 generate:
 command: ["sh", "-xc"]
 args: ["vela export"]

然后执行以下命令更新argocd-cm ConfigMap:

kubectl -n argocd patch cm/argocd-cm -p "$(cat argo-cm.yaml)"

配置argo-repo-server

Argo CD有一个名为argo-repo-server的组件,它从Git中提取部署清单文件并呈现最终输出。在这里,我们将使用vela cli解析appfile并将其呈现到Kubernetes资源中。

首先,使用所需的kubeconfig证书创建ConfigMap,以便与已经安装了KubeVela的目标Kubernetes集群进行通信:

apiVersion: v1
kind: ConfigMap
metadata:
 name: vela-kubeconfig
 namespace: argocd
data:
 config: |
 # fill your kubeconfig here

当创建了上面的ConfigMap,更新argo-repo-server以保存vela cli和凭证。

将以下补丁文件保存为deploy.yaml:

spec:
 template:
 spec:
 # 1. Define an emptyDir volume which will hold the custom binaries
 volumes:
 - name: custom-tools
 emptyDir: {}
 - name: vela-kubeconfig
 configMap:
 name: vela-kubeconfig
 # 2. Use an init container to download/copy custom binaries
 initContainers:
 - name: download-tools
 image: oamdev/argo-tool:v1
 command: [sh, -c]
 args:
 - cp /app/vela /custom-tools/vela
 volumeMounts:
 - mountPath: /custom-tools
 name: custom-tools
 # 3. Volume mount the custom binary to the bin directory
 containers:
 - name: argocd-repo-server
 env:
 - name: KUBECONFIG
 value: /home/argocd/.kube/config
 volumeMounts:
 - mountPath: /usr/local/bin/vela
 name: custom-tools
 subPath: vela
 - mountPath: /home/argocd/.kube/
 name: vela-kubeconfig

然后执行以下命令更新argocd-repo-server部署:

kubectl -n argocd patch deploy/argocd-repo-server -p "$(cat deploy.yaml)"

到目前为止,vela插件应该已经注册,argo-repo-server应该可以访问vela cli,将appfile呈现到Kubernetes资源中。

在Argo CD中使用KubeVela

现在,作为应用程序开发人员,你可以通过GitOps部署使用KubeVela指定的应用程序。通过argocd命令行创建应用时,要记住指定插件名:

argocd app create <appName> --config-management-plugin vela

让我们用Argo CD UI来演示一下。下面是一个包含appfile的仓库示例:

https://github.com/hongchaode...

配置Argo CD来监视Git推送的仓库,包括初始状态:

Image

任何推到仓库现在将自动检测和部署:

Image

就是这样!现在你可以创建/修改appfile,推送到git,Argo CD会自动将它们部署到你的Kubernetes集群,所有这些都是通过神奇的GitOps!

了解更多

所有上述设置和配置均可在此仓库中获得。KubeVela core和Argo CD目前正在阿里巴巴的web应用平台上生产应用,并已用于内部和公共云服务上的数万个应用程序。请尝试一下,让我们知道你的想法!

CNCF Slack #kubevela频道:

  • https://slack.cncf.io/

ArgoCD Slack频道:

  • https://argoproj.github.io/co...

点击阅读网站原文。


CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。扫描二维码关注CNCF微信公众号。
image

DevOps 选型指南:Zadig / 云效 / Coding/Jenkins/GitLab/Argo/Tekton

DevOps 选型指南:Zadig / 云效 / Coding/Jenkins/GitLab/Argo/Tekton

【直播预告】程序员逆袭 CEO 分几步?

打造一个功能全面、稳定且用户体验友好的 DevOps 平台对于推动持续集成、持续交付、团队协作和效率提升至关重要。企业在选择 DevOps 平台时,有的倾向于采用平台类产品,如 Zadig、云效、Coding 等;而另一些企业则基于企业文化和项目需求,在已有的 CI/CD 工具(如 Jenkins、GitLab、Argo、Tekton)基础上自建 DevOps 平台,以实现对企业内部 DevOps 方案的定制。无论是选择平台类产品还是自建平台,都需要在搭建之前进行充分的规划和评估,以确保满足企业的需求并提升 DevOps 实践的效率。

本文将详细分析各个 DevOps 平台和工具的设计理念、特点、局限性等,并从多个维度(团队规模和业务复杂度、多云策略和厂商关联、使用场景和业务需求等)出发,结合企业实际的业务需求给出建议,为企业 DevOps 选型指明方向。

 

DevOps 平台类产品

Zadig

Zadig 是由 KodeRover 公司基于 Kubernetes 研发的自助式云原生 DevOps 平台,服务端源码 100% 开放。Zadig 提供灵活可扩展的工作流支持、多种发布策略编排以及一键安全审核等特性。该平台还支持定制的企业级 XOps 敏捷效能看板,深度集成多种企业级平台,并通过项目模板化批量快速接入,实现数千个服务的一键纳管治理。其主要目标是帮助企业实现产研的数字化转型,使工程师成为创新引擎,并为数字经济的无限价值链接提供支持 [1]。

01-Zadig 具有以下几个核心特性:

  • 灵活易用的高并发工作流
  • 面向开发者的云原生环境
  • 高效协同的测试管理
  • 强大免运维的模板库
  • 安全可靠的发布管理
  • 稳定高效的客户交付
  • 客观精确的效能度量
  • 云原生 IDE 插件

02-Zadig 的核心优势:

  • 设计理念:产品级交付,包含代码、配置、数据全要素的交付
  • 底座真云原生架构:Zadig 基于 k8s 底座,支持较高规模的构建部署并发、多个微服务同时交付场景
  • 用户接入难度低:Zadig 支持导入和托管现有服务,并对现有流程几乎无侵入极简、开放,易于企业内落地,不需要改变用户行为
  • 产品可用性较强:3 年开源、大量一线真实场景高频使用打磨,积众家之所长,积累 15 万企业开发者,全球累计部署 50 万应用,2000 家企业高频使用,稳定可靠保证,内置众多最佳实践工作模式
  • 产品开放性较强:天生支持企业私有化部署,支持全球多地部署、分布式交付分发,针对具有全球化战略的企业更为友好

03-Zadig 的局限性:

  • 设计理念和其他 DevOps 平台存在不同,初次接触的用户需要一定时间学习和掌握
  • 系统依赖 K8s,对于对于未采用 K8s、完全处于传统主机环境的企业项目而言并不适用

 

云效

云效是阿里云提供的一站式 DevOps 平台,提供涵盖软件研发全生命周期的研发工具链和研发管理服务,并支持公共云、专有云多种部署形态。通过云原生新技术和研发新模式,助力创新创业和数字化转型企业快速实现研发敏捷和组织敏捷,打造 “双敏” 组织,实现多倍效能提升 [2]。

云效具有项目协作、代码管理、流水线、制品仓库、测试管理、应用交付平台、效能洞察等核心能力。

01 - 云效主要特点:

  • 开箱即用
  • 企业级安全保障
  • 实践经验模板化沉淀
  • 无缝对接阿里云产品

02 - 云效的局限性:

  • 系统比较厚重,迁移成本比较高
  • 耦合度较高,跟阿里云产品深度绑定,对于多云架构的支持不够友好
  • 对于非阿里云工具链的扩展较困难

云效与其他平台在设计理念上存在显著差异,云效专注于单应用的交付,将环境管理能力主要集中在应用维度。云效流水线以代码库为主要视角,随着业务增长,流水线数量迅速增加,配置管理难度加大,所以云效更适用于初期快速启动 DevOps 的场景。云效天然亲和阿里云资源和产品,对于多云需求或全球交付需求的企业而言,接入云效可能面临一定的适应难度。

 

Coding

Coding DevOps 是面向软件研发团队的一站式研发协作管理平台,提供从需求到设计、开发、构建、测试、发布到部署的全流程协同及研发工具支撑 [3]。

Coding 具有团队管理、项目协同、代码仓库、代码扫描、持续集成、持续部署、应用管理等核心能力

01-Coding 主要特点:

  • 一站式协作平台及研发工具链
  • 支持双态研发体系建设(瀑布模型、敏捷模型)
  • 项目度量数据可视化
  • 无缝集成第三方平台

02-Coding 的局限性:

  • 以代码库为核心的工作流,管理成本较高
  • 现有工程体系迁移有一定的成本
  • 耦合度较高,跟腾讯云产品深度绑定,对于多云架构的支持不够友好

和其他平台的定位上存在不同,Coding 是流程协同平台,一站式为开发者提供完整的 DevOps 工具链。由于其天然亲和腾讯云资源和产品,对于存在多云架构以及现有业务由其他云平台支撑的场景不够友好。在接入 Coding 过程中,需要做服务的初始化,有一定迁移成本。此外,Coding 构建和部署为两个单独的模块,对于习惯在一条工作流走完所有流程(构建、部署、测试、配置变更、数据变更等)的用户,可能需要重新适应或者调整使用方式。

 

DevOps 工具类产品

Jenkins

Jenkins 是一款开源、可扩展的自动化构建和交付工具。其设计初衷是为了满足不同团队和项目的需求,提供高度可扩展和灵活的平台。通过插件和扩展,Jenkins 赋予开发团队持续集成和交付的能力,帮助实现软件开发的自动化、协作和快速交付 [4]。

01-Jenkins 的主要特点:

  • 扩展性非常强,有大量的插件支持
  • 分布式构建
  • 流水线项目 pipeline as code 支持在代码仓库中管理

02-Jenkins 的局限性:

  • 系统本身安装过程不复杂,但对于插件管理非常繁琐
  • 项目实施难度大,所有任务都需要写脚本,维护成本高
  • Jenkinsfile 分散到不同的工程中,对于后期维护成本比较高

对用户而言,Jenkins 需依赖众多插件和大量脚本来解决业务交付过程中的构建、部署、测试和自动化流程串接的难题。对于云原生的场景而言需要通过脚本的方式来操作集群,对脚本维护和管理要求比较高。此外 Jenkins 通过插件来管理工作流的权限,权限管理负担较重。

Zadig 和 Jenkins 的比对请参阅 「Zadig vs. Jenkins 详细比对:时代的选择与开发者之选」一文。

 

GitLab CI/CD

GitLab 是一个基于 Git 的版本控制和协作平台。它提供了一套强大的工具,支持团队协作、代码托管、持续集成、持续交付等软件开发过程中的多个方面 [5]。

GitLab 具有代码仓库管理、CI/CD 流水线、效能管理、敏捷项目管理、集成其他工具等核心能力。

01-GitLab 的主要特点:

  • 一站式管理 DevOps 工具
  • 自动化工作流程加速软件交付
  • 与云厂商解耦

02-GitLab 的局限性:

  • As code 工作流配置不直观,学习和维护成本较高
  • 缺少基本环境管理能力,需另外搭建其他平台观测服务的情况
  • 多角色协同过程中,权限管理比较难,需要给运维测试代码仓库权限才能做 CI/CD,风险较大

GitLab CI/CD 设计理念是以代码仓库为核心,对于小型项目、单仓库顺序交付的场景较为友好,而对于更为复杂的项目和团队多角色协作,使用方面和管理上存在一定局限性。

 

Argo

Argo 是一个基于 Kubernetes CRD 实现的一个开源工具,基于 Kubernetes 的调度能力实现了工作流的控制和任务的运行。同时提供了一个 UI 方便用户查看任务的详情 [6]。

Argo 有三个核心产品 Workflows 、CD、Rollouts,为持续集成、持续交付、持续部署提供底层能力。

  • Workflows:云原生工作流引擎,支持编排构建、测试、部署等场景,支持声明式地管理复杂任务的执行流程
  • CD:基于 GitOps 的理念实现自动化部署、回滚和版本管理
  • Rollouts:用于实现 Kubernetes 上的蓝绿发布、金丝雀发布、渐进式发布等发布策略,确保生产发布的稳定性

01-Argo 的局限性:

  • 声明式的配置,维护和管理成本较高
  • 本身提供的 Web UI 无法企业级安全性和合规性要求
  • 适用 K8s 场景,对于传统主机场景并不适用

尽管 Argo 在云原生工作流引擎方面表现卓越,但对于完整的 DevOps 解决方案仍有欠缺,缺乏一系列企业管理功能,如环境管理、测试管理和权限控制,因此企业可能需要二次开发以建设相应的管理能力,以满足多角色协作的需求。

 

Tekton

Tekton 是一个谷歌开源的基于 Kubernetes 的云原生 CI/CD 框架,通过定义 CRD 的方式,让用户可以灵活的自定义流水线以满足自身 CI/CD 需求 [7]。

01-Tekton 的主要特点:

  • 高度抽象底层,方便企业定制工作流程
  • 与云原生环境无缝对接
  • 跨云厂商、技术栈和部署环境,帮助实现标准化的 CI/CD

02-Tekton 的局限性:

  • 适用 K8s 场景,对于传统主机场景并不适用
  • 自定义资源,有一定的学习成本

Tekton 注重底层灵活性,尽管灵活性强,但也显著增加了使用的难度。因此,要在 Tekton 上实现完整的 CI/CD 过程,就必须进行二次开发,门槛高,需要消耗一定建设成本。

 

各平台和工具之间的比较

 

DevOps 体系选型建议

企业在选择 DevOps 平台时,可以从多个角度进行考量,具体选择取决于企业的需求、文化和项目特点。以下是一些建议:

01 - 团队规模和业务复杂度:

  • 小型团队:适用于业务相对简单,研发为主的团队,可考虑选择 GitLab 方案,以代码管理作为入口,开启 GitLab CI/CD 功能,适用于强调全方位版本控制的企业。
  • 中型企业:对于复杂业务、多角色协作的情况,可选择一站式平台,如云效、Coding、Zadig,提供开箱即用的协作工具链。
  • 大型团队: 针对复杂场景、历史负担重的团队,建议选择功能全面、灵活可扩展的平台,如 Zadig,适用于复杂的异构环境交付流程和大规模的微服务架构。

02 - 多云架构及全球化战略需求:

  • 多云架构需求:若企业有多云和全球化战略,首选 Zadig。它天然支持企业私有化部署,厂商中立,友好支持多云架构,并满足国际化政策需求(i18n、出海合规等)。
  • 特定云服务需求: 对于已深度关联某一云厂商的企业,可考虑选择该厂商提供的平台,如云效(阿里云关联)或 Coding(腾讯云关联)。

03 - 使用场景和业务需求:

  • 全生命周期管理需求:若企业需全面管理全流程,可选择 Coding、云效提供的一站式协作平台。Zadig 平台侧重于研发和发布侧的一站式协同,需结合第三方实现业务到研发的衔接。
  • 云原生和微服务需求: 针对云原生和微服务架构,Zadig 提供灵活可扩展的工作流支持,适合大规模的构建、部署并发和产品级交付。
  • 传统单体业务:对于传统的单体业务,Jenkins 是一个灵活且支持强大插件的选择,满足基本的构建部署需求。
  • K8s 生态需求:Argo 是专注于 Kubernetes GitOps 持续交付工具,适用于新兴企业没有历史负担的情况。

04-DevOps 平台建设成本考量:

  • 围绕 CI/CD 工具自建平台成本估算:围绕 Jenkins、Tekton、Argo 工具搭建 DevOps 流程串接管理平台,需要组建跨职能、有丰富 DevOps 经验的团队,人力成本预估至少 300 万元 / 每年。
  • 直接购买商业 DevOps 平台成本估算:直接使用云厂商公有云或采用 Zadig 私有化 DevOps 平台。成本根据团队规模不同在 5 万元 - 20 万元 / 每年,可与供应商商谈获取更有竞争力的报价。
  • 开源商业产品与自研结合成本估算:针对 200 人以上团队,推荐选择 Zadig 作为自研平台的底层 “平台工程” 框架,结合自身业务进行定制开发。总体成本预估在 50 万元 / 每年左右,相较于从零开始搭建团队,采用 Zadig 可在成本上更具优势,同时满足企业特定需求。

05 - 数据的安全与合规考量:

  • 下公有云、上行业云:随着技术发展和政企数字化的深入,数据已成为组织中最核心的资产。数据的安全与合规已经成为国内越来越多组织的核心关注点。在这个背景下,将核心的生产过程及数据从公有云转移到行业私有云,已成为刻不容缓的时代需求。Zadig 作为提供标准私有模式的 DevOps 平台可以直接对接自建云、私有云,通过云原生技术架构迭代业务的同时又能满足数据本地化安全管理的诉求。

06 - 原厂实施考虑因素:

  • 专业支持和最佳实践需求:如果企业注重由产品开发者提供的专业支持和最佳实践,以降低试错成本和减少建设周期,可优先考虑 Zadig 作为原厂实施的选择。云效和 Coding 生态伙伴实施,提供的技术支持和最佳实践可能受制于生态伙伴的服务范围和能力。

 

后续将推出云效、Coding 等平台与 Zadig 之间详细对比文章,提供更全面的选型分析。敬请期待!

 

参考链接:

[1] Zadig 官方资料:https://docs.koderover.com

[2] 云效官方资料:https://help.aliyun.com/document_detail/153739.html

[3] Coding 官方资料:https://coding.net/help/docs/start/new.html

[4] Jenkins 官方资料:https://www.jenkins.io/doc

[5] GitLab 官方资料:https://docs.gitlab.com/ee

[6] Argo 官方资料:https://argoproj.github.io

[7] Tekton 官方资料:https://tekton.dev/docs

 

 

立即体验 Zadig V2.0 新架构,开启高效交付之旅! 

Zadig,让工程师更加专注创造

阅读原文 / Zadig 在 Github / Zadig 在 Gitee

推荐阅读 : Zadig v2.1.0 版本发布:工作流与环境全面协同升级! / Zadig vs. Jenkins 详细比对:时代的选择与开发者之选 / 探索 Zadig 自测模式,一套环境多人协同,释开发者创造力! / 阿里云 MSE + Zadig,面向开发者的全链路灰度发布解决方案 / ZADIG 专家版倾情上线:一键高效发布,119 元 / 人月起,社区老友享年终福利!

 

今天的关于Tekton 与 Argo CD 结合实现 GitOpstekton trigger的分享已经结束,谢谢您的关注,如果想了解更多关于Argo CD使用指南:如何构建一套完整的GitOps?、ArgoCD + KubeVela:以开发者为中心的 GitOps、ArgoCD + KubeVela:以开发者为中心的GitOps、DevOps 选型指南:Zadig / 云效 / Coding/Jenkins/GitLab/Argo/Tekton的相关知识,请在本站进行查询。

本文标签:

上一篇Kubernetes 实践:勿让 Docker Volume 引发 Terminating Pod(docker operation not permitted)

下一篇如何丝滑般将 Kubernetes 容器运行时从 Docker 切换成 Containerd(从docker到kubernetes进阶)