argo | 伪架构师

在 Argo workflow 中使用 OBS 进行制品传递

Tue, 11 Feb 2025 21:56:17 +0800

在所有的通用工作流中，都会有文件传递的需求，Argo workflow 中，可以通过对接外部存储来支持这一需求。下面就以华为云为例，展示一下对接对象存储的过程。

OBS 侧配置

首先在 OBS 服务中创建一个存储桶，并在控制台的用户->我的凭证->访问密钥模块中，创建一个访问密钥，并下载凭据文件，凭据文件格式大致如下所示：

User Name,Access Key Id,Secret Access Key
"myusername",Y9C3WCABCDEFG,6bHX5eHIJKLMN

Argo workflow 配置

使用文件中的 Access Key 和 Secret Access Key ，在Workflow 所在的 Namespace 中创建 Kubernetes Secret。例如：

$ kubectl create secret generic s3-secret \
    --from-literal accessKey=Y9C3WCABCDEFG \
    --from-literal secretKey=6bHX5eHIJKLMN
...

接下来需要修改 Argo workflow 的配置文件，加入对制品的支持内容：

  artifactRepository: |
    archiveLogs: true
    s3:
      endpoint: obs.[Region ID].myhuaweicloud.com
      bucket: [Bucket Name]
      region: cn-north-4
      insecure: false
      keyFormat: "my-artifacts\
        /{{workflow.creationTimestamp.Y}}\
        /{{workflow.creationTimestamp.m}}\
        /{{workflow.creationTimestamp.d}}\
        /{{workflow.name}}\
        /{{pod.name}}"

      accessKeySecret:
        name: s3-secret
        key: accessKey
      secretKeySecret:
        name: s3-secret
        key: secretKey
      useSDKCreds: false

上面的配置大致解释一下：

在 OBS 中存储 Pod 日志
使用了华为云北京四 Region 的 OBS 端点。
需要引用前面创建的存储桶名称
使用加密方式进行访问
制品的存储路径模板为：my-artifacts/实例创建时间（年/月/日）/实例名称/步骤所在 Pod 名称/
Access Key 引用 Kubernetes Secret 中名为 s3-secret 的 accessKey 字段
Secret Key 引用 Kubernetes Secret 中名为 s3-secret 的 secretKey 字段

将上述内容加入 Argo workflow 所在命名空间的 workflow-controller-configmap。

启动工作流

尝试启动一个使用制品能力的工作流，清单内容来自https://argo-workflows.readthedocs.io/en/latest/walk-through/artifacts/。

这个流程模板中定义了两个工步：

生成制品

...
outputs:
  artifacts:
  # generate hello-art artifact from /tmp/hello_world.txt
  # artifacts can be directories as well as files
  - name: hello-art
    path: /tmp/hello_world.txt

上述代码中，将 /tmp/hello_world.txt 内容作为制品，并命名为 hello-art。

读取制品

inputs:
  artifacts:
  # unpack the message input artifact
  # and put it at /tmp/message
  - name: message
    path: /tmp/message

这段代码则是获取输入中名为 message 的制品，并解压到 /tmp/message 路径下。

执行时候，用 {{steps.generate-artifact.outputs.artifacts.hello-art}} 方式引用生成的制品。

执行

使用 Argo CLI 启动流程后，会看到类似如下的输出：

Name:                artifact-passing-mkn57
Namespace:           default
ServiceAccount:      argo-executor
Status:              Succeeded
...
STEP                       TEMPLATE                 PODNAME                                                    DURATION  MESSAGE
 ✔ artifact-passing-mkn57  artifact-example
 ├───✔ generate-artifact   hello-world-to-file      artifact-passing-mkn57-hello-world-to-file-551171166       8s
 └───✔ consume-artifact    print-message-from-file  artifact-passing-mkn57-print-message-from-file-1735545326  8s

这时如果返回 OBS 面板，会看到存储桶中，按照前面的路径规则存储了文件以及相关的日志（*.log）。

其他制品相关功能

覆盖仓库配置

前面我们在 Workflow Controller 配置文件中的配置，适用于单租户场景；多租户场景下，还可以通过 artifactRepositoryRef 方式，让每个流程可以使用自己的制品配置（https://argo-workflows.readthedocs.io/en/latest/artifact-repository-ref/）。

首先使用 Configmap 定义多个存储对接的参数，例如：

apiVersion: v1
kind: ConfigMap
metadata:
  # If you want to use this config map by default, name it "artifact-repositories". Otherwise, you can provide a reference to a
  # different config map in `artifactRepositoryRef.configMap`.
  name: my-artifact-repository
  annotations:
    # v3.0 and after - if you want to use a specific key, put that key into this annotation.
    workflows.argoproj.io/default-artifact-repository: default-v1-s3-artifact-repository
data:
  default-v1-s3-artifact-repository: |
    s3:
...
  v2-s3-artifact-repository: |
...

这段 YAML 中，提供了几个信息：

如果想要默认使用这个 Configmap 定义制品仓库，可以将其名称设置为 artifact-repositories。
如果不是默认，就需要在 artifactRepositoryRef.configMap 中显示定义 Configmap 名称。
v3.0 以后，可以用 workflows.argoproj.io/default-artifact-repository 注解定义这个 Configmap 中的默认仓库定义
data 字段定义了两个制品仓库。

然后可以在 Workflow 中引用：

spec:
  artifactRepositoryRef:
    configMap: my-artifact-repository
    key: v2-s3-artifact-repository

垃圾回收

在 Workflow 的 spec.artifactGC 中，可以定义 Garbage Collection 的策略。可选策略包括 OnWorkflowCompletion 和 OnWorkflowDeletion。

存储驱动能力列表

除了 S3 之外，目前 Argo Workflow 支持的存储驱动能力如下：

(https://argo-workflows.readthedocs.io/en/latest/configure-artifact-repository/)

Name	Inputs	Outputs	Garbage Collection	Usage (Feb 2020)
Artifactory	Yes	Yes	No	11%
Azure Blob	Yes	Yes	Yes	-
GCS	Yes	Yes	Yes	-
Git	Yes	No	No	-
HDFS	Yes	Yes	No	3%
HTTP	Yes	Yes	No	2%
OSS	Yes	Yes	No	-
Raw	Yes	No	No	5%
S3	Yes	Yes	Yes	86%

在 Argo workflow 中使用插件减少并行 Pod 数量

Fri, 29 Nov 2024 21:41:22 +0800

在之前写过的使用 Argo workflow 调用公有云客户端软件实现运维过程的文章中，可以看到，使用 Argo workflow 的容器模板，简单的将既有运维能力容器化，就能使用 Argo workflow 对这些能力进行编排了。

不过近期一个测试中，遇到个小麻烦——在一个 With 循环里，我输入了 500 个任务，结果是 6 节点 CCE 集群爆满，流程卡住——集群规模的事情很简单，我直接将 Argo workflow 部署到 CCE Autopilot 集群中，随着流程启动，Auto pilot 集群非常给力，不到一分钟就扩容到了上百节点。然而新的问题出现了，Argo workflow 容器模板使用的镜像托管在 quay.io 上，我被限流了——无法拉取镜像，工作流自然也就无法执行了。

如果说必须要限流的话，Argo workflow 提供了多种机制，在不同粒度上对工作流的并发进行控制：

在模板中，使用 parallelism 参数，限制流程实例内的并发数。
在 Workflow Controller 的 Configmap（workflow-controller-configmap）中，使用 parallelism 或者 namespaceParallelism，在集群范围内，限制总体并发的流程数量。
模板中使用 synchronization，使用同样的共享锁的流程实例将会被有效限流。

不难看出，在有限集群的规模下，通过对并发的控制，以及垃圾回收策略的定义，都能有效的限制集群规模——毕竟上百节点是要花不少银子的。在这种情况下，还有一条路就是，使用执行插件。例如如下工作流：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: python-example-
spec:
  entrypoint: main
  arguments:
    parameters:
      - name: value
        value: "1"  
  templates:
    - name: main
      steps:
      - - name: evaluate
          template: evaluate
          arguments:
            parameters:
              - name: value
                value: "{{workflow.parameters.value}}"
          withSequence:
            count: "50"         
    - name: evaluate
      inputs:
        parameters:
          - name: value    
      plugin:
        python:
          expression: |
            {"sum": int(parameters["value"]) + 1}

这里使用 plugin.python 的方式引用了一个插件，执行时，循环了 50 次，提交后，我们会发现，这里只执行了一个 Pod：python-example-hlc5t-1340600742-agent，也就是说，这一个 Pod 承载了所有的 50 个任务。如何实现的呢？这里就要看看 Argo workflow 的插件机制了。

Argo workflow 默认是不启用插件的，要启用插件，需要给控制器加入环境变量：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: workflow-controller
spec:
  template:
    spec:
      containers:
        - name: workflow-controller
          env:
            - name: ARGO_EXECUTOR_PLUGINS
              value: "true"

重启后，就可以启用上面工作流引用的插件了，启用插件的方式很有意思，提交一个 Configmap 即可：

# This is an auto-generated file. DO NOT EDIT
apiVersion: v1
data:
  sidecar.container: |
    args:
....
kind: ConfigMap
metadata:
...
    workflows.argoproj.io/version: '>= v3.3'
  creationTimestamp: null
  labels:
    workflows.argoproj.io/configmap-type: ExecutorPlugin
  name: python-executor-plugin

这方式有点奇怪，Configmap 里面包含了一堆 Python 代码。以及似乎是 Sidecar 的容器定义。应用之后，就能够运行上述工作流了。

注意 Configmap 中的注释说明：这是一个自动生成的文件，哪里来的呢？

实际上，Argo workflow 插件是由 argo executor-plugin build 命令构建出来的，一个插件的原始文件主要包含三个部分：

插件清单（plugin.yaml）：这里实际上是对一个容器的定义，其中包含了容器镜像、资源使用等。
启动文件：一个命名为 server.* 的文本文件，可以是 Shell 或者 Python 脚本，他会在插件启动时被执行。
插件镜像：上述文本文件可能无法描述一些业务逻辑，因此，可以将二进制文件封装到镜像里，给启动文件调用。

例如前边用到的 Python 插件的 plugin.yaml：

kind: ExecutorPlugin
apiVersion: argoproj.io/v1alpha1
metadata:
  name: python
...
    workflows.argoproj.io/version: '>= v3.3'
spec:
  sidecar:
    container:
      command:
        - python
        - -c
      image: python:alpine
      name: python-executor-plugin
...

不难看出，这个定义和上边的 Configmap 是一致的。再看看 server.py：

import json
from http.server import BaseHTTPRequestHandler, HTTPServer


class Plugin(BaseHTTPRequestHandler):

    def args(self):
        return json.loads(self.rfile.read(int(self.headers.get('Content-Length'))))

    def reply(self, reply):
        self.send_response(200)
        self.end_headers()
        self.wfile.write(json.dumps(reply).encode("UTF-8"))

    def unsupported(self):
        self.send_response(404)
        self.end_headers()

    def do_POST(self):
        if self.path == '/api/v1/template.execute':
            args = self.args()

            template = args['template']
            plugin = template.get('plugin', {})

            if 'python' in plugin:
                spec = plugin['python']

                # convert parameters into easy to use dict
                # artifacts are not supported
                parameters = {}
                for parameter in template.get('inputs', {}).get('parameters', []):
                    parameters[parameter['name']] = parameter['value']

                try:
                    code = compile(spec['expression'], "<string>", "eval")
...


if __name__ == '__main__':
    httpd = HTTPServer(('', 7984), Plugin)
    httpd.serve_forever()

上边的代码，不难看出，这里只是启动了一个简单的 Python HTTP Server，监听 /api/v1/template.execute 的 Post 请求，并对其进行处理。

上述的 YAML 和启动代码都编写完成之后，就可以使用 argo executor-plugin build 命令来构建 Configmap 了。

当然也可以使用自己定义的基础镜像。

Argo + KooCli 操作华为云资源

Tue, 15 Oct 2024 01:39:10 +0800

前面写过一篇使用 Argo Workflow 操作 AWS 资源的例子，今天要写的是类似的，在 Argo Workflow 中，使用 CLI 客户端操作华为云资源的办法。

华为云提供的 KooCLI 是一个命令行工具，其中提供了很多华为云的操作能力。要在 Argo Workflow 中使用 KooCLI，首先需要构建 KooCLI 的容器镜像，Dockerfile 如下：

FROM ubuntu:24.04
RUN apt-get update -y && apt-get install curl -y
RUN curl -sSL https://cn-north-4-hdn-koocli.obs.cn-north-4.myhuaweicloud.com/cli/latest/hcloud_install.sh -o ./hcloud_install.sh \
  && bash ./hcloud_install.sh -y \
  && yes | hcloud --help

WORKDIR hcloud

整个过程和官网的说明是类似的，这里我加了一行初始化操作：yes | hcloud --help，这是因为启动 hcloud 的时候，首先会弹出一个 License 界面，需要输入 yes 才继续。所以这里使用 yes 命令进行一个初始化。

容器镜像构造结束之后，就可以在 Argo Workflow 中使用 KooCLI 了。

这次测试使用的是 Argo Workflow 的 v3.5.11 版本。

简单粗暴上代码，在 https://gist.github.com/fleeto/7c70b58a6ee7bdb93494f94f77db7c20

上述代码有几个要点：

入参

在 spec.arguments.parameters 中，定义了 ak、sk 以及 region 三个参数，用于配置华为云的 AK、SK 以及区域。

  arguments:
    parameters:
    - name: ak
      value: "AKAKAK"
    - name: sk
      value: "SKSKSSK"
    - name: region
      value: "cn-north-4"

执行 KooCLI

在 list-ecs 步骤中，使用了前面构建的 KooCLI 镜像，用无配置方式，通过 hcloud ECS ListCloudServers 命令，获取到当前区域下的所有云服务器：

- name: list-ecs
  container:
    image: dustise/koocli:v0.0.2
    command:
    - hcloud
    args:
    - ECS
    - ListCloudServers
    - --cli-region={{workflow.parameters.region}}
    - --cli-access-key={{workflow.parameters.ak}}
    - --cli-secret-key={{workflow.parameters.sk}}

这一步骤中，我没有定义输出参数，这是因为在 Argo Workflow 中，可以使用 steps.[步骤名称].outputs.result 的方式，默认导出 STDOUT 内容，但是需要注意的是，这种方式最大支持 256kb 的内容。

还有一种方式就是把内容输出给文本文件，然后用如下形式声明：

outputs:
  parameters:
  - name: hello-param
    valueFrom:
      path: /tmp/hello_world.txt

KooCLI 输出的 JSON 中，可以使用 --cli-query 开关，使用 JMESPath 方式对结果进行整理，原始的输出格式大致如下：

{
  "servers": [
    {},]}

要想只输出 servers 数组，可以加入 --cli-query=servers 开关，就能输出只包含 servers 数组的内容了。

引用输出结果进行循环

这里使用了 withParam 语法，对 list-ecs 步骤的输出结果进行循环，每次循环，都会把当前循环的元素赋值给 item 变量，输出 item 变量的 id 属性。

循环变量里，我们使用了一个奇怪的表达式："{{=toJSON(jsonpath(steps.list.outputs.result, '$.servers'))}}"：

{{= 代表使用表达式进行运算。
使用 jsonpath 获得数组
toJSON 把对象编码为 JSON

注意，不同的 Argo workflow 版本，这一点不太一样，目前看到的官网讨论是：

3.4: {{=toJson(jsonpath(...))}}
3.5: {{=toJSON(jsonpath(...))}}
3.6: {{=jsonpath(...)}}

运行

argo submit 或者 kubectl create 执行之后，可以看到，KooCLI 用了一个容器进行查询，随后在循环中，每个示例都有一个对应的 Pod 执行 ECHO 任务。

用 Kyverno 让 Argo Workflow 单步执行

Thu, 18 Jul 2024 22:59:35 +0800

AWS 的 SSM Automation 中，有个有趣的特性就是单步执行，在编写自动化脚本的时候，这个功能对调试非常有帮助。Argo Workflow 也有个暂停特性，官网给出的例子是这样的：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: pause-after-
spec:
  entrypoint: whalesay
  templates:
    - name: whalesay
      container:
        image: argoproj/argosay:v2
        env:
          - name: ARGO_DEBUG_PAUSE_AFTER
            value: 'true'

把他提交到 Argo 会看到暂停的情况：

$ argo submit --watch debug.yml
Name:                pause-after-hpvg9                                                                                                                                          [0/1455]
Namespace:           default
ServiceAccount:      unset (will run with the default ServiceAccount)
Status:              Running
Conditions:
 PodRunning          True
Created:             Thu Jul 18 23:18:46 +0800 (18 seconds ago)
Started:             Thu Jul 18 23:18:46 +0800 (18 seconds ago)
Duration:            18 seconds
Progress:            0/1

STEP                  TEMPLATE  PODNAME            DURATION  MESSAGE
 ● pause-after-hpvg9  whalesay  pause-after-hpvg9  18s

你会发现，这个 Workflow 会一直冻结在这个状态，

$ argo list
NAME                STATUS      AGE   DURATION   PRIORITY   MESSAGE
pause-after-hpvg9   Running     11m   11m        0
...

这时候只要进入 Pod，执行一个命令，工作流就会完成：

$ kubectl exec -it pause-after-hpvg9 -- bash
root@pause-after-hpvg9:/# touch /proc/1/root/var/run/argo/ctr/main/after
root@pause-after-hpvg9:/# command terminated with exit code 137

可以看到 Argo 的 Watch 也发生了变化：

STEP                  TEMPLATE  PODNAME            DURATION  MESSAGE
 ✔ pause-after-hpvg9  whalesay  pause-after-hpvg9  21m

问题来了，正常的工作流不会只有一个步骤，要实现单步执行的效果，就需要给每个步骤加入环境变量，是不是有点麻烦？我想到一个办法——用 Kyverno 做个自动补丁。只要 Workflow 加上一个 debug 标签，就给所有步骤加入暂停标志。

废话不多说，上策略代码：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-argo-debug-env
spec:
  rules:
    - name: add-debug-env-var
      match:
        resources:
          kinds:
            - argoproj.io/v1alpha1/Workflow
          selector:
            matchLabels:
              debug: "true"
          operations:
          - CREATE
      mutate:
        foreach:
          - list: request.object.spec.templates[]
            patchesJson6902: |-
              - path: /spec/templates/{{elementIndex}}/container/env/-
                op: add
                value:
                  name: ARGO_DEBUG_PAUSE_AFTER
                  value: "true"

这段策略有几个要点：

selector 指定，只处理带有 Debug 标签，并且操作为 CREATE 的
使用 foreach 语法，处理工作流中出现的每一个步骤
用 patchesJson6902 方式，给每个步骤的容器加入 ARGO_DEBUG_PAUSE_AFTER 环境变量。

提交策略之后，用如下任务脚本测试一下：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: debug314159-
  labels:
    debug: "true"
spec:
  entrypoint: whalesay
  templates:
    - name: whalesay
      container:
        image: argoproj/argosay:v2
    - name: whalesayagain
      container:
        image: argoproj/argosay:v2

提交工作流：

$ argo submit debug.yml
Name:                debug314159-dvqmw
Namespace:           default
ServiceAccount:      unset (will run with the default ServiceAccount)
Status:              Pending
Created:             Fri Jul 19 00:11:15 +0800 (now)
Progress:

查看生成的工作流：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
...
  labels:
    debug: "true"
    workflows.argoproj.io/completed: "false"
    workflows.argoproj.io/phase: Running
  name: debug314159-dvqmw
  namespace: default
...
spec:
...
  - container:
      env:
      - name: ARGO_DEBUG_PAUSE_AFTER
        value: "true"
      image: argoproj/argosay:v2
...
  - container:
      env:
      - name: ARGO_DEBUG_PAUSE_AFTER
        value: "true"
      image: argoproj/argosay:v2
      name: ""
...

可以看到，Kyverno 给每个步骤都加入了环境变量，这样一来，就实现了单步执行的效果。

后记

这个办法还有个问题，就是恢复太麻烦了，我打算接下来用 Shell Operator 来解决。

不明白为什么 Argo Workflow 没有给这种步骤设置一个暂停状态。

使用 Argo Workflow 组织跨云运维的可能性

Thu, 02 May 2024 21:39:17 +0800

在微服务、容器化和 IaC 等概念普及之前，自动化通常是使用过程性操作进行的，例如摘流——升级——恢复的过程。为了运维方便，通常这些操作序列会由所谓的运维流程编排工具完成，例如 AWS 的 SSM Automation，或者阿里云的 OOS 等。随着运维自动化的要求逐步提高，这些工具的编排能力也逐步扩展，出现了插件扩展、循环、跳转等更复杂的行为，甚至还出现了人工审批等蜜汁操作。自动化的编排复杂度也不断延伸——AWS 公开的作业脚本中已经出现了超过 3000 行 50 个步骤的庞然大物。

古时候的自动化运维通常是围绕着虚拟机进行的——管你是谁家的机器，只要你开了 SSH，或者装了我家的 Agent，你就跟我姓了。但是随着公有云服务能力的不断扩展，虚拟机的运维操作占比就逐步降低了，围绕 API 进行的运维能力逐步超过了虚拟机，成为主流。

不管有用没用，多云已经成为部分架构师的口头禅了。再加上前面的两个情况—— SRE 平台需要有一个能跨云的、面向 API 的、具备复杂编排能力并且能用编程方式进行扩展的自动化工具了，另外随着面对资源规模的不同，必要的并发能力和横向扩展的能力也是必要的。经过一番比对，我觉得 Argo Workflow 可能是个合适的选择。

Argo 大概于 2017 年以 GitOps 工具的形态，由 Intuit 发布，2020 年进入 CNCF 孵化，2022 年毕业，现在已经成长为包含 Argo CD、Argo Workflows、Argo Events 以及 Argo Rollouts 的生态群，并在 2022 年开始有了 Argo Con 峰会。

架构

根据官方提供的组件图可以看出：

Argo Workflows 运行在 Kubernetes 集群里。
可以利用 Kubernetes API 对 Argo 进行控制。
用户可以通过 CLI、Kubectl 和 Web UI 三种方式和 Argo 进行交互。
可以对接外部 idP，让 Argo Workflows 具备单点登录能力
Workflow 也是以 Pod 的形式在集群中运行的。

下图则是对工作流的一个描述。

这里不难发现，Argo Workflow 除了支持工作流之外，还支持了 DAG，它的工作流节点是用多容器 Pod 的形式运行的——每个 Pod 中包含 Wait、Init 和 Main 三个容器。

功能

Argo Workflow 提供了非常丰富的自动化编排能力。流程方面，提供了循环、条件、递归、暂停、恢复等常见内容；容错方面提供了超时、重试、异常捕捉/跳转等能力；另外他还支持脚本执行、变量定义和处理、工件传递等用于应对复杂场景的功能。功能方面，个人评估是略强于 AWS 的 SSM Automation 的。

起步

下文均用目前的 v3.5.6 为例

Argo Workflows 的快速部署方式非常简单，下面两行命令即可：

$ kubectl create namespace argo
namespace/argo created
$ kubectl apply -n argo -f https://github.com/argoproj/argo-workflows/releases/download/v3.5.6/install.yaml
...
priorityclass.scheduling.k8s.io/workflow-controller created
deployment.apps/argo-server created
deployment.apps/workflow-controller created

当然，这只是一个测试环境的玩法，项目也用 Helm Chart 的方式提供了用于生产环境的部署途径。

服务启动后，可以看到两个 Pod：

$ kubectl get po -n argo
NAME                                   READY   STATUS    RESTARTS   AGE
workflow-controller-5bb8788d57-sxnv2   1/1     Running   0          29s
argo-server-67bcf4bb48-sq9jp           1/1     Running   0          29s

为了简化使用可以进行一点修改：

$ kubectl patch deployment \
  argo-server \
  --namespace argo \
  --type='json' \
  -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/args", "value": [
  "server",
  "--auth-mode=server"
]}]'

默认的认证方式需要使用 Service Account，并且需要进行较多的 RBAC 配置，有些复杂，所以这里改成了服务侧自行认证。

然后把服务改成 NodePort：

$ kubectl patch svc argo-server -n argo -p '{"spec": {"type": "NodePort"}}'
service/argo-server patched

这样，就可以在获取端口后，直接浏览器直接访问 Argo UI 了（注意这里默认使用的是 https 协议）。

教程中提供了一个 Hello World 流程，内容如下：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: hello-world-
  labels:
    workflows.argoproj.io/archive-strategy: "false"
  annotations:
    workflows.argoproj.io/description: |
      This is a simple hello world example.
spec:
  entrypoint: whalesay
  templates:
  - name: whalesay
    container:
      image: docker/whalesay:latest
      command: [cowsay]
      args: ["hello world"]

这个简单的 YAML 可以看到 Argo 工作流定义中的基本元素：

这是一个 CRD，类型是 argoproj.io/v1alpha1 的 Workflow。
这一清单需要重复使用，因此 metadata 中没有给出 Name，而是给出了 generateName。
spec.templates 中保存的步骤的定义，并使用 spec.entrypoint 指定了入口环节。
仅有的一个步骤中，使用一个容器镜像，并指定了执行命令，输出一段文字。

使用 kubectl create 提交工作流，看看结果：

$ kubectl create -f install.yaml
workflow.argoproj.io/hello-world-fdddc created

用浏览器打开控制台，浏览 workflows 页面，可以看到，出错了：

错误原因也很 Kubernetes，就是 RBAC 权限不足：

Error (exit code 1): pods "hello-world-fdddc" is forbidden: User "system:serviceaccount:default:default" cannot patch resource "pods" in API group "" in the namespace "default"

看来这里用到的什么修改 Pod 的功能，看一下命名空间中的 hello-world，会看到它的内容和我们在模板中指定的简单几行完全不同，多出了 initContainer 和 Sidecar。主容器的命令也被加入了新的内容。

这里偷个懒，直接借用 Argo 明明空间里的 Argo SA，用法很简单，在 YAML 的 entrypoint 字段后加入同级元素 serviceAccountName: argo，并且在 Argo 命名空间里创建：

$ kubectl create -f hello-world.yaml -n argo
workflow.argoproj.io/hello-world-l4q2x created

浏览器控制台可以看到，这次成功运行，并且输出了结果：

用 argo CLI 也可以方便的查看：

$ argo list -A
NAMESPACE   NAME                STATUS      AGE   DURATION   PRIORITY   MESSAGE
argo        hello-world-l4q2x   Succeeded   7h    10s        0
default     hello-world-fdddc   Error       8h    10s        0          Error (exit c

场景

用户可以通过 Restful API、SDK、CLI 和 Web 控制台来访问 AWS 服务，自动化操作通常会使用 SDK 或者 CLI 的方式。这里我们设置一个场景：查询当前账户的 EC2 实例，并关机。

这里需要用到几个能力：

使用容器模板加载 AWS 凭据，并运行 AWS CLI 的能力
将 AWS CLI 结果输出为变量的能力
循环处理列表变量的能力

加载 Secret

假设我们的凭据文件保存在当前目录的 credentials 文件中，我们需要将它创建为 Secret，并在后续的容器模板中进行加载：kubectl create secret generic awskey --from-file=credentials。

工作流中想要加载 Secret，跟 Pod 是很相似的，例如我们将会这样编写列出 EC2 实例的环节：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: shutdown-ec2-
  labels:
    workflows.argoproj.io/archive-strategy: "false"
spec:
  serviceAccountName: argo
  entrypoint: list-instances
  volumes:
    - name: aws-secret
      secret:
        secretName: awskey
  templates:
    - name: list-instances
      container:
        image: amazon/aws-cli:2.15.43
        args:
          - "ec2"
          - "describe-instances"
          - "--output"
          - "json"
          - "--region" 
          - "ap-northeast-1"
          - "--query"
          - "Reservations[].Instances[].InstanceId"          
        volumeMounts:
          - name: aws-secret
            mountPath: /root/.aws

这个步骤写完之后，可以运行一下，看看结果：

$ argo submit -n argo --watch aws-list-ec2.yaml
...
STEP                   TEMPLATE        PODNAME             DURATION  MESSAGE
 ✔ shutdown-ec2-7ngl9  list-instances  shutdown-ec2-7ngl9  4s

查看日志会发现，成功返回了一个 JSON 数组，其中包含了我们需要的实例 ID 列表。

循环关闭

接下来把这个工作流改为多模板的模式，便于我们加入参数和循环能力。

实际上 AWS CLI 是直接支持用数组方式关闭多个 EC2 实例的

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: shutdown-ec2-
  labels:
    workflows.argoproj.io/archive-strategy: "false"
spec:
  serviceAccountName: argo
  entrypoint: shutdown-all-ec2
  volumes:
    - name: aws-secret
      secret:
        secretName: awskey
  templates:
    - name: shutdown-all-ec2
      steps:
        - - name: list
            template: list-instances
        - - name: shut
            template: shutdown-ec2
            arguments:
              parameters:
                - name: ec2id
                  value: "{{item.InstanceId}}"
            withParam: "{{steps.list.outputs.result}}"
    - name: list-instances
      container:
        image: amazon/aws-cli:2.15.43
        command: ["aws"]
        args:
          - --output
          - json
          - --region
          - ap-northeast-1
          - ec2
          - describe-instances
          - --query
          - "Reservations[].Instances[]"
        volumeMounts:
          - name: aws-secret
            mountPath: /root/.aws
    - name: shutdown-ec2
      inputs:
        parameters:
          - name: ec2id
      container:
        image: amazon/aws-cli:2.15.43
        command: ["aws"]
        args:
        - "ec2"
        - "stop-instances"
        - --region
        - ap-northeast-1        
        - "--instance-ids"
        - "{{inputs.parameters.ec2id}}"
        volumeMounts:
          - name: aws-secret
            mountPath: /root/.aws

上面的 YAML 的主要变化：

把原有的单步骤流程拓展成了多步骤
列表中加入了格式化内容，精简输出

将列表结果作为循环变量，传递给了用于关机的后续步骤

arguments:
parameters:
- name: ec2id
  value: "{{item}}"
withParam: "{{steps.list.outputs.result}}"

这一段将步骤 list 的控制台输出作为循环变量，传递给 shutdown-ec2 模板的 ec2id 参数，逐个关机。

注意这里的写法，使用 step 的方式对模板进行引用，形成多步骤流程。

运行后，可以看到 Argo 用并发的形式，进行了批量关机操作。

补充

首先是 AWS CLI 提供了丰富的功能，调用起来实在是比 SDK 方便太多，所以这里用这种形式来简化操作。

其次是这里对输出变量的做法，其实 Argo 提供了丰富的内置函数，可以对这些输出内容进行较为复杂的处理，当然，也可以用 Script 步骤进行更加细致的定制工作。

再次，过程中直接加载 AWS 凭据的方法非常不推荐，关于容器环境中的敏感信息管理，已经有很多陈述，这里就不节外生枝了。

最后，Argo 的文档真烂，真的烂。。