前言
Hi 大家好我是 LINE Taiwan SRE team - Wei，平常我們使用 Kubernetes Job / Cronjob 可以滿足我們簡單的任務需求，像是資料庫備份清理等…每日作業，那遇到更複雜的任務編排需求該怎麼辦呢？
舉例來說：我想要做完 A 任務然後並行處理 BCDEFG 任務，然後前面的任務都成功最後進行 H 任務。又或者是我想要在滿足某個特定條件，例如：某個 K8S 資源被創建、某個 Webhook 被呼叫等…在觸發的的任務。以上這些複雜的需求雖然全部使用 K8S SDK 自己開發也可以達成，但是透過 Argo Event / Workflow 提供的抽象畫以及可組裝式的各種組件，然後再發揮一下自己的創意就能夠減少很多的開發工作，而且之後也能後很好的重複使用曾經使用過的組件。
本次主題將帶大家認識 Argo Event / Workflow 以及介紹 SRE Team 使用它們建置的全託管 Lighthouse 網頁跑分平台。
活動影片
TW SRE 日常提供的服務
為什麼需要 Argo Event & Workflow？
背景
我們從SRE提供的Sentry服務開始說起，Sentry是一個可以蒐集前後端應用程式錯誤的平台，此外他也能夠順便統計Web Vital的指標。
在這個一個功能強大的資料蒐集系統背後，能夠乘載這些資料的資料庫是必須的，因此SRE團隊也必須架設跟維護對應的資料庫，如下圖：
可以看見紅框圈起來的部分，就是我們Sentry儲存核心資料的地方，PostgrSQL跟ClickHouse，架設這兩個資料庫其中有一項重要的工作
就是處理備份的問題，因此我們就需要請出我們的大殺器Argo Workflows來構建我們的備份工作。
如何處理
盤點一下我們需要做備份的資料大概有PostgreSQL一個實例、ClickHouse 12個Shard如下圖：
一開始，我們可以很直接的想到直接做資料庫備份的shell script然後部屬成Kubernetes的Cronjob如下圖：
這樣子做可以很好完成我們的備份作業但是會有以下的缺點：
- 不同環境的備份腳本需要四處複製貼上，不好維護
- 單一用途的Job，例如：備份PostgreSQL無法重用
- 腳本中途失敗不好除錯
因此我們決定導入Argo Workflows來解決上面的這些缺點
透過 Argo Workflows 建立可重複使用的 Cronjob
什麼是 Argo Workflows?
Argo Workflows 是一個開源容器原生工作流引擎，用於在 Kubernetes 上編排並行作業。 Argo Workflows 實現為 Kubernetes CRD(自定義資源定義)。
- 定義工作流中的每個步驟都是一個容器的工作流。
- 將多步驟工作流建模為一系列任務或使用有向無環圖 (DAG) 捕獲任務之間的依賴關係。
- 使用 Kubernetes 上的 Argo Workflows 在很短的時間內輕鬆運行機器學習或數據處理的計算密集型作業。
- 在 Kubernetes 上本地運行 CI/CD 管道，無需配置複雜的軟件開發產品。
首先我們來簡單看一下Workflow 跟 Kubernetes Job撰寫起來的差異，可以很簡單的看到，其實Workflow跟Job撰寫上沒有太多差異，最大的差別就是在Workflow裡可以定義很多的Step
放在templates這個字段底下，這些steps支援很多種不同的形式等等會一一介紹。
首先介紹以下五種單一用途的template
- container
跟經典的Job一樣可以跑一個容器執行指定的指令 - script
跑一個容器自己指定的腳本 - resource
創建一個Kubernetes資源 - delay
單純睡覺一個時間 - http
執行http call
接著來介紹以下兩種用於工作流程編排的template
- steps
雙層陣列，可以參考已經定義的template然後指定他們的執行順序，最外層陣列順序執行，內層陣列併發執行 - dag
可以參考已經定義的template然後指定他們的執行順序，透過定義依賴步驟的方式建立執行順序
實戰
接下來就是實戰的部分，我們來介紹一個新的CRD：ClusterWorkflowTemplate，透過這個CRD你可以把經常使用的Workflow抽出來並宣告參數，這樣就能在其他的Workflow裡引用，達到重用的效果。
如下圖我們訂一了一個CronWorkflow，看名字就能很好理解，就如同Cronjob一般能夠定時直接我們Workflow裡定義的步驟，在這個Workflow裡，我們引用了前一個步驟的ClusterWorkflowTemplate，
並用了withItem字段來帶入陣列型態的參數，這樣Argo Workflows會自動幫我們展開每一個Step。
到此為止我們資料庫備份的Workflow就做好了，下圖是實際部屬到Cluster上的樣子。
什麼是 Lighthouse CI ?
不少人應該都有看過這個畫面，這是隱藏在Chrome瀏覽器裡的功能，能夠對一個網站做跑分，並呈現一個報表。
Lighthouse CI是一個整合性的解決方案，提供了cli讓開發團隊整合在CI pipeline中做跑分，並提供了一個Server持續蒐集並統計這些數據，並呈現在web上。
那這又遇到了甚麼問題呢？其實讓每個團隊去設定lighthouse ci在ci系統上是一件複雜的工作，為了要能夠運行這個跑分軟體，你需要安裝headless chrome在你的ci平台上並且需要足夠的資源，我們SRE團隊看到了這個問題
因此想要幫助家家可以很輕鬆地使用這套工具而不需要去配置這些前置作業，因此就有了LHCI Farm這平台的誕生。
Argo Events 事件驅動的工作流自動化框架
如下圖：Argo Events是一個事件驅動的自動化框架，他能夠支援多種事件來源，例如：webhook、nats、kafka、aws sns等等......
並且按照撰寫在CRD裡的條件去觸發不同的事情，例如：創建Kubernetes資源、呼叫AWS Lambda等等......
首先我們來介紹兩個核心概念，第一個是EventSource，你可以透過CRD去定義它，如下圖：這邊定義了一個Webhook的EventSource，當你安裝這個CRD到級群裡，Argo Events就會幫你創建對應的Deployment，該Deployment會監聽你指定的端口還有路徑。
接著是Sensor，顧名思義就是傳感器，在這個CRD中定義你要觸發操作的事件源(EventSource)跟要對應的操作(Trigger)。
實戰
在LINE內部有一個系統，是可以幫助大家部署自己的靜態網頁，以下就會拿這個系統來當例子，說明它是怎麼樣使用我們的這個LHCI Farm平台:
基本上High Level架構如下，使用者在該平台上點及按鈕就能觸發Lighthouse掃描，它會呼叫一個API給SRE這邊開發的一個Server，上面會做驗證資料以及預先生成lhci cli需要的設定檔，
然後就會呼叫Argo Event的webhook EventSource，接著預先定義好的Sensor就會出發創建一個跑分的Workflow來做跑分。
以下就是一些實際上要達成這些步驟的CRD，基本上內容前面有介紹過這邊就不贅述了。
我們整個系統都部屬起來後，同樣能在Argo的web介面上看到簡單的呼叫關係圖以及產生的Workflow，這些界面都很方便去除錯。
結論
很高興經過了這麼久時間可以在線下與大家見面，希望透過這次的分享讓更多對於 Infra、SRE、DevOps...有興趣的朋友可以學到更多 Argo 好用的地方，如果覺得這篇內容有幫助，歡迎分享給周遭的朋友們。
另外，台灣 SRE 團隊也有開職缺啦！如果想加入我們的朋友，趕快把握機會投遞履歷，跟著我們一起打造 Taiwan Observability Platform！那我們就下次活動見囉！
最後不管你是技術社群、學校、社團、系學會，若對於來 LINE 辦公室舉辦活動有興，歡迎發送各位的需求到這個連絡信箱： dl_twn_devrel@linecorp.com
活動小結
立即加入「LINE 開發者官方社群」官方帳號，就能收到第一手 Meetup 活動，或與開發者計畫有關的最新消息的推播通知。▼
「LINE 開發者官方社群」官方帳號 ID：@line_tw_dev
關於「LINE 開發社群計畫」
LINE 於 2019 年開始在台灣啟動「LINE 開發社群計畫」，將長期投入人力與資源在台灣舉辦對內對外、線上線下的開發者社群聚會、徵才日、開發者大會等，已經舉辦 30 場以上的活動。歡迎讀者們能夠持續回來察看最新的狀況。詳情請看:
- 2019 年 LINE 開發社群計畫活動時程表
- LINE Taiwan Developer Relations 2019 回顧與 2019 開發社群計畫報告
- 2020 年 LINE 開發社群計畫活動時程表
- 2021 年 LINE 開發社群計畫活動時程表 (持續更新)