Argo工作流可替代Cloud Composer

背景

在以前的文章中（计划工作＃1，计划工作＃2），我一直在写关于如何使用GCP Cloud Composer（气流）进行工作流计划的信息。

Cloud Composer困扰我的是价格过高（最低380 $ /月！）。 对于小型集群和少量工作，美元和基础设施方面的支出并不能真正增加所提供的价值。

我们内部的Computas应用程序就是一个很好的例子。

它曾经作为cron-jobs在kubernetes集群中运行。 从某个时候开始，我们开始获得作业之间的依赖关系，因此cron不再是一种选择。

computas中的每个员工都安装了一个应用程序，可让您访问所有其他员工-图像，电话，邮件…此外，它还包含每个员工的个人信息，例如休假日，病假日和kks预算。

Computas每年还会举行几次内部会议，并进行多次平行会议。 使用我们创建的应用程序，每个员工都可以决定要去的曲目。 主数据在JIRA中。

该应用程序使用Firebase作为其后端。 为了用我们的Prem系统上的相关数据填充Firebase，我们有几个ETL工作。

> Conceptual diagram of the infrastructure involved

如果我们要启动一个Composer集群来处理此ETL，则成本将过高，因为其余基础结构的成本不足100美元/月。

Argo工作流程

> Argo workflows to the rescue!

有几种替代方法可以运行作曲家托管。 一个不错的选择是在VM上运行气流，但是鉴于这些作业已经是kubernetes cron作业，我们希望可以轻松地将它们安装到kubernetes集群中，而所需的开销最少，并按原样运行这些作业。

Argo工作流是kubernetes原生的，与气流相比，其占用空间相对较小。 它使用自定义资源来描述作业，并部署控制器来运行它们-所有本机kubernetes概念。 这意味着Argo不需要外部数据库来保存状态，因为状态保存在资源本身中。

它也有一个（简单的）UI，但是默认情况下它不公开给互联网。

这些工作流程可以按cron计划运行，也可以作为一次性工作运行。 对于我们的用例，cron计划最适合我们。 您可以配置如果作业已在运行该怎么办（禁止，杀死现有文件，跳过…）

工作流程以yaml定义。

Argo还拥有丰富的生态系统。 例如，它具有用于执行事件驱动的体系结构的插件（即，在使用pubsub消息后生成工作流等），在Composer中要做的事情有些麻烦。

部署工作流程

Argo工作流在定义工作流时有一个非常好的概念，这使得ci-cd流程在单仓库和微型仓库中都非常容易实现。 工作流程可以包含多个减肥模板，并且可以在docker映像（带有版本）旁边构建一个模板。 这意味着您的构建过程可以构建命名模板，并且工作流程将在可用时进行选择。 这意味着在您提交代码并完成构建过程之后，就可以运行工作流了。

将此与您必须在云Composer中进行的操作进行比较：

· 首先创建一个触发器，该触发器将repo文件夹同步到存储桶以进行提交。

· 然后在后台，每30秒将此桶同步到每个气流工作人员。

· 然后，您将不断刷新ui中的dag，直到看到DAG更改的内容

· 然后，您开始工作。

使用IAP创建入口

Argo工作流并没有开箱即用。 当然，您可以按需创建一个隧道来查看argo ui，但是每次想要概览时，这样做并不是最佳选择。 不用担心，很容易将argo-server暴露在互联网上！

· 您需要拥有一个域。

· 在域中创建一个A记录，以指向您的负载均衡器的IP

· 修补argo服务器，使其可以被L7 LB暴露

kubectl patch svc argo-server -n argo -p ‘{“spec”: {“type”: “NodePort”}}’

· 使用GKE ui创建入口，然后选择argo-server。

> select argo-server and hit “Create ingress”

· 在LB上启用IAP，因此您需要登录才能访问资源

> In the IAP ui you can add who should be allowed to your site!

那所有的气流操作员呢？

您将要松开某些东西，这就是所有气流操作员。 您可以通过运行gcloud /任何docker映像以及" gsutil"，" bq"等bash命令来模仿其中的一些/大部分。 但是，如果您的用例是使用大量内置的气流操作器，则argo工作流程不适合您。

其他要点—作曲家与Argo

自动缩放

· Argo可以自动缩放。 您可以有一个带有自动扩展节点池的小型群集，它可以正常工作。

· 另一方面，Composer不会-主要是因为Google如何配置它。 如果操作正确，Airflow可以轻松实现自动缩放。.一些中等职位对如何实现此目标有一些解决方案

用户界面

· Argo具有漂亮的简约UI，但不具有气流的所有功能

· Composer具有您所需的所有功能，但看起来很糟糕（希望这会有所改变）。

日程安排的根本差异

· Argo与DAG一起作为cron运行。

· Composer在带有开始时间的特定时间运行作业。 （并为您回填）

记录中

· Argo日志与kubernetes资源一起存储，这意味着一旦删除作业，它们也将被删除。 （除非运到stackdriver）。 流日志是在ui中实时完成的。

· Composer日志存储在存储桶中并进行版本控制。

结束语

总而言之，我真的很喜欢Argo。 我现在已经部署了两次（一次内部部署，一次是作为Cloud Composer替代品在客户身上部署），并且两个地方都使其表现非常出色。

它是Composer的绝佳替代品，特别是如果您已经拥有kubernetes集群并希望在该集群中调度作业！

对于那些每月最低费用380 $太多而无法在工作流计划上花费的人来说，这也很棒。

Composer仍然可以发挥作用。 它是一个功能强大的托管解决方案，您无需了解任何kubernetes，即可专注于从第一天开始创造业务价值！