Argo Workflow 介绍:一款强大的云原生持续集成工具
Argo workflow 是什么
老牌的 CICD 工具 Jenkins 应该是大部分都接触过的,而在云原生时代,诞生了两大 CI/CD 框架,也就是 Argo Workflow 和 Tekton,本文主要介绍一下 Argo Workflow。
Argo Workflow 是一个云原生的工作流引擎,基于 kubernetes 来做编排任务,目前 Argo 项目是 CNCF 的毕业项目。
只有当需要执行对应的 step 时才会创建出对应的 pod,因此和 Tekton 一样,对资源的申请和释放具有很好的利用性。
基于 Argo Workflow 可以完成一些比较复杂的工作流,下面是一个来自某个 issue 的图:

架构概览

在 Argo Workflow 中,每一个 step/dag task 就是一个 pod 中的容器,最基础的 pod 会有 1 个 init 容器和两个工作容器,其中 init 容器和主容器都是 argoproj/argoexec 容器,另一个则是 step 中需要使用的容器,也就是实际执行内容的容器,在 pod 中充当 sidecar。
- main 容器,也就是 step/dag task 中定义的容器,用于执行实际内容。
- init 容器,用于为 main 容器处理 artifact 以及参数相关的逻辑。
- wait 容器,等待 main 容器执行完成,以及处理一些清理任务,例如上传 artifact 到 S3。
需要理清的一点是虽然 Argo Workflow 将工作容器定义为main容器
,但实际上wait容器
是 pod 中的主容器。
主要资源
在 Argo Workflow 中主要的 CRD 对象有几个:
- Workflow
- WorkflowTemplate
- CronWrokflow
接下来分别了解一下三个 CRD 对象。
Workflow
Workflow 定义的字段和 workflowTemplate 定义的字段基本上是一致的,因此将字段的解释放在 workflowTemplate 部分,对 Workflow 的理解只需要知道 Workflow 是一个流水线的"实例",也就是只有创建了 Workflow 对象是才会真正的运行流水线。
WorkflowTemplate
WorkflowTemplate 是最重要的对象了,基本上绝大部分时间你都是和它在打交道,其中还有一个 template 的定义,在刚认识 Argo workflow 时需要注意区分的一点是 workflowTemplate 和 template,这在我刚入门时也造成了一点困惑,接下来讲一下这两个的区别:
workflowTemplate 是 argo workflow 中实现的 CRD 对象,而 template 则是对象内的一个字段,实际执行内容都是在 template 中定义的,一个 workflowTemplate 至少要包含一个 template。workflowTemplate 需要将一个 template 配置为 entrypoint,也就是流水线的起点,在这个 template 的 steps 中又可以应用多个相同或不同的 template。
简单举一个例子来理解 workflowTemplate 多个 template,假设要封装一个 workflowTemplate 来处理 git 相关的场景:
分别为以下三个操作创建三个 template,假设需要在同一份代码中多次 merge && commit,那么流水线入口是 git clone,然后 git merge,git add && git commit,在这种情况下 template2 和 template3 是作为 template1 的一部分存在的。而当流水线入口直接就是 git merge 或 git add && git commit 的情况时,template2 或 template3 是作为单独的流水线逻辑存在。
- git clone
- git merge
- git add && git commit
因此 template 可以单独作为流水线入口执行,也可以被其他的 template 引用。
先列出几个关键词做一个简单的概述来更好的了解 Template:
- steps,流水线每一步的执行内容,
--
表示与同级别的 step 并行执行,-
表示与同级别的 step 顺序执行。 - container,真正执行内容的定义,与 kubernetes container spec 定义一致。
- script,这是一个基于 container 的类型,可以让用户直接在 CI 中直接执行一些脚本并且得到返回的结果,例如执行 python 代码,执行 node 代码以及执行 shell 等等。
- resource,这个类型可以支持在 CI 中对 Kubernetes 的对象进行操作,例如创建一个 configMap,然后根据这个 Kubernetes 资源对象的状态来判断该步骤是否成功。(这个功能太酷了!)
以上几个点是理解 template 最主要的内容,一个简单示意的 yaml 格式如下:
...
entrypoint: hello-hello-hello #配置 template 入口
templates:
- name: hello-hello-hello
steps:
- - name: hello1
template: whalesay
arguments:
parameters:
- name: message
value: "hello1"
- - name: hello2a
template: whalesay
arguments:
parameters:
- name: message
value: "hello2a" #hello2a 与 hello1 是顺序执行
- name: hello2b #hello2a 与 hello2b 是并行执行
template: whalesay
arguments:
parameters:
- name: message
value: "hello2b"