Arm64 架構(gòu)開源軟件的CI/CD 難題與解決方案

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

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

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

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

Actuated 平臺的助力

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

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

實施與成果

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

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

GitHub Actions 的Arm64 自託管運(yùn)行器

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

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

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

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

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

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

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

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

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

差距現(xiàn)象

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

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

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

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

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

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

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

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

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

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

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

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

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