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

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

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

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

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

Actuated 平臺(tái)的助力

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

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

實(shí)施與成果

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

這項(xiàng)舉措的成功促使 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ù)了軟件項(xiàng)目托管的主導(dǎo)地位。GitHub 托管項(xiàng)目生成持續(xù)集成構(gòu)建和發(fā)布最流行的方式是使用平臺(tái)內(nèi)置的 CI 工具集 GitHub Actions。GitHub Actions CI/CD 平臺(tái)最重要的作用是自動(dòng)化軟件開發(fā)流程。

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

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

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

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

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

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

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

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

差距現(xiàn)象

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

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

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

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

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

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

為了邁向 x86 和 Arm64 之間平臺(tái)一致性的第一步，Ampere 尋求了 Alex Ellis 的幫助，他是名為 Actuated 的服務(wù)的創(chuàng)建者。這是一個(gè)在安全的、隔離的微虛擬機(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)行器，在某些情況下還需要粘貼一些代碼片段——這些更改的實(shí)施時(shí)間不到五分鐘。這些更改使 GitHub 托管項(xiàng)目能夠指向 Actuated 在 Ampere Altra 處理器上的微虛擬機(jī)驅(qū)動(dòng)環(huán)境以進(jìn)行其構(gòu)建作業(yè)。

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

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

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

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

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