關注世界領先 DevOps 平台 JFrog
近年來，混合雲、多雲正逐漸成為企業用雲的主流模式。據 IBM 的調查報告顯示，僅截至2021年，采用混合雲、多雲戰略的企業就已經接近80%。混合雲、多雲戰略的确能夠增加企業資源配置的靈活性，但也給持續傳遞帶來了更大的挑戰。在軟體釋出頻率持續增長趨勢下，如何将版本快速分發到多個環境中去，成為令不少開發者頭疼的問題。
近日，亞馬遜雲科技聯合 JFrog 舉行了《DevOps 實踐：混合雲模式下軟體單一可信源的建設方法》為主題的 Tech Talk，JFrog （中國）技術總監王青與大家分享了解決該問題的獨特思路。
1. 現有的制品庫正在阻礙你的快速釋出
IDC 研究報告顯示，到2024年全球 APP 數量将達到 520M；2025年後，超過60%的企業每天都将進行版本釋出，甚至更快。在如此之快的版本建構需求下，現有的統一代碼庫、統一持續內建再進行不同環境分發的制品管理方式往往存在一定的局限性。
這些局限性主要展現在研發團隊面臨着 Nexus 開源版私服當機無人維護、開源元件漏洞被引入等問題；測試團隊無法清晰地了解版本品質資訊，同時測試報告也無法準确進行關聯；運維團隊在面臨當機問題時候缺乏商業技術支援，缺乏高可用和容災；在此管理模式下，一旦發生問題，安全團隊很難快速發現漏洞、對問題進行定位，是以也很難做到及時響應。
面對諸多問題，王青提出，建立軟體單一可信源對于企業來說是至關重要的。單一可信源是指企業内部單一的，合規地存放所有軟體的倉庫，包括 war 包、Docker 鏡像、zip 包等，以及第三方開源元件或者商業軟體的授權版本和軟體物料清單（SBOM）。
2. 為什麼要建立軟體單一可信源
建立唯一可信源的制品管理流程後，隻需要不斷将版本從開發流水線的 CI 伺服器裡建立晉級，一路晉級到生産環境的制品庫，再由生産環境的制品庫推送到多雲環境中去。對于大型企業來說，通常會有多種雲的技術棧，多種語言包都需要建構。通過制品庫統一建構，把版本統一上傳到 DEV 本地倉庫做本地的內建測試，當開發者測試沒有問題後，版本會晉級到 Test 倉庫供測試來測，此後版本會進入性能和穩定性檢測的環境，最終進入到生産環境的倉庫中。
按照這種制品的晉級流程去建設會大大提高軟體傳遞的效率。JFrog Artifactory 遵循的正是這樣一套流程。它是支援30種語言包的制品倉庫，Maven 包、NPM 包、Docker 鏡像、ZIP 檔案等多種通用檔案都可以進行存儲。
據王青介紹，JFrog 曾有一個國内大型手機制造商客戶，每天單叢集資料增長 20TB 左右，共有10多個叢集。JFrog 和他們一起在研發測試區搭建了本地 Artifactory 叢集，支援高并發的上傳和下載下傳，通過5-6個 Artifactory 節點來作為高可用叢集提供服務。
這種方案相比傳統的需要搭建一個 Nexus 開源版作為 Docker 鏡像，再搭建一個 Nexus 開源版作為 Maven 倉庫，Maven 倉庫可能還要管 NPM 的技術方案，這種方案投入人力成本更低且能夠提供更高的可用性。對于有多套環境的大型企業來說，軟體單一可信源建設的優勢就更加明顯了，因為多套環境維護成本會線性增長。
3. 混合雲模式下單一可信源的建設方法
軟體單一可信源的建設有助于企業降本增效，提升軟體制品的建構速度，那麼該如何建構軟體單一可信源呢？王青談到了一種差別于傳統開源方案的獨特方式。
在公司建設軟體倉庫的單一可信源時，最基本的是要保證它的高可用性。高可用有兩層含義：一是零當機，二是能夠支援高并發的負載。Artifactory 對于生産環境的部署，天然的支援私有雲和公有雲的一鍵部署，并且提供實時推送功能。相比較來說，Nexus 開源版是沒有推送功能的，是以也就沒辦法實作将本地建構的版本推送到多個私有雲或者多個公有雲上去。
假設公司的制品數量級已經達到百萬級甚至是千萬級，該如何應對這種大規模的讀取和寫入呢？JFrog 引入了兩個概念，一個是讀緩存層，一個是寫緩存層。這是差別于開源方案的一個很重要的産品功能設計點。Nexus 開源版是沒有緩存這個概念的，拉取的時候會去本地查詢檔案存在與否，這樣的問題是，當服務讀取作業系統檔案的時候，作業系統檔案是要耗時的，如果檔案塊在實體上存儲的力度比較分散，實際查詢效率會很低。
JFrog 在 Artifactory 伺服器上添加了一個叫 SSD 的緩存層，通過這個緩存層能夠快速讀取一些熱資料傳回給使用者。這個設計遵循的是 LRU 的算法，會保持 500G 左右的熱資料。除了讀緩存，JFrog 還引入了寫緩存。因為在将檔案上傳到伺服器上的時候，是先上傳到伺服器的某一個目錄，再通過一個程序寫到存儲裡，有了這個設計，隻要把檔案成功上傳到目錄即可建立成功，大大減少了用戶端傳回的請求時間, 而後端隻需建立一個異步任務，把檔案存儲進去，再把存儲目錄删掉即可。為了減少存儲的壓力，JFrog 還設計了備援同步，能夠讓使用者去配置備援數量，如上傳一個檔案時使用者要備援兩份，Artifactory 就會把檔案從 a 備援到 b 去，通過輪詢拿到熱資料傳回，進而提高效率。
綜上所述，高可用性是建立軟體單一可信源的基石。尤其是當客戶的資料量超過幾千萬時，如果都儲存在存儲中，查找的效率就會非常低。在存儲方面，JFrog 也進行了優化。GIT 檔案存儲是按照 checksum 的前兩位，以目錄的方式去存儲每一個檔案，是以 GIT 能高效地存儲代碼倉庫裡面上百萬、上千萬的檔案，這依托的是檔案索引的設計。當使用者尋找某一個檔案的時候，它會先以索引的方式定位到檔案在哪個目錄，在目錄裡面再去辨識。相當于建立了樹狀的結構，是以查詢效率會更高。當資料量增大後要提升效率肯定還是需要依賴資料結構，通過每種場景應用不同的資料結構提升效率。
完整的高可用服務能夠保證制品庫建設單一可信源，但可信性又該如何保證呢？讓制品庫變得可信就涉及到安全相關的問題。尤其在面對海外使用者時候，面臨的最大挑戰不是軟體釋出效率瓶頸，而是安全問題，特别是部署到公有雲上的時候。在整個程式的冰山上，代碼就是冰山一角，底層有很大的 API 接口、依賴包，還有底層的基礎鏡像，下面會存在很多開源元件，其中客戶提到最多的就是漏洞爆發之後哪些應用将受到什麼樣的影響，應該修複到哪個版本？
對于上述問題王青認為，現在開源軟體比較多，但真正用起來會存在很多問題。如惡意依賴注入、注入惡意二進制或者代碼實作勒索等。為此，JFrog 的産品中特别增加了漏洞掃描的功能。當發現漏洞時，JFrog 是如何快速定位，然後下線這些服務的更新版本的呢？這需要精準定位的能力。
傳統的掃描會掃出很多漏洞，缺乏跨語言的依賴，比如無法定位到哪一個 Docker 鏡像被 Log4j 污染。JFrog 通過 SCA（software component analysis）來進行漏洞掃描，此外還對某些語言包如 Docker 鏡像進行密鑰探測，包括上下文分析。掃描出漏洞之後，傳統的廠商隻會告訴使用者有哪幾個漏洞，而 JFrog 則會告訴你每個漏洞的評分分别是什麼以及該漏洞的影響範圍。
單一可信源建設要做的不僅僅是掃描，還有治理，對于掃描出的漏洞進行跟蹤并精細化管理；安全部門要做的是定義規則，定義政策。公司内部一般有兩個概念，一個是漏洞，一個是違規，漏洞是事實，而違規是公司政策。安全部門要定義哪些級别的版本屬于違規，而開發者隻需要去修複違規就可以了，不用管所有的漏洞。
是以，Artifactory 設計了兩個次元的管理，一個是根據團隊或者軟體版本進行掃描，定位到某一個團隊。另一個是按照部門去修複，不同部門的安全政策可能是不一樣的，是以可以根據不同部門建立 Project 進行掃描和漏洞修複，進而實作有效的漏洞治理。
以上介紹的是在單一私有雲或者公有雲環境下的處理方式，如果要把私有雲的制品同步到公有雲上，JFrog 是如何做的呢？
這就涉及到 JFrog 另一個功能——制品的雙向同步。通過雙向同步能力，借助于亞馬遜雲科技的 PrivateLink 開設私有網絡。隻要開了 Link 之後，私有雲的制品倉庫就能直接推到雲上的 VPC 上去，自動複制到不同的 Region，實作制品液體般的流動。
除制品的雙向同步之外，JFrog 還提供統一認證的功能，使雲上雲下保持一緻。通常來說，雲上的使用者和雲下的使用者的賬号是不能複用的，比如雲上用賬号 a 登入，雲下就要用賬号 b，這樣使用者就需要維護兩套賬号，導緻用的人越多，賬号維護的成本就越高。但是，Artifactory 實作了聯合身份認證。隻要在叢集 a 建立使用者，它會自動把使用者資訊同步到叢集的每一個節點，使用者在雲下怎麼登入，在雲上按照同樣的方式登入即可。這個功能特别适合多雲環境進行軟體制品的傳輸，能夠極大節省公網帶寬，提高釋出速度，降低成本。
4. 輕松建立可信釋出流程的實踐案例
某大型跨國銀行，需要進行雲遷移，實作應用上雲。他們采用的方案是本地的關鍵資料庫加上存儲，到雲上直接使用雲資料庫加上 Amazon S3 雲存儲，應用直接遷移到 Amazon EKS，Amazon EKS 的使用極大的降低了運維成本。在整個資料遷移的過程中，JFrog 有專門的工具把本地的 Artifactory 制品通過一個腳本直接傳到雲上的 Artifactory，這種持續的傳輸實作了業務的零中斷，并能将建構速度提升了30-40%。
軟體制品從本地推到雲端會用到一個叫 Internal Gateway 的 VPC 。亞馬遜雲科技在2022年 re:Invent 上最新釋出的一款名為 Amazon CodeCatalyst 的 DevOps 端到端工具，包含需求設計、issue 管理、建構等一系列功能，使用者可以通過 Amazon CodeCatalyst 進行建構，建構完成後把版本上傳到某個 Amazon ECS , 并且能夠和 Artifactory 制品庫進行內建。
內建方式如上圖所示，使用者的代碼 Commit 後到 GIT 倉庫就能觸發 Amazon CodeCatalyst 建構，建構時通過 JFrog 的 CLI 指令行工具連接配接到 Artifactory 做遠端依賴 PublicRepo 的下載下傳，下載下傳時會觸發漏洞掃描，掃描完成後進行晉級，分發到多種雲，用 IoT 裝置進行更新。整個編排過程由 Amazon CodeCatalyst 進行負責，并能夠和 Artifactory 無縫內建，進而實作輕松地規劃、開發、寫作、建構和傳遞應用程式。
關于捷蛙
公司成立于2008年，在美國、以色列、法國、西班牙，以及中國北京市擁有超過200名員工。捷蛙擁有5000多個付費客戶，其中知名公司包括如騰訊、谷歌、思科、Netflix、亞馬遜、蘋果等。關注捷蛙，感受原汁原味的矽谷技術！我們不僅僅提供最優秀的産品，也提供最優秀的持續傳遞平台的解決方案。
關于曉數神州
曉數神州-堅持以“敬業、協作、追求卓越”為宗旨，為客戶提供專業的服務和解決方案。目前公司有兩個團隊組成，一個是IT基礎設施團隊，以Radware産品為中心，提供相關周邊網絡産品，包括科來、ZDNS等一系列優質産品，提供專業解決方案；另一個是針對DevOps平台，緻力于推動企業數字化轉型，為使用者提供全生命周期管理的産品以及專業化服務，包括JFrog、極狐Gitlab、維普等優質産品。
欲知詳情，請通路：www.xdatatech.com