在計(jì)算機(jī)中，流水線是把一個(gè)重復(fù)的過程分解為若干個(gè)子過程，使每個(gè)子過程與其他子過程并行進(jìn)行的技術(shù)，也叫 Pipeline。由于這種 s工作方式與工廠中的生產(chǎn)流水線十分相似， 因此也被稱為流水線技術(shù)。從本質(zhì)上講，流水線技術(shù)是一種時(shí)間并行技術(shù)。以“構(gòu)建鏡像”過程為例：
在每一次構(gòu)建鏡像中，我們都需要拉下代碼倉(cāng)庫(kù)中的代碼，進(jìn)行代碼編譯，構(gòu)建鏡像，最后推往鏡像倉(cāng)庫(kù)。在每一次代碼更改過后，這一過程都是不變的。使用流水線工具可以極大的提升這一過程的效率，只需要進(jìn)行簡(jiǎn)單的配置便可以輕松的完成重復(fù)性的工作。這樣的過程也被稱之為 CI。上圖流程中使用的是 Jenkins。Jenkins 作為老牌流水線框架被大家所熟知。在云原生時(shí)代，Jenkins 推出了 Jenkins X 作為基于 Kubernetes 的新一代流水線，另外云原生時(shí)代還誕生了兩大流水線框架—— Argo 和 Tekton。本文就詳細(xì)介紹了 Argo 的相關(guān)內(nèi)容。
Argo Workflows 是一個(gè)開源的容器原生的工作流引擎，可在 Kubernetes 上編排并行作業(yè)。Argo Workflows 實(shí)現(xiàn)為 Kubernetes CRD。Argo 基于 Kubernetes，可以直接使用 kubectl 安裝，安裝的組件主要包括了一些 CRD 以及對(duì)應(yīng)的 controller 和一個(gè) server。
注意，上述安裝只會(huì)執(zhí)行同 namespace 內(nèi)的 Workflow，cluster install 詳見文檔。文檔地址：https://github.com/argoproj/argo/blob/master/docs/installation.md
要了解 Argo 定義的 CRD，先從其中的三級(jí)定義入手。概念上的從大到小分別為 WorkflowTemplate、Workflow、template，這些資源的命名有些相似，要注意分辨。
從最簡(jiǎn)單的 template 說起，一個(gè) template 有多種類型，分別為 container、script、dag、steps、resource 以及 suspend。對(duì)于 template，我們可以簡(jiǎn)單的將其理解為一個(gè) Pod ——container/script/resource 類型的 template 都會(huì)去實(shí)際控制一個(gè) Pod，而 dag/steps 類型的 template 則是由多個(gè)基礎(chǔ)類型的 template （container/script/resource）組成的。
container：最常見的模板類型，與 Kubernetes container spec 保持一致。
script：該類型基于 Container，支持用戶在 template 定義一段腳本，另有一個(gè) Source 字段來表示腳本的運(yùn)行環(huán)境。
resource：該類型支持我們?cè)?template 中對(duì) kubernetes 的資源進(jìn)行操作，有一個(gè) action 字段可以指定操作類型，如 create, apply, delete 等，并且支持設(shè)定相關(guān)的成功與失敗條件用于判斷該 template 的成功與失敗。
suspend：Suspend template 將在一段時(shí)間內(nèi)或在手動(dòng)恢復(fù)執(zhí)行之前暫停執(zhí)行?？梢詮?CLI （使用 argo resume）、API 或 UI 恢復(fù)執(zhí)行。
steps：Steps Template 允許用戶以一系列步驟定義任務(wù)。在 Steps 中，[--] 代表順序執(zhí)行，[-] 代表并行執(zhí)行。
dag：DAG template 允許用戶將任務(wù)定義為帶依賴的有向無環(huán)圖。在 DAG 中，通過 dependencies設(shè)置在特定任務(wù)開始之前必須完成的其他任務(wù)。沒有任何依賴項(xiàng)的任務(wù)將立即運(yùn)行。有關(guān) DAG 的詳細(xì)邏輯可見源碼 https://github.com/argoproj/argo/blob/master/workflow/controller/dag.go#L204。
在一個(gè) Workflow 中，其 spec 中有一個(gè)名為 templates 的字段，在其中至少需要一個(gè) template 作為其組成的任務(wù)。一個(gè)最簡(jiǎn)單的 hello world 例子如下：
在這個(gè)例子中，該 Workflow 的 templates 字段中指定了一個(gè)類型為 container 的 template，使用了 whalesay 鏡像。下面是一個(gè)稍微復(fù)雜的 workflow：
WorkflowTemplate 相當(dāng)于 Workflow 的模板庫(kù)，和 Workflow 一樣，也由 template 組成。用戶在創(chuàng)建完 WorkflowTemplate 后，可以通過直接提交它們來執(zhí)行 Workflow。
在了解了 Argo 的三級(jí)定義后，我們首先來深入一下 Argo 中最為關(guān)鍵的定義，Workflow。Workflow 是 Argo 中最重要的資源，有兩個(gè)重要的功能：
由于這些雙重職責(zé)，Workflow 應(yīng)該被視為一個(gè) Active 的對(duì)象。它不僅是一個(gè)靜態(tài)定義，也是上述定義的一個(gè)“實(shí)例”。Workflow Template 的定義與 Workflow 幾乎一致，除了類型不同。正因?yàn)?Workflow 既可以是一個(gè)定義也可以是一個(gè)實(shí)例，所以才需要 WorkflowTemplate 作為 Workflow 的模板，WorkflowTemplate 在定義后可以通過提交（Submit）來創(chuàng)建一個(gè) Workflow。而 Workflow 由一個(gè) entrypoint 及一系列 template 組成，entrypoint 定義了這個(gè) workflow 執(zhí)行的入口，而 template 會(huì)實(shí)際去執(zhí)行一個(gè) Pod，其中，用戶定義的內(nèi)容會(huì)在 Pod 中以 Main Container 體現(xiàn)。此外，還有兩個(gè) Sidecar 來輔助運(yùn)行。
在 Argo 中，這些 Sidecar 的鏡像都是 argoexec。Argo 通過這個(gè) executor 來完成一些流程控制。
當(dāng)用戶的 template 中需要使用到 inputs 中的 artifact 或者是 script 類型時(shí)（script 類型需要注入腳本），Argo 都會(huì)為這個(gè) pod 加上一個(gè) Init Container —— 其鏡像為 argoexec，命令是 argoexec init。在這個(gè) Init Container 中，主要工作就是加載 artifact：
除了 Resource 類型外的 template，Argo 都會(huì)注入一個(gè) Wait Container，用于等待 Main Container 的完成并結(jié)束所有 Sidecar。這個(gè) Wait Container 的鏡像同樣為 argoexec，命令是 argoexec wait。（Resource 類型的不需要是因?yàn)?Resource 類型的 template 直接使用 argoexec 作為 Main Container 運(yùn)行）在運(yùn)行 Workflow 時(shí)，一個(gè)常見的場(chǎng)景是輸出產(chǎn)物的傳遞。通常，一個(gè) Step 的輸出產(chǎn)物可以用作后續(xù)步驟的輸入產(chǎn)物。在 Argo 中，產(chǎn)物可以通過 Artifact 或是 Parameter 傳遞。
要使用 Argo 的 Artifact，首先必須配置和使用 Artifact 存儲(chǔ)倉(cāng)庫(kù)。具體的配置方式可以通過修改存有 Artifact Repository 信息的默認(rèn) Config Map 或者在 Workflow 中顯示指定，詳見 配置文檔，在此不做贅述。下表為 Argo 支持的倉(cāng)庫(kù)類型。
一個(gè)簡(jiǎn)單的使用了 Artifact 的例子如下：
默認(rèn)情況下，Artifact 被打包為 tar 包和 gzip 包，我們也可以使用 archive 字段指定存檔策略。在上面的例子里，名為 whalesay 的 template 使用 cowsay 命令生成一個(gè)名為 /tmp/hello-world.txt 的文件，然后將該文件作為一個(gè)名為 hello-art 的 Artifact 輸出。名為 print-message 的 template 接受一個(gè)名為 message 的輸入 Artifact，在 /tmp/message 的路徑上解包它，然后使用 cat 命令打印 /tmp/message 的內(nèi)容。在前面 Sidecar 介紹中提到過，Init Container 主要用于拉取 Artifact 產(chǎn)物。這些 Sidecar 正是產(chǎn)物傳遞的關(guān)鍵。下面，我們通過介紹另一種產(chǎn)物傳遞的方式來體驗(yàn) Argo 中傳遞產(chǎn)物的關(guān)鍵。
在上面的例子中，有兩個(gè)類型為 script 的 template，script 允許使用 source 規(guī)范腳本主體。這將創(chuàng)建一個(gè)包含腳本主體的臨時(shí)文件，然后將臨時(shí)文件的名稱作為最后一個(gè)參數(shù)傳遞給 command（執(zhí)行腳本主體的解釋器），這樣便可以方便的執(zhí)行不同類型的腳本（bash、python、js etc）。Script template 會(huì)將腳本的標(biāo)準(zhǔn)輸出分配給一個(gè)名為 result 的特殊輸出參數(shù)從而被其他 template 調(diào)用。在這里，通過 {{steps.generate.outputs.result}} 即可獲取到名為 generate 的 template 的腳本輸出。{{xxx}} 是 Argo 固定的變量替換格式：- 關(guān)于變量的格式詳見文檔，文檔地址：https://github.com/argoproj/argo/blob/master/docs/variables.md
- 關(guān)于變量替換的邏輯詳見源碼，源碼地址：https://github.com/argoproj/argo/blob/master/workflow/common/util.go#L305
那么，容器內(nèi)部應(yīng)該如何獲取這個(gè)腳本輸出呢？我們回到 Sidecar，在 Wait Container 中，有這樣一段邏輯：
再來看看這個(gè) Wait Container 的 Volume Mount 情況：
現(xiàn)在就十分明確了，Wait Container 通過掛載 docker.sock 以及 service account，獲取到 Main Container 中的輸出結(jié)果，并保存到 Workflow 中。當(dāng)然，因?yàn)?Workflow 中保存了大量的信息，當(dāng)一個(gè) Workflow 的 Step 過多時(shí)，整個(gè) Workflow 的結(jié)構(gòu)會(huì)過于龐大。Parameter 提供了一種通用機(jī)制，可以將步驟的結(jié)果用作參數(shù)。Parameter 的工作原理與腳本結(jié)果類似，除了輸出參數(shù)的值會(huì)被設(shè)置為生成文件的內(nèi)容，而不是 stdout 的內(nèi)容。如：
這并不是 Argo 處理產(chǎn)物傳遞的一種標(biāo)準(zhǔn)方式，但是通過共享存儲(chǔ)，我們顯然也能達(dá)到共通產(chǎn)物的結(jié)果。當(dāng)然，如果使用 Volume，我們則無需借助 Inputs 和 Outputs。在 Workflow 的 Spec 中，我們定義一個(gè) Volume 模板：
并在其他的 template 中 mount 該 volume：循環(huán)
在編寫 Workflow 時(shí)，能夠循環(huán)迭代一組輸入通常是非常有用的，如下例所示:
在源碼實(shí)現(xiàn)中，將會(huì)去判斷 withItems，如果存在，則對(duì)其中的每個(gè)元素進(jìn)行一次 step 的擴(kuò)展。
Template 可以遞歸地相互調(diào)用，這是一個(gè)非常實(shí)用的功能。例如在機(jī)器學(xué)習(xí)場(chǎng)景中：可以設(shè)定準(zhǔn)確率必須滿足一個(gè)值，否則就持續(xù)進(jìn)行訓(xùn)練。在下面這個(gè)拋硬幣例子中，我們可以持續(xù)拋硬幣，直到出現(xiàn)正面才結(jié)束整個(gè)工作流。
以下是兩次執(zhí)行的結(jié)果，第一次執(zhí)行直接拋到正面，結(jié)束流程；第二次重復(fù)三次后才拋到正面，結(jié)束流程。
退出處理是一個(gè)指定在 workflow 結(jié)束時(shí)執(zhí)行的 template，無論成功或失敗。相較于 Tekton 而言，Argo 的流程控制功能更加豐富。擁有著循環(huán)、遞歸等功能，這對(duì)于一些機(jī)器學(xué)習(xí)的場(chǎng)景都是十分適用的。而 Argo 社區(qū)對(duì)自己的定位也是 MLOps、AIOps、Data/Batch Processing，這也正是 Kubeflow Pipeline 底層基于 Argo 的原因（盡管 KFP 也在做 Tekton 的 backend）。
但是在權(quán)限控制方面，Argo 做的就不如 Tekton，我個(gè)人認(rèn)為，Tekton 的結(jié)構(gòu)定義更為清晰。二者各有優(yōu)劣，可以根據(jù)自己的需求進(jìn)行選擇。- Argo Roadmap：https://github.com/argoproj/argo/blob/master/docs/roadmap.md
- Argo Examples：https://argoproj.github.io/argo/examples/#welcome
- Argo Source Code：https://github.com/argoproj/argo
點(diǎn)擊屏末 | 閱讀原文 | 即刻學(xué)習(xí)