实践

达到 github action 同一个 PR 只跑一个 CI 的效果

需要考虑的点: 一个PR使用同一个 volume,暂时每次都清理, 后续优化是延迟一些时间再清理 volume

serverless 节点

为了成本考虑,需要使用的时候才去创建一个 K8S 节点,然后才创建对应的 argo workflow job.

限制一个 node 可以跑的 CI / workflowRun 数量

设置workflow的超时时间

我有一个定时 argo workflow,主要做的事情就是运行 renovate 来自动化更新项目的依赖项,例如 maven 依赖和容器镜像版本,有天我一看,这个 job 居然已经运行了 35 天,一直卡在 clone github 代码,默认情况似乎没有超时时间,导致这个定时任务 35 天内都没有再次正常.因此还是很有必要设置一个超时时间的.

apiVersion: argoproj.io/v1alpha1
kind: CronWorkflow
metadata:
  name: compile
  namespace: lank8scn
spec:
  activeDeadlineSeconds: 3600 # 1小时超时
...

workflow template 的 container 无法和 sidecar 共享一个 EmptyDir

本意是想通过 sidecar 的方式启动一个 docker 提供给 trivy 来做镜像扫描,trivy 需要使用 docker 的 unix socket,因此尝试挂载一个临时的共享 volume,每次用完之后就销毁,但argo workflow 似乎无法支持 (:

最后是通过将容器镜像导出为压缩包,然后使用 trivy image 的 --input 参数指定容器镜像压缩包文件来完成镜像的安全扫描.

docker save -o ecf-latest.tar my.lank8s.cn/ecf:latest 
trivy image --input ecf-latest.tar

如果我遗漏了什么,欢迎提醒我,随时与我交流 :)

对了,使用的 argo workflow 版本是 v3.5.5

...
    templates:
    - name: trivy
      volumes:
        - name: workspace
          emptyDir: { }
      container:
        image: ci-ubuntu-2204:latest
        imagePullPolicy: Always
        volumeMounts:
          - mountPath: /workspace
            name: workspace
      sidecars:
      #https://argo-workflows.readthedocs.io/en/stable/walk-through/docker-in-docker-using-sidecars/
      - name: dind
        volumeMounts:
          - mountPath: /workspace
            name: workspace

workflow 的重试配置

CI 过程中难免会遇到一些不稳定因素导致 CI 失败,并且希望这类事件发生时对当前 workflow 进行一次重试,argo workflow 原生支持这个需求.

...
spec:
  workflowSpec:
    entrypoint: cacherebuild
    templates:
    - name: cacherebuild
    # https://argo-workflows.readthedocs.io/en/stable/retries/#configuring-retrystrategy-in-workflowspec
      retryStrategy:
        limit: "2"
        retryPolicy: "Always"
...

可以设置根据一些条件来判断是否需要重试,上述配置比较简单,直接设置不论什么原因只要失败了就会重试两次.

workflow 执行完成后总是失败,显示 is forbidden: User “system:serviceaccount:lank8s:default” cannot patch resource “pods” in API group “” in the namespace “lank8s”

这是因为没有为 workflow 配置 RBAC 的时候使用的是当前 namespace 下的 default 这个 serviceAccount,而这个 serviceAccount 没有对应的权限.

官方有文档生命需要对应的权限: #https://github.com/argoproj/argo-workflows/blob/main/docs/workflow-rbac.md

解决方案是添加对应有权限的 serviceAccount 就可以了:

...
spec:
  workflowSpec:
    serviceAccountName: executor
...

对应的 Role 是:

#https://github.com/argoproj/argo-workflows/blob/main/docs/workflow-rbac.md
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: executor
  namespace: smartoilets
rules:
  - apiGroups:
      - argoproj.io
    resources:
      - workflowtaskresults
    verbs:
      - create
      - patch

官方 issue: https://github.com/argoproj/argo-workflows/issues/12783

做了一些公共的 workflow template,欢迎使用以及参与贡献.

微信公众号

扫描下面的二维码关注我们的微信公众号,第一时间查看最新内容。同时也可以关注我的Github,看看我都在了解什么技术,在页面底部可以找到我的Github。

[长期更新]argoworkflow 的一些实践和思考

TOC

实践