CNCF觸發了ARM64和X86的平台平等突破

Arm64 架構開源軟件的CI/CD 難題與解決方案

在Arm64 架構上部署開源軟件需要一個強大的CI/CD 環境。然而，Arm64 和傳統x86 處理器架構的支持水平之間存在差異，Arm64 通常處於劣勢。面向多種架構的基礎設施組件開發人員對工作環境有一定的期望：

• 一致性：跨平台使用的工具和方法保持一致，避免因採用不太流行的平台而需要改變開發流程。
• 性能：平台和支持機制具有良好的性能，確保在支持多個平台時部署方案不會因速度不足而受影響。
• 測試覆蓋率：對所有平台同時進行效率、合規性和安全性測試，且無需進行重大區分。
• 可維護性：使開發人員能夠自動化集成和重新開發流程，使其適用於所有平台而無需修改。

這些組件的產品經理也需要滿足這些要求，此外還有至少兩點：

• 平台覆蓋能力：技術客戶經理(TAM) 具備響應客戶需求所需的技能和準備。
• 支持分級能力：使TAM 和其他IT 人員能夠根據響應緊急或突發客戶問題的能力對軟件支持級別進行分類。

Actuated 平台的助力

開源開發者Alex Ellis 與Ampere 和基礎設施提供商Equinix 合作，為雲原生軟件生態系統中一些最關鍵的開源項目提供了Actuated CI/CD 平台。

Actuated 將GitHub 自託管自動化流程（安全工程師證明其容易受到惡意攻擊）在與公共互聯網隔離的微虛擬機中運行。

實施與成果

幾個關鍵的CNCF 開源項目利用Actuated 環境運行其所有Arm64 的GitHub Actions。該環境基於Ampere® Altra® 處理器，並在基礎設施提供商Equinix 的幫助下提供。

這項舉措的成功促使GitHub 為GitHub Actions 提供了完整的Arm64 架構支持。現在，以前在x86 架構的QEMU 模擬環境中運行Arm64 構建流程的開發人員可以將其遷移到裸機上的Arm64。

GitHub Actions 的Arm64 自託管運行器

GitHub 佔據了軟件項目託管的主導地位。 GitHub 託管項目生成持續集成構建和發布最流行的方式是使用平台內置的CI 工具集GitHub Actions。 GitHub Actions CI/CD 平台最重要的作用是自動化軟件開發流程。

觸發任何GitHub Action 的責任方是運行器。它是在服務器上運行的代理，等待任務並準備好一旦收到任務就執行。它從工作流程中獲得任務，並負責完成它。

GitHub 是一個完整的軟件部署平台。因此，它託管自己的運行器，每個運行器都適應其指定的目標環境和架構。直到最近，GitHub 還沒有為Arm64 提供託管運行器環境。想要生成Arm64 原生構建的項目確實有一個選擇——自託管運行器。

GitHub 用戶可以在其他地方託管的物理機或虛擬機上安裝代理，並讓GitHub Actions 將作業分派到該主機，由項目用戶管理。這要求項目管理員不僅要管理項目本身，還要負責維護和保障項目將使用的構建環境的安全。

在CNCF 的案例中，開發人員利用了Equinix Metal 的積分，使他們能夠配置裸機實例並將其用作項目的自託管運行器。但是對於必須全天候向全球其他開發人員提供服務的代碼實驗室項目而言，自託管運行器的安全性構成挑戰：根據GitHub 文檔，任何人都可以克隆項目存儲庫，修改Actions 作業，並訪問運行器節點以運行任意作業。

另一個問題是確保CI 運行之間的一致性。對於自託管運行器，如果CI 作業存在副作用，例如配置更改或之後留下的文件，它們仍將存在於後續作業中。

這帶來了一個問題——在運行構建或測試軟件的CI 作業時，應該擁有一個受控的環境，以便每次運行之間唯一變化的是軟件。對於自託管運行器，環境會隨著時間的推移而發生漂移。如果沒有清理過程，同一個主機上相同構建作業的運行可能會隨著時間的推移而產生不同的結果。

開發人員繞過對Arm64 原生運行器需求的一種方法是在x86 服務器上運行虛擬Arm64 環境，使用QEMU 開源模擬。模擬環境為軟件編譯增加了巨大的性能開銷，其速度只是在原生、非模擬硬件上編譯速度的一小部分。

模擬對於開發中小型項目足夠好用。但是，如果開發人員必須為ARM64 構建大型且重要的項目，那麼對虛擬環境的壓力就會變得非常大，以至於構建會完全失敗。

差距現象

與典型的企業不同，CNCF 有義務為世界上所有主要的處理器架構構建其云原生組件。

containerd 可移植容器運行時、etcd 鍵值數據存儲、fluentd 日誌數據收集器、Falco 實時威脅檢測工具和OpenTelemetry 可觀測性和檢測工具包等項目是雲原生生態系統的關鍵依賴項，因此必須為x86 和Arm64 構建。

為了構建支持Arm64 的低級基礎設施組件，CNCF 開發人員需要訪問原生的Arm64 基礎設施。具有諷刺意味的是，這意味著他們需要他們正在嘗試創建的工具類別。

最初，Ampere 和Equinix 與CNCF 合作克服這些差距，通過捐贈基於Ampere Altra 的服務器或在Equinix 設施中設置基於Altra 的裸機節點。 Equinix 可以共享的基於Arm64 的服務器資源的粒度是裸機節點——160 核雙插槽Ampere Altra 系統。

理想情況下，這樣的服務器將在多個項目之間共享，但這在當時超出了CNCF 的能力範圍。這就是Ampere 和Actuated 提出為CNCF 解決的問題，通過允許多個項目在較少的數量的主機上運行，從而為更多項目提供對構建服務的輕鬆訪問，同時消耗更少的硬件。

突破：Actuated 和一行代碼的修改

為了邁向x86 和Arm64 之間平台一致性的第一步，Ampere 尋求了Alex Ellis 的幫助，他是名為Actuated 的服務的創建者。這是一個在安全的、隔離的微虛擬機中運行GitHub Actions 作業的產品，該產品經過檢測以接收來自GitHub Actions 的構建作業，並為開發人員提供對其構建作業性能和共享構建系統負載的可視性。

在更改其配置文件的一行代碼後，Actuated 就可以運行所有CNCF 現有的GitHub Actions 運行器，在某些情況下還需要粘貼一些代碼片段——這些更改的實施時間不到五分鐘。這些更改使GitHub 託管項目能夠指向Actuated 在Ampere Altra 處理器上的微虛擬機驅動環境以進行其構建作業。

公平的競爭環境

到2023 年初，對於想要將Arm64 完全集成到其持續集成流程中的GitHub 託管項目，幾乎沒有選擇。通過這項倡議，利用Actuated 的創新軟件解決方案和Equinix 託管的Ampere CPU，降低了CNCF 項目開始實現ARM64 和x86 支持一致性的門檻。

包括etcd、containerd、Open Telemetry、Falco 等在內的關鍵雲原生項目能夠推進其對ARM64 的支持，加快其在原生Arm64 基礎設施上的CI 運行速度，並支持越來越多的用戶利用雲中的Arm64 計算。

在這個試點項目結束時，開發人員的選擇數量大大增加。 CNCF 現在為其項目提供了在OCI 上的託管Kubernetes 集群上運行GitHub Actions 作業的能力，使用Ampere 驅動的實例和GitHub 項目Actions Runner Controller，並且隨著GitHub 添加了託管的Arm64 運行器，項目更容易支持這種快速增長且令人興奮的雲原生應用程序架構。

以上是CNCF觸發了ARM64和X86的平台平等突破的詳細內容。更多資訊請關注PHP中文網其他相關文章！