werf 中對 monorepo 和 multirepo 的支持以及 Docker Registry 與它有什麼關係

werf 中對 monorepo 和 multirepo 的支持以及 Docker Registry 與它有什麼關係

單一存儲庫的主題已經討論了不止一次,並且通常會引起非常活躍的爭議。 通過創建 韋爾夫 作為一個開源工具,旨在改進從 Git 到 Docker 鏡像(然後將它們交付給 Kubernetes)構建應用程序代碼的過程,我們不會過多考慮哪種選擇是最好的。 對我們來說,為不同意見的支持者提供一切必要的東西是首要的(當然,如果這不與常識相抵觸)。

werf 最近的 mono-repo 支持就是一個很好的例子。 但首先,讓我們弄清楚這種支持通常如何與使用 werf 相關,以及 Docker Registry 與它有什麼關係......

問題

讓我們想像一下這樣的情況。 公司有許多從事獨立項目的開發團隊。 大多數應用程序在 Kubernetes 上運行,因此是容器化的。 要存儲容器、鏡像,你需要一個註冊中心(registry)。 作為這樣的註冊中心,該公司使用具有單個帳戶的 Docker Hub COMPANY. 與大多數源代碼存儲系統類似, Docker Hub 不允許嵌套的存儲庫層次結構, 例如 COMPANY/PROJECT/IMAGE. 在那種情況下……如何在不為每個項目創建單獨帳戶的情況下將非單體應用程序存儲在具有此限制的註冊表中?

werf 中對 monorepo 和 multirepo 的支持以及 Docker Registry 與它有什麼關係

也許,所描述的情況對於第一手資料的人來說是熟悉的,但讓我們考慮一下一般組織應用程序存儲的問題,即沒有參考上面的例子和 Docker Hub。

解決方案

如果應用 整體的,出現在一張圖片中,那麼沒有問題,我們只需將圖片保存到項目的容器註冊表中。

當應用程序呈現為多個組件時, 微服務,那麼就需要某種方法。 以包含兩個圖像的典型 Web 應用程序為例: frontend и backend - 可能的選項是:

  1. 將圖像存儲在單獨的嵌套存儲庫中:

    werf 中對 monorepo 和 multirepo 的支持以及 Docker Registry 與它有什麼關係

  2. 把所有的東西都放在一個倉庫裡,考慮一下標籤中的鏡像名稱,例如,如下:

    werf 中對 monorepo 和 multirepo 的支持以及 Docker Registry 與它有什麼關係

NB:實際上,還有另一種選擇可以保存在不同的存儲庫中, PROJECT-frontend и PROJECT-backend, 但我們不會考慮它,因為用戶之間的支持、組織和權利分配的複雜性。

支持

最初,werf 僅限於嵌套存儲庫——幸運的是,大多數註冊表都支持此功能。 從版本開始 v1.0.4-alpha.3, 添加了與註冊表的工作,其中 不支持嵌套,而 Docker Hub 就是其中之一。 從那時起,用戶可以選擇如何存儲應用程序圖像。

可根據選項實施 --images-repo-mode=multirepo|monorepo (默認 multirepo, IE。 存儲在嵌套存儲庫中)。 它定義了將圖像存儲在註冊表中的模式。 使用基本命令時選擇所需的模式就足夠了,其他一切都將保持不變。

因為可以設置大多數 werf 選項 環境變量,在CI/CD系統中,存儲方式通常很容易為整個項目全局設置。 例如, 在 GitLab 的情況下 只需在項目設置中添加一個環境變量: 設置 -> CI / CD -> 變量: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

如果我們談論發布圖像和推出應用程序(您可以在相關文檔文章中詳細閱讀這些過程: 發布過程 и 部署流程),則模式僅決定您可以使用的圖像模板。

細節決定成敗

添加新存儲方式的區別和主要難點在於清理註冊表的過程 (對於 werf 支持的清除功能,請參見 清洗過程).

清理時,werf 會考慮 Kubernetes 集群中使用的圖像,以及用戶配置的策略。 策略是根據標籤劃分成策略的。 目前支持的策略:

  1. 由 Git 原語鏈接的 3 種策略,例如標記、分支和提交;
  2. 1 任意自定義標籤的策略。

我們在發布圖像時將有關標籤策略的信息保存在最終圖像的標籤中。 意義本身就是所謂的 元標記 - 需要應用一些政策。 例如,當從 Git 存儲庫中刪除一個分支或標籤時,刪除相關的邏輯是合乎邏輯的 沒用過 來自註冊表的圖像,這是我們政策的一部分。

當保存在一個存儲庫中時(monorepo), 在圖片標籤中,除了meta標籤外,還可以存儲圖片的名稱: PROJECT:frontend-META-TAG. 為了將它們分開,我們沒有引入任何具體的分隔符,只是在發佈時簡單地在最終圖像的標籤中添加了必要的值。

NB:如果您有興趣查看 werf 源代碼中描述的所有內容,那麼起點可以是 公關1684的.

在這篇文章中,我們不會更多地關注我們方法的問題和理由:關於標記策略、在標籤中存儲數據以及整個發布過程——所有這些在 Dmitry Stolyarov 最近的一份報告中都有詳細描述:“werf 是我們在 Kubernetes 中用於 CI/CD 的工具“。

總結

缺乏對未嵌套註冊表的支持並不是我們或我們所知的 werf 用戶的阻礙因素——畢竟,您總是可以提出一個單獨的圖像註冊表(或切換到谷歌云中的條件容器註冊表)......但是,為了使該工具在更廣泛的 DevOps 社區中更加方便,取消這樣的限制似乎是合乎邏輯的。 實施它,我們面臨的主要困難是重構容器註冊表清理機制。 現在一切就緒,很高興意識到它對某些人來說變得更容易了,我們(作為項目的主要開發人員)在進一步支持此功能方面不會有任何明顯的困難。

和我們在一起,我們很快就會告訴你其他的創新 韋爾夫!

聚苯乙烯

另請閱讀我們的博客:

來源: www.habr.com

添加評論