在werf中支持monorepo和multirepo,Docker Registry与它有什么关系?



单一存储库的主题已被讨论了不止一次,并且通常引起非常积极的辩论。 创建werf作为开放源代码工具,旨在改善从Git到Docker映像的应用程序代码的编译过程(以及随后将其交付给Kubernetes的过程),我们没有考虑哪个选择更好。 对于我们来说,为不同意见的支持者提供必要的一切都是首要的(当然,如果这不违背常识)。

最近在werf中对mono-repo的支持就是一个很好的例子。 但是首先,让我们看看这种支持通常与werf的使用相关联,以及Docker Registry与它有何关系...

发行


想象一下这种情况。 公司拥有许多参与独立项目的开发团队。 大多数应用程序都在Kubernetes上运行,因此是容器化的。 要存储容器,图像,需要注册表。 该公司将Docker Hub与单个COMPANY帐户一起用作注册表。 与大多数源代码存储系统类似, Docker Hub不允许您创建嵌套的存储库层次结构,例如COMPANY/PROJECT/IMAGE 。 在这种情况下...如何在不限制每个项目的情况下将非单一应用程序保留在注册表中而又没有此单独帐户的情况?



所描述的情况也许是第一手就很熟悉的人,但是让我们考虑一下组织应用程序存储的一般问题,即 无需参考上面的示例和Docker Hub。

解决方案


如果应用程序是整体式的 ,则仅包含一个图像,那么就没有问题了,我们只需将图像保存在项目存储库中即可。

当应用程序以多个组件( 微服务)的形式呈现时,需要选择一种特定的方法。 以包含两个图像( frontendbackend的典型Web应用程序为例,可能的选项如下:

  1. 将图像存储在单独的嵌套存储库中:

  2. 将所有内容存储在一个存储库中,并将图像名称带入标签,例如,如下所示:


注意 :实际上,仍然可以选择将PROJECT-frontendPROJECT-backend存储在各种存储库中,但是由于用户之间的支持,组织和权利分配的复杂性,我们不考虑使用它。

Werf支持


最初,werf仅限于嵌套存储库-幸运的是,大多数注册管理机构都支持此功能。 从v1.0.4-alpha.3版本开始,添加了不支持嵌套的注册表,其中包括Docker Hub。 从这一刻起,用户可以选择如何存储应用程序图像。

可将实现作为选项--images-repo-mode=multirepo|monorepo (默认情况下为--images-repo-mode=multirepo|monorepo ,即存储在嵌套存储库中)的一部分提供。 它定义了将图像存储在注册表中的方式。 使用基本命令时选择所需的模式就足够了,其他所有内容都将保持不变。

由于大多数werf选项都可以使用环境变量设置,因此在CI / CD系统中,通常很容易在整个项目中全局设置存储模式。 例如,对于GitLab,只需在项目设置中添加环境变量: 设置-> CI / CD->变量: WERF_IMAGES_REPO_MODE: multirepo|monorepo

如果我们谈论发布图像和推出应用程序(您可以在文档的相应文章中了解更多有关这些过程的信息: 发布过程部署过程 ),那么该模式将独家确定可用于处理图像的模板。

魔鬼详细


添加新存储方法的区别和主要困难在于注册表清理过程中(有关werf支持的清理选项,请参阅清理过程

清理时,werf会考虑Kubernetes集群中使用的映像以及用户配置的策略。 策略基于将标签划分为策略。 当前支持的策略:

  1. 与Git原语相关的3种策略,例如标记,分支和提交;
  2. 自定义标签的1种策略。

在最终图像的标签中发布图像时,我们会保存有关标签策略的信息。 含义本身(即所谓的元标记 )对于某些策略的应用是必需的。 例如,当从Git存储库中删除分支或标记时,从注册表中删除相关的未使用映像是合乎逻辑的,这在我们的部分政策中有所涵盖。

当保存在一个存储库( monorepo )中时,除了meta标签之外,图像名称还可以存储在image标签中: PROJECT: frontend -META-TAG 。 为了分隔它们,我们没有引入任何特定的分隔符,而只是在发布时将必要的值添加到了最终图像的标签中。

注意 :如果您有兴趣查看werf源代码中描述的所有内容,那么PR 1684可以作为起点。

在本文中,我们将不再关注方法的问题和合理性:关于标记策略,标签中的数据存储以及整个发布过程— Dmitry Stolyarov在最近的一份报告中对此进行了详细描述:“ werf是我们用于CI / CD的工具。 Kubernetes 。“

总结


对于我们或我们熟悉的werf用户来说,缺少嵌套就缺少注册表支持并不是一个阻碍因素-您可以随时提出一个单独的图像注册表(或切换到Google Cloud中的条件容器注册表)...但是,删除此限制似乎合乎逻辑,以使该工具更方便广泛的DevOps社区。 在实施它时,我们在处理清理容器注册表的机制时面临主要困难。 现在一切就绪,很高兴知道对某人来说变得更容易了,我们(作为项目的主要开发人员)在进一步支持此功能方面没有很大困难。

与我们在一起,很快我们将告诉您有关werf的其他创新!

聚苯乙烯


另请参阅我们的博客:

Source: https://habr.com/ru/post/zh-CN465131/


All Articles