werf 中对 monorepo 和 multirepo 的支持以及 Docker Registry 与它有什么关系

单一存储库的主题已经讨论了不止一次，并且通常会引起非常活跃的争议。 通过创建 韦尔夫 作为一个开源工具，旨在改进从 Git 到 Docker 镜像（然后将它们交付给 Kubernetes）构建应用程序代码的过程，我们不会过多考虑哪种选择是最好的。 对我们来说，为不同意见的支持者提供一切必要的东西是首要的（当然，如果这不与常识相抵触）。

werf 最近的 mono-repo 支持就是一个很好的例子。 但首先，让我们弄清楚这种支持通常如何与使用 werf 相关，以及 Docker Registry 与它有什么关系......

问题

让我们想象一下这样的情况。 公司有许多从事独立项目的开发团队。 大多数应用程序在 Kubernetes 上运行，因此是容器化的。 要存储容器、镜像，你需要一个注册中心（registry）。 作为这样的注册中心，该公司使用具有单个帐户的 Docker Hub COMPANY. 与大多数源代码存储系统类似， Docker Hub 不允许嵌套的存储库层次结构， 例如 COMPANY/PROJECT/IMAGE. 在那种情况下……如何在不为每个项目创建单独帐户的情况下将非单体应用程序存储在具有此限制的注册表中？

也许，所描述的情况对于第一手的人来说是熟悉的，但让我们考虑一下一般组织应用程序存储的问题，即没有参考上面的例子和 Docker Hub。

解决途径

如果申请 整体的，出现在一张图片中，那么没有问题，我们只需将图片保存到项目的容器注册表中。

当应用程序呈现为多个组件时， 微服务，那么就需要某种方法。 以包含两个图像的典型 Web 应用程序为例： frontend и backend - 可能的选项是：

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

   

2. 把所有的东西都放在一个仓库里，考虑一下标签中的镜像名称，例如，如下：

   

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 社区中更加方便，取消这样的限制似乎是合乎逻辑的。 实施它，我们面临的主要困难是重构容器注册表清理机制。 现在一切就绪，很高兴意识到它对某些人来说变得更容易了，我们（作为项目的主要开发人员）在进一步支持此功能方面不会有任何明显的困难。

和我们在一起，我们很快就会告诉你其他的创新 韦尔夫!

PS

另请阅读我们的博客：

• «您现在可以使用常规 Dockerfile 在 werf 中构建 Docker 镜像“;
• «werf - 我们在 Kubernetes 中的 CI / CD 工具（概述和视频报告）“。

来源： habr.com