Applatix的Argo是一个开源项目，为Kubernetes提供了云原生工作流，将工作流中的每个步骤实现为容器。 Argo使用户能够使用类似于传统YAML的自定义DSL启动多步管道。该框架提供了复杂的循环，条件，与DAG的依赖关系管理等，这有助于提高部署应用程序堆栈时的灵活性以及配置和依赖关系的灵活性。使用Argo，用户可以定义依赖项，以编程方式构造复杂的工作流程，用于将任何步骤的输出链接为后续步骤的输入的工件管理，并在易于阅读的UI中监视计划的作业。

Argo V2被实现为Kubernetes CRD（自定义资源）。因此，可以使用kubectl管理Argo工作流程，并与其他Kubernetes服务（例如卷，Secret和RBAC）原生集成。新的Argo软件轻巧，可在一分钟内安装，但提供完整的工作流程功能，包括参数替换，工件，混合，循环和递归工作流程。

Argo中的工作流程自动化由YAML模板（易于采用，因为Kubernetes主要使用相同的DSL）驱动，使用ADSL（Argo域特定语言）设计的。使用ADSL提供的每条指令都被视为一段代码，并与应用程序代码一起托管在SCM（源代码管理）中。 Argo提供/支持6种不同的YAML构造：

• 容器模板：根据需要创建单个容器和参数
• 工作流程模板：定义作业，即short-running-app，工作流中的一个步骤可以是容器
• 策略模板：用于触发/调用作业或通知的规则
• 部署模板：创建长期运行的应用程序
• 装置模板：在Argo之外粘贴第三方资源
• 项目模板：工作流定义可在Argo目录中访问

Argo支持几种不同的方式来定义Kubernetes清单：Ksonnet应用程序，Helm图表和YAML / json清单的简单目录。

Argo 工作流模板

下面的模板是一个简单的模板，其中定义了工作流以创建具有两个容器的Pod，其中一个容器装有curl（仅带有curl的基于alpine的镜像），另一个是Nginx Sidecar容器（Sidecar作为第二进程与服务一起运行）并提供“平台基础架构功能”。在这里curl是一个“主”容器，它轮询nginxSidecar容器，直到准备好处理请求为止。

以上工作流程中的事件：

如上所示，工作流创建了一个容器并执行规范中定义的配置，并杀死容器状态标记为已完成的容器。

Argo仪表板视图:

有条件的工作流程模板

Argo支持工作流程执行中的条件模式。 argo提供的Coinflip示例描述了如何在模板中使用“when”，其中执行取决于从父级收到的输出。

上方的工作流程会运行一个随机整数脚本，其常量为0 =正面和1 =尾数，其中特定模板（正面或反面）的调用取决于“翻转硬币”任务的输出，如上面的工作流图中所示，投币任务产生的heads只执行heads模板。

上面的工作流创建了两个容器，一个用于执行randomint python脚本，另一个用于根据脚本的结果执行heads模板。如下所示，根据来自randomint脚本的结果（result == heads）执行heads模板。

类似地，可以将递归（递归调用模板）添加到条件规范中。例如，下面的模板输出显示翻转硬币模板被执行了n次，直到结果为正面。

迭代和参数化的工作流引擎模板

Argo有助于迭代工作流模板中的一组输入，并且用户可以提供参数（例如：输入参数）。在以下工作流程中，使用两个输入参数“ hello kubernetes”和“ hello argo”执行Whalesay模板。

上面的模板包含一个模板，该模板将使用项目列表并根据提供的参数值的数量运行任务。因此，这将创建两个Pod，一个执行工作流消费参数“ hello kubernetes”，另一个使用“ hello argo”，如下所示:

同样复杂的循环：支持迭代一组项目，动态生成项目列表。

具有由DAG（有向无环图）和步骤定义的依赖关系的多步骤工作流模板

Argo允许用户使用简单的Python对象DAG（有向无环图）启动多步管道，还可以方便地在工作流程规范（嵌套工作流程）中定义多个模板:

类似地，步骤可用于定义多步骤工作流，以下示例包括两个模板hello-hello-hello和whalesay（嵌套工作流）。

使用步骤的多步骤工作流程:

在此，根据步骤控制流程，并根据破折号定义运行格式。

Minio的工件管理和Argo的集成

工件是任何工作流程（例如CI-CD）的组成部分，工作流程中的步骤会生成工件，然后其他后续步骤将消耗这些工件。

这里使用的工件存储库是Minio：具有Amazon S3兼容API的开源对象存储服务器。

上面的工作流程包括两个步骤：1.生成工件：使用whalesay模板生成工件；以及2.消费工件：使用在步骤1中创建的工件并打印消息。根据配置中的定义，两个任务都按顺序运行。第一步中生成的工件存储在Minio中，可以通过在工作流配置映射中提供以下配置，将工件存储库与Argo集成。

上面创建的工件存储在My-bucket的Minio中。消费工件任务将根据提供的配置拉出工件。 Minio类似于S3，并提供了一个共享链接来使用工件，如下所示。

使用Argo部署具有长期运行的应用程序（部署和服务）的完整应用程序栈（应用程序，数据库，监视，日志和跟踪）

如上所示，Argo支持各种可用于部署简化的工作流的结构，以使用定义明确的规则集创建复杂的应用程序堆栈。在下面的示例中，部署了完整的Web应用程序（示例袜子商店应用程序），并带有日志记录（使用Elastic Search，Kibana和FluentD），监视（Prometheus和Grafana），跟踪（Zipkin）。

Argo可以使用传统的基于YAML的文件使用各种Kubernetes配置（部署，服务，群集角色等）。在此示例中，工作流程目录包含所有基于Argo的工作流程配置，这些配置使用Kubernetes-spec目录中的Kubernetes对象配置。

• Kubernetes Spec目录内容：

如下所示，应用程序栈配置分为日志，监视，数据库（shock-shop-db），应用程序（sock-shop）和zipkin（跟踪），它们是单独的子目录，分别构成特定于服务的部署，服务，configmap，集群-roles等（基本上是部署应用程序所需的所有Kubernetes配置）。例如，Zipkin包含：Mysql部署，Mysql服务，Zipkin部署，Zipkin服务。

kubernetes-spec
├── logging
│   ├── elasticsearch.yml
│   ├── fluentd-crb.yml
│   ├── fluentd-daemon.yml
│   ├── fluentd-sa.yaml
│   └── kibana.yml
├── logging-cr
│   └── fluentd-cr.yml
├── monitoring
│   ├── grafana-dep.yaml
│   ├── grafana-svc.yaml
│   ├── prometheus-alertrules.yaml
│   ├── prometheus-configmap.yaml
│   ├── prometheus-crb.yml
│   ├── prometheus-dep.yaml
│   ├── prometheus-exporter-disk-usage-ds.yaml
│   ├── prometheus-exporter-kube-state-dep.yaml
│   ├── prometheus-exporter-kube-state-svc.yaml
│   ├── prometheus-sa.yml
│   └── prometheus-svc.yaml
├── monitoring-cfg
│   ├── grafana-configmap.yaml
│   └── grafana-import-dash-batch.yaml
├── monitoring-cr
│   └── prometheus-cr.yml
├── sock-shop-db
│   ├── carts-db-dep.yaml
│   ├── carts-db-svc.yaml
│   ├── catalogue-db-dep.yaml
│   ├── catalogue-db-svc.yaml
│   ├── orders-db-dep.yaml
│   ├── orders-db-svc.yaml
│   ├── session-db-dep.yaml
│   ├── session-db-svc.yaml
│   ├── user-db-dep.yaml
│   └── user-db-svc.yaml
├── sock-shop-persist-db
│   ├── carts-db-ss.yaml
│   ├── carts-db-svc.yaml
│   ├── catalogue-db-dep.yaml
│   ├── catalogue-db-svc.yaml
│   ├── orders-db-ss.yaml
│   ├── orders-db-svc.yaml
│   ├── session-db-dep.yaml
│   ├── session-db-svc.yaml
│   ├── user-db-ss.yaml
│   └── user-db-svc.yaml
├── sock-shop-usvc
│   ├── carts-dep.yaml
│   ├── carts-svc.yml
│   ├── front-end-dep.yaml
│   ├── front-end-svc.yaml
│   ├── orders-dep.yaml
│   ├── orders-svc.yaml
│   ├── queue-master-dep.yaml
│   ├── queue-master-svc.yaml
│   ├── rabbitmq-dep.yaml
│   ├── rabbitmq-svc.yaml
│   ├── shipping-dep.yaml
│   └── shipping-svc.yaml
├── sock-shop-zipkin-usvc
│   ├── catalogue-dep.yaml
│   ├── catalogue-svc.yaml
│   ├── payment-dep.yaml
│   ├── payment-svc.yaml
│   ├── user-dep.yaml
│   └── user-svc.yaml
└── zipkin
    ├── zipkin-cron-dep.yml
    ├── zipkin-dep.yaml
    ├── zipkin-mysql-dep.yaml
    ├── zipkin-mysql-svc.yaml
    └── zipkin-svc.yaml
10 directories, 63 files

• 工作流目录内容：

工作流程目录包含所有基于Argo的工作流程配置，这些配置使用上面的Kubernetes规范文件。

workflows/
├── logging-workflow.yaml
├── monitoring-workflow.yaml
├── sock-shop-persist-workflow.yaml
└── sock-shop-workflow.yaml
0 directories, 4 files

查看上面的日志记录工作流示例：

同样，所有特定的工作流程都使用特定的Kubernetes资源来无缝部署应用程序，如下面的工作流程所示。

• 日志

如上所示，日志记录工作流创建ElasticSearch：部署和服务，Kibana：部署和服务，Fluentd：服务帐户，守护程序。

• 监控

如上所示，监视工作流为正在运行的Prometheus和Grafana堆栈创建所需的资源。

• Sock-Shop

如上所示，此工作流构成了多应用程序/模板工作流，其中Zipkin与具有依赖要求的袜子商店一起部署。

有了这个完整的应用程序，就可以在线进行日志记录，监视和跟踪。将根据提供的配置创建所有必需的服务。

通过将工作流引擎的丰富功能集与原生工件管理，准入控制，“fixtures”，对DinD（Docker-in-Docker）的内置支持和策略相结合，Argo在诸如传统CI之类的场景中具有极其重要的意义。 CD管道，具有顺序和并行步骤以及相关性的复杂作业，根据策略体系结构协调分布式应用程序的部署并触发基于时间/事件的工作流。

PS: 本文属于翻译，原文