Artifactory 倉庫架構和命名最佳實踐(下)

在上篇文章中,我們已經建立了基本的倉庫命名結構,在 JFrog Artifactory 中,倉庫管理的最佳實踐應該考慮三個因素:安全性,性能和可操作性。大多數情況下,這些因素跟你的團隊規模密切相關,在較小程度上跟倉庫成熟度等級的粒度劃分有一定的關係。


安全


Artifactory 允許通過包含/排除模式在單個文件夾甚至文件級別進行管理權限。一般來說,這裏的最佳做法是在倉庫級別管理權限。對於具有高度結構化的倉庫(如 Maven 和 RPM),可以在文件夾級別實現細粒度的控制。但是,對於管理員來說,這仍然可能過於複雜。尤其是關於那些需要細粒度的寫權限的高度結構化的倉庫來說。


當你的團隊之間沒有合作或沒有共享數據且彼此的軟件間不需要讀取權限時,就應該在相同的技術和成熟度級別設置不同的倉庫。你也可以根據寫入權限選擇提供不同的倉庫,並假設它們被聚合在虛擬倉庫中供讀取。這種基於寫入的倉庫的選擇在倉庫類型中非常重要,這些倉庫類型沒有被 Namespacing 劃分得很好,比如默認的 NuGet 行爲或者沒有設置好的的 Npm 倉庫。


性能


另一個應該考慮的是性能。儘管技術上的差異有所不同,但對於任何給定的技術來說,清楚知道倉庫中包的最大數量是有意義的。在 Maven 中,這往往是成千上萬的,並且更多地應該考慮 UI 界面的性能。然而在 Yum / Debian 中,這是數以千計的,而更多的是計算索引和索引文件大小,它們對客戶端的性能會有很大影響。


另一方面是清理策略。一個完全沒有清理策略的 Artifactory 服務器將會快速地增加存儲的使用率,而且一般來說,大部分並不是你真正需要存儲的東西。實施清理策略的機制有很多種。根據公司的業務需求,不同的項目可能有不同的策略。例如,Dev-sandbox-docker 倉庫可能有一個策略,該策略規定應刪除最近兩週內未下載的任何 Docker Tag。另一方面,受監管的行業可能會有監管要求,即任何在受監管的生產環境中的產物都必須保留十年。生命週期的各個階段之間的產物提升對於不同的倉庫是至關重要的。但是這些策略對於正在開發的應用程序來說也可能不一樣。


可操作性


當在特定環境中爲特定團隊管理工件倉庫時,其他基本可操作性注意事項均適用。一般而言,這些策略應該在倉庫級別進行處理,因此這將成爲選擇倉庫結構的決定性因素。


首先是一個相當簡單的:確定商業價值。如果你正在管理跨越公司內多個大型項目和業務單位的 Artifactory,除了上述考慮之外,你還需要確定這些不同的項目/單位如何使用 Artifactory 服務。這可能是爲了明確使用效益,或者僅僅是爲了追蹤哪些單位導致了什麼樣的成本。只要你想跟蹤公司內某個特定單位的使用情況並與其他組織分開使用,則這個單位應該有自己的倉庫,並根據命名規則進行細分,以便於識別。


此外,只要你不能成功的協調命名約定和目錄結構組織,那麼應該分倉庫進行管理。也就是說,一個大團隊如果沒有嚴格的規範,那將無法成功地管理像工件組的 ID 命名約定,那麼最好給他們單獨的倉庫,並且設置一個最大存儲的限制。一般而言,寫入權限,甚至更多的刪除權限,應該具有合理的特定性,以防止團隊干擾彼此的工作。一般而言,刪除權限只應提供給非策略清理之外的一個非常小的組(請參閱上述性能部分的清理策略討論)。


考慮到這一切,管理員通常更喜歡更少的倉庫。倉庫管理流程的自動化程度越高,其實際影響就越小。例如,在一個強大的 DevOps 環境中,你可能會遇到一種情況,即每一個測試都可以被看作是一種提升。雖然對於每個測試使用 Promotion API 可能會更好,但是對於幾十個測試中的每一個都有一個倉庫是沒有意義的,而是應該通過屬性跟蹤這些結果,併爲主要控制點保留單獨的倉庫。


最佳實踐案例


下面總結了各種倉庫類型的最佳實踐命名約定的示例:


1. 本地倉庫


team-tech-maturity-locator

 

例子:


  • tigerteam-docker-dev-local

  • tigerteam-docker-release-local



2. 遠程倉庫


例子:


  • tiger-mvn-release-boston

  • jcenter-remote



3. 虛擬倉庫


<team>-<tech>-<maturity>

 

例子:


  • tiger-docker-dev

  • tiger-docker-prod



4. 分發倉庫


例子:


  • artifactorypro-product-jfrog-dist

  • examples-jfrogtraining-dist



總結


管理倉庫並選擇命名約定是 JFrog Artifactory 管理員需要做出的第一個也是最重要的決定之一。儘管虛擬倉庫的使用可以在以後進行更改,但最好先選擇一個命名約定。


本文針對倉庫結構和命名約定總結了最佳實踐經驗,以幫助你回答以下問題:“我需要多少倉庫?”。它提供了一個由四部分組成的約定<team> - <tech> - <maturity> - <locator>,它可以用作命名和組織結構的基本最佳實踐指南。使用這個建議的慣例,大多數組織問題變得相當清楚。


本文中描述的約定將允許你在全局拓撲中擴展你的 Artifactory。它將支持大型企業的 DevOps 平臺建設,爲衆多不同團隊和項目的數千名開發人員提供服務。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章