This post is also available in the following languages. Japanese

使用 Argo Workflows 自動化 LINE 的 Baremetal 設置的故事

Kodai Matsumoto2022-08-15

Infrastructure Engineer at LINE Corporation.

嗨大家好，我是 LINE IT 系統服務中心的的松本。在這篇文章中，我想介紹一個關於 LINE 的 Baremetal 上設置自動化的專案，這專案自從我2019年應屆畢業加入LINE之後，我一直參與其中。

關於 Verda Baremetal as a Service

LINE 擁有基於 OpenStack 的私有雲服務 Verda，提供 VM 和儲存基礎設施相關資源。Verda 提供了多種服務，其中一種服務使用名為「Baremetal as a Service」，它有專屬的計算資源，透過直接在常規物理伺服器上安裝和使用操作 OS。不必擔心使用虛擬化技術時出現的開銷或各種虛擬機互相影響的問題。此外，由於LINE需要處理大量數據的服務性質，許多大型儲存集群也都在內部運行，因此對物理伺服器的需求仍然很高，這些伺服器需要可以容納大量磁碟，因此在選擇具體設備時，會需要使用特定型號。

為什麼使用Baremetal as a Service？

在 Verda Baremetal as a Service 無父的其他服務之前，我們基本上都根據內部開發人員的提交建構伺服器申請，並且給對應的伺服器。在以前的操作中有許多問題，如每次個人申請都需要人工安裝操作系統，從伺服器申請到實際提供伺服器這集間的交付時間變很長。此外，由於LINE需要處理的伺服器數量急劇增加，人工執行這些任務變得很不切實際。有鑒於這些問題，在 Verda 的「Baremetal as a Service」中，來自Verda Dashboard 的 Baremetal Instance 使用起來感覺與常規 VM 相同。在創建 Baremetal 時會自動執行作業系統安裝、刪除和重建。這降低了我們提供 Baremetal 的運營成本，並顯著縮短了向開發人員提供 Baremetal 的交付時間。

關於 Baremetal 初始設置過程

為了使用 Baremetal as a Service，並且搭配物理伺服器的性質，服務中存在著各種初始設置過程的內容：

（機架安裝/排線工作）
資產登記
設定 BIOS 和 BMC
OS 安裝
1. 雖然 Baremetal 初始設定不需要作業系統安裝，但 LINE 會對所有伺服器執行多次作業系統安裝測試，以確保伺服器硬體或其他配置正確無故障。
註冊私有雲服務 Verda

設置過程步驟本身並不多，但在處理數以萬計的伺服器（如LINE）的環境中，每年新增約10,000台左右的 Baremetal，當服務器多時，一次添購的服務器數可能達到數千台。我想你會明白，在這麼多機器的環境中設置BIOS和安裝OS手動操作是非常棘手的。而在此專案項目開始之前，這些工作實際上是手動操作；以下是我們當時面臨的問題的簡要總結：

需要處理大量的伺服器
設置和故障排除需要深入了解伺服器和LINE基礎設施，以便與新成員使用
工作內容間存在復雜的相賴關係，需要一邊手動執行一邊詳細管理工作狀態
每個系統管理者的工作內容存在細微差異，手動狀態下難以保證一定的產出品質
由於這是人工操作和確認，初始設置時的服務器和硬體故障經常被忽視

面對這些挑戰，我們非常努力以及花了很多時間來處理這些工作。特別是第五點，它是開發人員和管理 Baremetal as a Service 人員面臨的主要壓力點，因為這個問題是在開發人員從 Verda 的 Dashboard 創建 Baremetal 時會被看見。因此，我們解決了這些挑戰，並啟動了一個專案，透過開發和運行自己的系統，自動執行 Baremetal 初始設置過程。

BSIP 專案

BSIP 是一個專案，主要在自動化上述 Baremetal 初始設置過程。 BSIP 盡可能自動化 Baremetal 獨有未完善的初始設置過程，從而降低基礎設施營運成本。BSIP 使用 DAG(有向無環圖) 來表示具有依賴關係的 Baremetal 初始設置過程，並透過 Argo Workflows 處理。

什麼是 Argo Workflows？

“Argo Workflows”是一個由 CNCF 孵化專案 -“Argo”所提供的Kubernetes-Native Workflow Engine。我想很多人可能對 Argo CD 很熟悉，了解 Kubernetes 環境和 GitOps 的流程。 Argo Workflows 旨在用於 Kubernetes-Native 環境，所有資源都作為 Kubernetes CRD 實現。現在，讓我們快速總結一下 Argo Workflows 的功能:

將工作流中的每個步驟透過容器運行
您可以將多個處理步驟定義為 Workflows，也可以使用 DAG 定義處理步驟之間的相賴關係
利用Kubernetes-Native的特點，您可以輕鬆地採用水平擴展方法進行大型 Wrokflow 處理

有兩個主要原因，為什麼我們使用Argo Workflows 作為 BSIP。

首先，我最初在我的組織中推廣 Kubernetes-Native 環境。盡可能容器化傳統基礎架構資源(如 VM)來部署的內部系統，並在 Kubernetes-Native 環境中應用 GitOps 等部署策略。 Argo Workflows 也假定在 Kubernetes-Native 環境中使用，並且找到適合當前團隊中的趨勢。此外，由於我自己常關注 Kubernetes 生態系統的知識，確信自己與 Kubernetes 的生態系統有良好的連結。
其次，Argo Workflows 本身假定運行相對較大的 Workflow。如上所述，這利用了 Kubernetes-Native 的特性，採取水平擴展等方式。對於 BSIP，從一開始就假設當一次 Baremetal 設置的數量會到幾千個。這就是我們選擇 Argo Workflows 的原因，它使我們能夠輕鬆地採用水平擴展等方法。

Workflow

“Argo Workflows”以“Workflows”單位執行一組定義的操作。下面是一個範例 Workflows。其「Manifest」包含執行每個流程的步驟以及將這些步驟作為一系列工作流程執行的資訊。而 DAG 還允許步驟之間的相依關係，並且根據使用方式，可以處理具有複雜依賴項的 Workflows。

entrypoint: hello-hello-hello
templates:
- name: hello-hello-hello
  steps:
  - - name: hello1
      template: whalesay
      arguments:
        parameters: [{name: message, value: "hello1"}]
  - - name: hello2a
      template: whalesay
      arguments:
        parameters: [{name: message, value: "hello2a"}]
    - name: hello2b
      template: whalesay
      arguments:
        parameters: [{name: message, value: "hello2b"}]

BSIP和Argo Workflows

BSIP 的初始設置過程是透過在 Argo Workflows 的 WorkflowTemplate 中定義。 WorkflowTemplate 是 Argo Workflows 的 CRD 之一，顧名思義就是創建 Workflow 時可以作為 Template 使用的資源。 BSIP 基本上從這個 WorkflowTemplate 為每個要設置的服務器創建一個 Workflow，並在單獨的 Workflow 中為每個目標伺服器執行初始設置過程。這是因為 BSIP 要求特定的設置過程不受其他設置過程的影響。例如，假設您同時設置 100 台伺服器，則需考慮到在一台伺服器遇到任何故障時，其他設置過程不會停止。這聽起來似乎很自然，但在 LINE 伺服器數量相對較多的環境中，這一點非常重要。

以下是 BSIP 中使用的WorkflowTemplate的一部分。在此部分中，我們設定 BIOS、在 check-bios-settings 步驟中，我們提前獲取當前目標伺服器的 BIOS 資訊，如果與 LINE 裡面常用的 BIOS 設置不同，則下一步將執行正確的 BIOS 設置。由於 Argo Workflows 可以確定上一步的處理結束後，並執行下一步，因此 BSIP 可以很好地利用此功能，並在配置正確時跳過設置 BIOS 到下一步。

- name: check-bios-settings
  dependencies:
    - polling-health-check-ipmi
  template: bsip-task
  continueOn:
    failed: true
  arguments:
    parameters:
      - name: taskName
        value: check-bios-settings
    artifacts:
      - name: manifest
        from: "{{workflow.outputs.artifacts.manifest}}"
- name: set-bios-settings
　　# 只有在 BIOS 設置不正確時才運行 BIOS 設置步驟
  when: "{{tasks.check-bios-settings.status}} == Failed"
  dependencies:
    - check-bios-settings
  template: bsip-task
  arguments:
    parameters:
      - name: taskName
        value: set-bios-settings
    artifacts:
      - name: manifest
        from: "{{workflow.outputs.artifacts.manifest}}"
- name: bios-settings-apply-hard-reboot
  when: "{{tasks.check-bios-settings.status}} == Failed"
  dependencies:
    - set-bios-settings
  template: bsip-task
  arguments:
    parameters:
      - name: taskName
        value: hard-reboot
    artifacts:
      - name: manifest
        from: "{{workflow.outputs.artifacts.manifest}}"
- name: polling-check-bios-settings
  when: "{{tasks.check-bios-settings.status}} == Failed"
  dependencies:
    - bios-settings-apply-hard-reboot
  template: bsip-task
  arguments:
    parameters:
      - name: taskName
        value: polling-check-bios-settings
    artifacts:
      - name: manifest
        from: "{{workflow.outputs.artifacts.manifest}}"

LINE 的一些初始設置中，為了提前排除服務氣本身的初始故障和硬體故障，有一個可以實際測試創建了一個 Baremetal Instance 並在環境中安裝了OS。這樣做是為了提前預防向內部開發人員提供 Baremetal 時所出現的麻煩。這些工作也與 Argo Workflows 上的 Workflows 處理所需的系統相互關聯，並使用 PXE Boot 等來完全自動完成安裝測試和測試後的檢查。

因此，當前的 BSIP 完全自動地為每個 Baremetal 執行大約 17 個步驟的初始設置過程。

易於重新執行

由於 Baremetal 處理物理伺服器的性質，因此出現了一定數量的初始故障或硬體故障。當然，如果存在此類伺服器，則必須修復故障並重新啟動設置。在這種情況下，您應該能夠多次重做設置過程。 BSIP 設計為安全重新運行每個設置過程，以便在發生重新設置等情況時，只需重新創建工作流即可重新設置。

GitOps對Baremetal進行管理

在這次的分享中我有點離題，但我想簡要地介紹一下 LINE 的 Baremetal 管理手法。目前 LINE 使用 Git 來管理 Baremetal 使用的物理服務器。所有 Baremetal 訊息都在 Git 上的 YAML 文件中以聲明方式進行管理，並使用 ArgoCD 將 YAML 檔上的資訊部署到相關系統（如 OpenStack）。

servers:
  server1:
    baremetal_ipmi_mac: 00:00:00:00:00:00
    baremetal_private_ip: 192.168.1.1
    baremetal_private_mac: 00:00:00:00:00:00
    baremetal_flavor_aggregate: FLAVOR1
    baremetal_dc_aggregate: Tokyo
    baremetal_private_network_aggregate: PRIVATE_NETWORK
    baremetal_public_network_aggregate: PUBLIC_NETWORK
  server2:
    baremetal_ipmi_mac: 00:00:00:00:00:00
    baremetal_private_ip: 192.168.1.2
    baremetal_private_mac: 00:00:00:00:00:00
    baremetal_flavor_aggregate: FLAVOR2
    baremetal_dc_aggregate: Tokyo
    baremetal_private_network_aggregate: PRIVATE_NETWORK
    baremetal_public_network_aggregate: PUBLIC_NETWOR

在以前不使用 GitOps 的流程時，管理人員需要使用相關 API 註冊新 Baremetal 任務。在那些日子裡，操作方法不僅使員工的工作成本變很高，而且他們還遇到一個問題，就是如何在完成這項工作時進行審查。另一方面，最近引入的使用 GitOps 的 Baremetal 管理手法基本上允許在 Git 上執行所有任務，包括添加和刪除 Baremetal。如果要添加新的 Baremetal，可以添加到 Git 上的 Baremetal 硬體資訊，並使用 Pull Request 發出需求，管理人員會根據需求來 Review PR。由於現在可以在 Git 上管理 Baremetal，即使像是 Mac Address 更改，或是服務器故障等而更換硬體零件時，Git 上的服務器訊息都可以重寫，您可以通過以下方式應用這些更改。

在 BSIP 中，透過 Argo Workflows 上的處理以 YAML 文件格式註冊（Git Push）Baremetal 訊息，最後在將 Baremetal 提供給正在開發 LINE 服務的內部開發人員。

BSIP 部署後的現狀

到 2022 年，當 BSIP 被導入時，Baremetal 的初始設置工作時間已經大大減少，過去需要大約 2-3 天的工作時間，現在在每台服務器大約 1 小時內即可完成。在介紹 BSIP 的過程中，我們回顧了 setup 本身，不管如何，我覺得無論是工作時間還是開發者的負荷都得到了很大的改善。

此外，在安裝過程中出現硬體問題然後設定失敗的情況下，現在可以從 Argo Workflows 上的 log 檢查狀態並開始故障排除，從而提高了故障排除的可操作性。目前，工程師仍需要從 WebUI 上手動觸發，啟動 Argo Workflows 的工作流程，但我相信，我們今後將致力於自動化這一部分，並實現更進一步全自動化。

在 BSIP 中採用 Argo Workflows 時的感受

從結論來看，我認為在 BSIP 中採用 Argo Workflows 是一個很大的正確答案。

Kubernetes-Based 工作流引擎的Argo工作流的易用性

首先，它使 Argo Workflows 在 Kubernetes-Based Workflow Engine 中更易於處理。我前面提到，Argo Workflows 本身是容器化技術和 Kubernetes 的 CRD 製成的，換句話說，只需以某種方式實現您想要執行的過程並使其成為 Container Image，然後只要撰寫 Argo Workflows 的 Manifest 即可完成一系列工作流程。當然，Argo Workflows 的學習成本會很高，但只要有機會，相信任何人都可以自由、相對輕鬆地執行 Workflows 處理。透過將所有 Workflows 和設置委派給 Argo Workflows，我們的 BSIP 開發人員只需專注於他們執行的每一個實現並進行維護即可，也使得 BSIP 本身更易於維護。

現在很清楚該怎麼做了

使用 Argo Workflows 自動化 Baremetal 初始設置時，很清楚的顯示我們接下來必須做什麼。而 BSIP 現在可以透過將工作流程應用到 Argo Workflows 來自動執行 Baremetal 的初始設置。因此，如果想進一步自動化 Baremetal 的初始設置，可以撰寫完的 Workflow 應用推到 Argo Workflows 中，換句話說，最好為 Argo Workflows 創建一個 Manifest 並將其推送到 API。

在當前的 BSIP 中，需要手動創建執行 Workflow 所需的服務器資訊，但是如果將來可以透過結合 ZTP（Zero Touch Provisioning）的機制來實現這部分的自動化，將可以把自動化帶到下一個級別。而我也覺得到導入 Argo Workflows 時讓我們清楚什麼時候該做什麼事。

性能優化

這是 Argo Workflows 本身的故事，但在 Argo Workflows 中，當 Workflow 執行時，會為 Workflow 中的每個步驟創建和執行 Kubernetes Pod。考慮到在 BSIP 中，如果一次的 Workflows 中有 10 個步驟，而你想一次設置 1000 個 Baremetals，那麼 Kubernetes 就會有 10 個 Pod（步驟）* 1000 個 Workflows = 10000 個 Pods 在集群上建立。Kubernetes 本身基本上可以水平擴展，但是說到 Argo Workflows 本身的性能調優，就沒有那麼簡單了。Argo Workflows 有一些組件因為架構而無法水平擴展。

這次對 BSIP 中使用的 Argo Workflows 進行了許多參數調整和配置更改，例如調整這些組件的垂直縮放所需的參數，以及將儲存在 Etcd 中的 Workflow 訊息轉存到 MySQL 裡。我覺得這些訊息還沒有辦法作為一般資訊發佈出去。事實上，即使在這個 BSIP 中，我們也是透過重複大量未經優化的實驗和錯誤來進行性能調優。

Argo Workflows Manifest 的學習成本

當然，要使用Argo Workflows，您需要以 YAML 格式來定義資源（如 Workflow 資訊）的Manifest，但編寫此工作流程的學習成本很高。雖然 Argo Workflows 本身可以執行的操作範圍相當廣泛，但另一方面，我覺得 Manifest 的結構很複雜，也讓學習成本相對較高。

總結

我介紹了我加入公司以來一直參與的 LINE 的 Baremetal 初始設置流程，如何將該流程使用 Argo Workflows 實現自動化。在後半部分，我們談論的是 Argo Workflows，也因為 Argo Workflows 本身是一個相當方便的工具，我認為根據能夠使用方式與情境，讓各種任務可以更有效率且自動化。

正如我們在這裡討論的 Baremetal 設置自動化一樣，LINE 需要隨著服務的增長而擴展各種伺服器基礎設施，從而進一步提高營運效率和改進。如果您想參與LINE的基礎設施，請查看以下職位，感謝大家持續看到本篇結尾！

LINE Corporation 正在尋找與我們合作的工程師！以下是與本篇相關的職位，等你來加入：
- 台灣
  - Site Reliability Engineer
- 日本

Blog

使用 Argo Workflows 自動化 LINE 的 Baremetal 設置的故事

關於 Verda Baremetal as a Service

為什麼使用Baremetal as a Service？

關於 Baremetal 初始設置過程

BSIP 專案

什麼是 Argo Workflows？

Workflow

​

BSIP和Argo Workflows

易於重新執行

GitOps對Baremetal進行管理

BSIP 部署後的現狀

在 BSIP 中採用 Argo Workflows 時的感受

Kubernetes-Based 工作流引擎的Argo工作流的易用性

現在很清楚該怎麼做了

性能優化

Argo Workflows Manifest 的學習成本

總結