是我们的开源 GitOps CLI 实用程序，用于构建应用程序并将其交付到 Kubernetes。 按照承诺， 标志着向werf添加新功能和修改传统方法的开始。 现在我们很高兴推出 v1.1 版本，这是开发中的一大步，也是未来的基础 集电极 韦尔夫。 该版本目前可用 .
该版本的基础是新的阶段存储架构和两个收集器（针对 Stapel 和 Dockerfile）工作的优化。 新的存储架构开启了从多个主机实现分布式程序集以及在同一主机上实现并行程序集的可能性。
工作的优化包括在计算阶段签名阶段消除不必要的计算，并将计算文件校验和的机制改为更有效的机制。 此优化减少了使用 werf 构建项目的平均时间。 当所有阶段都存在于缓存中时，进行空闲构建 阶段存储，现在速度真的很快。 大多数情况下，重新启动构建将花费不到 1 秒的时间！ 这也适用于验证团队工作过程中各个阶段的程序。 werf deploy и werf run.
此外，在此版本中，还出现了按内容标记图像的策略 - 基于内容的标签，现在默认启用，也是唯一推荐的。
让我们仔细看看werf v1.1的关键创新，同时告诉您未来的计划。
werf v1.1 发生了什么变化？
用于从缓存中选择阶段的新阶段命名格式和算法
新的艺名生成规则。 现在，每个阶段构建都会生成一个唯一的阶段名称，该名称由两部分组成：签名（与 v2 中一样）加上唯一的临时标识符。
例如，完整的舞台图像名称可能如下所示：
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...或者一般来说：
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
在这里：
-
SIGNATURE是一个阶段签名，它代表阶段内容的标识符，并且取决于导致该内容的 Git 编辑历史记录； -
TIMESTAMP_MILLISEC是在构建新图像时生成的有保证的唯一图像标识符。
从缓存中选择阶段的算法基于检查 Git 提交的关系：
- Werf 计算某个阶段的签名。
- В 阶段存储 对于给定的签名可能有几个阶段。 Werf 选择与签名匹配的所有阶段。
- 如果当前阶段链接到 Git（git-archive，带有 Git 补丁的自定义阶段：
install,beforeSetup,setup; 或 git-latest-patch），然后 werf 仅选择与作为当前提交（为其调用构建）的祖先的提交关联的那些阶段。 - 从剩余的合适阶段中选择一个 - 按创建日期最旧的阶段。
不同 Git 分支的阶段可以具有相同的签名。 但 werf 将阻止与不同分支关联的缓存在这些分支之间使用，即使签名匹配。
.
在舞台存储中创建和保存舞台的新算法
如果在从缓存中选择阶段时，werf没有找到合适的阶段，则启动组装新阶段的过程。
请注意，多个进程（在一台或多台主机上）可以大约在同一时间开始构建同一阶段。 Werf 使用乐观阻塞算法 阶段存储 将新收集的图像保存在 阶段存储。 这样，当新阶段构建准备就绪时，werf 就会阻塞 阶段存储 仅当合适的图像不再存在时才保存新收集的图像 （通过签名和其他参数 - 请参阅从缓存中选择阶段的新算法）.
保证新组装的图像具有唯一的标识符 TIMESTAMP_MILLISEC （参见新的阶段命名格式）。 万一在 阶段存储 将找到合适的图像，werf 将丢弃新编译的图像并使用缓存中的图像。
换句话说：完成构建图像的第一个进程（最快的进程）将有权将其存储在阶段存储中（然后这个单个图像将用于所有构建）。 缓慢的构建过程永远不会阻止更快的过程保存当前阶段的构建结果并继续进行下一个构建。
.
改进了 Dockerfile 构建器的性能
目前，从 Dockerfile 构建的映像的阶段管道由一个阶段组成 - dockerfile。 计算签名时，计算文件的校验和 context，这将在组装过程中使用。 在此改进之前，werf 递归地遍历所有文件，并通过对每个文件的上下文和模式求和来获得校验和。 从 v1.1 开始，werf 可以使用存储在 Git 存储库中的计算校验和。
该算法基于 。 该算法考虑了中的记录 .dockerignore 并仅在必要时递归遍历文件树。 因此，我们已经与读取文件系统以及算法对大小的依赖解耦了 context 并不重要。
该算法还会检查未跟踪的文件，并在必要时将其纳入校验和中。
改进了导入文件时的性能
werf v1.1 的版本在以下情况下使用 rsync 服务器： 。 以前，导入是使用主机系统的目录挂载分两步完成的。
macOS 上的导入性能不再受到 Docker 卷的限制，并且导入在与 Linux 和 Windows 相同的时间内完成。
基于内容的标记
Werf v1.1 支持所谓的按图像内容标记 - 基于内容的标签。 生成的 Docker 映像的标签取决于这些映像的内容。
运行命令时 werf publish --tags-by-stages-signature или werf ci-env --tagging-strategy=stages-signature 发布的所谓的图像 舞台签名 图像。 每张图像都标记有自己的该图像的各个阶段的签名，该签名是按照与每个阶段的常规签名相同的规则分别计算的，但它是图像的通用标识符。
图像阶段的签名取决于：
- 该图像的内容；
- 导致此内容的 Git 更改的历史。
Git 存储库始终具有不会更改图像文件内容的虚拟提交。 例如，仅包含注释的提交或合并提交，或者更改 Git 中不会导入到映像中的文件的提交。
当使用基于内容的标记时，即使镜像的内容没有改变，由于镜像名称的变化而导致 Kubernetes 中的应用程序 Pod 不必要重启的问题也得到了解决。 顺便说一句，这是阻止将一个应用程序的许多微服务存储在单个 Git 存储库中的原因之一。
此外，基于内容的标记是比在 Git 分支上标记更可靠的标记方法，因为生成的图像的内容不依赖于 CI 系统中用于组装同一分支的多个提交的管道的执行顺序。
这一点很重要: 从现在开始 阶段签名 - 唯一推荐的标记策略。 它将在命令中默认使用 werf ci-env （除非您明确指定不同的标记方案）。
。 还将有一份单独的出版物专门介绍此功能。 更新 （3 月 XNUMX 日）：详细文章 .
记录级别
用户现在有机会控制输出、设置日志记录级别并使用调试信息。 添加选项 --log-quiet, --log-verbose, --log-debug.
默认情况下，输出包含最少信息：
当使用详细输出时（--log-verbose）你可以看到 werf 是如何工作的：
详细输出（--log-debug），除了werf调试信息外，还包含使用过的库的日志。 例如，您可以查看与 Docker 注册表的交互是如何发生的，还可以记录花费大量时间的地方：
进一步的计划
警告！ 下面描述的选项已标记 v1.1 将在此版本中提供，其中许多将在不久的将来提供。 更新将通过自动更新进行 。 这些功能不会影响 v1.1 功能的稳定部分；它们的出现不需要用户手动干预现有配置。
完全支持各种 Docker 注册表实现（新）
- 版本：v1.1
- 日期：三月
目标是让用户在使用 werf 时不受限制地使用自定义实现。
目前，我们已经确定了以下一组解决方案，我们将保证全力支持：
- 默认（库/注册表）*，
- AWS ECR
- 天蓝色*,
- 码头工人中心
- GCR*，
- GitHub 包
- 亚搏体育appGitLab注册表*，
- 港口*，
- 码头。
目前 werf 完全支持的解决方案标有星号。 对于其他人来说，有支持，但有限制。
可以确定两个主要问题：
- 某些解决方案不支持使用 Docker 注册表 API 删除标签，从而阻止用户使用 werf 的自动清理功能。 对于 AWS ECR、Docker Hub 和 GitHub 包来说也是如此。
- 某些解决方案不支持所谓的嵌套存储库（Docker Hub、GitHub Packages 和 Quay），但用户必须使用 UI 或 API (AWS ECR) 手动创建它们。
我们将使用解决方案的本机 API 来解决这些问题和其他问题。 这项任务还包括覆盖造船操作的整个周期，并对每个周期进行测试。
分布式镜像构建 (↑)
- 版本：v1.2 v1.1（提高了实现该功能的优先级）
- 日期：三月至四月
目前，werf v1.0和v1.1只能在一台专用主机上使用，用于构建和发布镜像以及将应用程序部署到Kubernetes的操作。
为了开启 werf 分布式工作的可能性，当 Kubernetes 中的应用程序的构建和部署在多个任意主机上启动并且这些主机在构建之间（临时运行器）不保存其状态时，werf 需要实现使用以下功能的能力： Docker 注册表作为临时存储。
此前，当werf项目还叫dapp时，就有这样的机会。 然而，我们在 werf 中实现此功能时遇到了一些需要考虑的问题。
注意。 此功能不需要收集器在 Kubernetes Pod 内工作，因为为此，需要摆脱对本地 Docker 服务器的依赖（在 Kubernetes pod 中是无法访问本地 Docker 服务器的，因为进程本身是在容器中运行的，而 werf 不支持也不会支持）通过网络与 Docker 服务器一起工作）。 对运行 Kubernetes 的支持将单独实现。
对 GitHub Actions 的官方支持（新）
- 版本：v1.1
- 日期：三月
包括 werf 文档（部分 参考 и 指南），以及使用 werf 的官方 GitHub Action。
此外，它还允许 werf 处理临时运行器。
用户与 CI 系统交互的机制将基于在拉取请求上放置标签以启动某些操作来构建/推出应用程序。
使用werf本地开发和部署应用程序(↓)
- 版本：v1.1
- 日期：一月至二月
主要目标是实现用于在本地和生产中部署应用程序的单一统一配置，无需复杂的操作，开箱即用。
werf还需要有一种操作模式，可以方便地编辑应用程序代码并立即接收正在运行的应用程序的反馈以进行调试。
新的清洁算法（NEW）
- 版本：v1.1
- 日期：四月
在当前版本的werf v1.1中的程序 cleanup 基于内容的标记方案没有提供清理图像的规定 - 这些图像会累积。
此外，当前版本的 werf（v1.0 和 v1.1）对在标记方案下发布的图像使用不同的清理策略：Git 分支、Git 标记或 Git 提交。
发明了一种基于 Git 提交历史记录的新图像清理算法，该算法对所有标记方案进行统一：
- 为每个 git HEAD（分支和标签）保留与 N1 个最新提交相关联的 N2 个以上图像。
- 为每个 git HEAD（分支和标签）存储与 N1 个最新提交相关的 N2 个阶段图像。
- 存储任何 Kubernetes 集群资源中使用的所有映像（配置文件和命名空间的所有 kube 上下文都会被扫描；您可以使用特殊选项限制此行为）。
- 存储 Helm 版本中保存的资源配置清单中使用的所有图像。
- 如果某个镜像未与 git 中的任何 HEAD 关联（例如，因为相应的 HEAD 本身已被删除）并且未在 Kubernetes 集群和 Helm 版本中的任何清单中使用，则可以将其删除。
并行图像构建（↓）
- 版本：v1.1
- 日期：一月至二月 四月*
当前版本的 werf 收集中描述的图像和工件 werf.yaml，依次。 有必要并行化组装图像和工件的独立阶段的过程，并提供方便且信息丰富的输出。
* 注意：由于实现分布式组装的优先级增加，截止日期已发生变化，这将增加更多的水平扩展功能，以及将 werf 与 GitHub Actions 结合使用。 并行组装是下一个优化步骤，在组装一个项目时提供垂直可扩展性。
过渡到 Helm 3 (↓)
- 版本：v1.2
- 日期：二月至三月*
包括迁移到新的代码库 以及一种经过验证的、便捷的方式来迁移现有的安装。
* 注意：切换到 Helm 3 不会为 werf 添加重要功能，因为 Helm 3 的所有关键功能（3 路合并和无操作器）已在 werf 中实现。 此外，werf还有 除了那些指出的之外。 然而，这一转变仍在我们的计划中并将予以实施。
用于描述 Kubernetes 配置的 Jsonnet (↓)
- 版本：v1.2
- 日期： 一月至二月 四月至五月
Werf 将支持 Jsonnet 格式的 Kubernetes 配置描述。 同时，werf 将保持与 Helm 的兼容性，并且可以选择描述格式。
原因是很多人认为 Go 模板的入门门槛很高，而且这些模板代码的可理解性也受到影响。
引入其他 Kubernetes 配置描述系统（例如 Kustomize）的可能性也在考虑之中。
在 Kubernetes 内部工作 (↓)
- 版本：v1.2
- 日期： 四月至五月 五月至六月
目标：确保使用 Kubernetes 中的运行器构建镜像并交付应用程序。 那些。 可以直接从 Kubernetes Pod 构建、发布、清理和部署新镜像。
要实现这个能力，首先需要能够构建分布式镜像 （见上一点）.
它还需要支持构建器在没有 Docker 服务器的情况下的操作模式（即类似 Kaniko 的构建或在用户空间中构建）。
Werf 不仅支持使用 Dockerfile 在 Kubernetes 上进行构建，还支持使用具有增量重建功能的 Stapel 构建器和 Ansible。
迈向开放发展
我们热爱我们的社区（, ）并且我们希望越来越多的人帮助werf变得更好，了解我们前进的方向，并参与到开发中。
最近决定改用 为了揭示我们团队的工作流程。 现在您可以看到近期计划以及以下领域的当前工作：
- ;
- ;
- ;
- .
针对以下问题，我们做了很多工作：
- 删除了不相关的。
- 现有的内容被采用单一格式，并具有足够数量的细节和细节。
- 添加了有关想法和建议的新问题。
如何启用v1.1版本
该版本目前可用 （在频道中 稳定 и 坚如磐石 然而，随着稳定的发生，释放将会出现 ea 本身已经足够稳定可以使用，因为通过渠道 阿尔法 и 测试）。 活性 通过以下方式：
source $(multiwerf use 1.1 ea)
werf COMMAND ...结论
Stapel 和 Dockerfile 构建器的新阶段存储架构和构建器优化开启了在 werf 中实现分布式和并行构建的可能性。 这些功能很快就会出现在同一个 v1.1 版本中，并将通过自动更新机制自动可用（对于用户 ).
在这个版本中，添加了基于图像内容的标记策略—— 基于内容的标签，这已成为默认策略。 主命令日志也已重新设计： werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
下一个重要步骤是添加分布式程序集。 自 v1.0 以来，分布式构建已成为比并行构建更高的优先级，因为它们为 werf 增加了更多价值：构建器的垂直扩展和对各种 CI/CD 系统中的临时构建器的支持，以及为 GitHub Actions 提供官方支持的能力。 因此，并行装配的实施期限发生了变化。 然而，我们正在努力尽快实现这两种可能性。
关注新闻！ 并且不要忘记访问我们 要创建一个问题，找到一个现有的问题并添加一个加号，创建一个 PR，或者只是观察项目的开发。
PS
另请阅读我们的博客：
- «»
- «“;
- 关于werf创新的一系列注释：
- «“;
- «“;
- «“;
- «“。
来源： habr.com