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

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

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

這些組件的產(chǎn)品經(jīng)理也需要滿足這些要求，此外還有至少兩點：

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

Actuated 平臺的助力

開源開發(fā)者Alex Ellis 與Ampere 和基礎設施提供商Equinix 合作，為雲(yún)原生軟件生態(tài)系統(tǒng)中一些最關鍵的開源項目提供了Actuated CI/CD 平臺。

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

實施與成果

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

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

GitHub Actions 的Arm64 自託管運行器

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

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

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

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

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

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

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

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

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

差距現(xiàn)象

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

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

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

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

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

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

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

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

公平的競爭環(huán)境

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

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

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

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