werf是我们的开源GitOps CLI实用程序，用于构建应用程序并将其交付给Kubernetes。如所承诺的，v1.0的发布标志着开始向werf添加新功能并修订熟悉的方法的开始。现在，我们很高兴发布v1.1，这是werf 收集器发展和未来的一大进步。该版本当前在1.1 ea通道中可用。该发行版的基础是舞台存储的新架构以及两个收集器（针对Stapel和Dockerfile）的工作优化。新的存储体系结构为在多个主机上实现分布式程序集和在单个主机上并行程序集提供了可能性。工作的优化包括在计算阶段签名的阶段摆脱不必要的计算，并将计算文件校验和的机制更改为更有效的机制。这种优化减少了使用werf的项目的平均构建时间。现在，当所有阶段都存在于阶段存储缓存中时，空闲构建现在真的非常快。在大多数情况下，重新启动程序集将比1秒内更快！这也适用于团队werf deploy和团队工作中验证阶段的程序werf run。此外，在此版本中，还提供了一种通过内容标记图像的策略- 基于内容的标记，默认情况下已启用该功能，并且这是唯一推荐使用的策略。让我们仔细看看werf v1.1中的关键创新，同时讨论未来的计划。werf v1.1中发生了什么变化？
新的阶段命名格式和缓存阶段选择算法
新的艺名生成规则。现在，每个阶段程序集都会生成一个唯一的阶段名称，该阶段名称由两部分组成：签名（如v1.0中所示）以及唯一的临时标识符。例如，舞台图像的全名可能看起来像这样：werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835...或一般形式：werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC这里：SIGNATURE -这是舞台签名，代表舞台内容的标识符，并取决于导致该内容的Git编辑历史；TIMESTAMP_MILLISEC -这保证了在组装新图像时生成的图像的唯一标识符。
从缓存中选择阶段的算法基于检查Git提交的关系：- Werf计算某个阶段的签名。
- 在阶段存储中，给定签名可以有多个阶段。Werf选择适合签名的所有阶段。
- 如果当前阶段在GIT中相关联（GIT-存档，用户在步骤c GIT中-补丁
install，beforeSetup，setup，或的git-最新补丁），然后WERF选择只涉及提交，这是当前的提交祖先（这些步骤对造成组件） - 在其余合适的阶段中，选择一个-按创建日期最早。
不同Git分支的阶段可以具有相同的签名。但是，即使签名匹配，werf也会阻止使用与这些分支之间的不同分支关联的缓存。→文档。用于在舞台存储中创建和保存舞台的新算法
如果在从缓存中选择阶段时werf找不到合适的阶段，则将启动组装新阶段的过程。请注意，几个过程（在一台或多台主机上）可以在大约同一时间开始组装同一阶段。当将新收集的图像存储在stage-storage中时，Werf使用stage-storage乐观锁定算法。因此，当新阶段的组装准备就绪时，werf会阻止阶段存储并仅在那里没有合适的图像的情况下将新收集的图像保存在那里（有关签名和其他参数-请参阅用于从缓存中选择阶段的新算法）。保证新挑选的图像具有唯一的标识，方法是TIMESTAMP_MILLISEC （请参阅新的舞台命名格式）。如果在stages-storage中找到了合适的图像，则werf将丢弃新收集的图像，并使用高速缓存中的图像。换句话说：第一个完成收集图像（最快）的过程将获得将其保存为阶段存储的权利（然后，该特定图像将用于所有装配体）。缓慢的组装过程将永远不会阻止较快的过程保存当前阶段的组装结果并继续进行下一个组装。→文档。改进的Dockerfile收集器性能
目前，从Dockerfile编译的映像的阶段管线包括一个阶段- dockerfile。在计算签名时，将考虑文件的校验和context，这将在汇编期间使用。在进行此改进之前，werf递归地遍历所有文件并接收校验和，以总结每个文件的上下文和模式。从v1.1开始，werf可以使用存储在Git存储库中的计算出的校验和。该算法基于git ls-tree。该算法.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（除非您明确指定其他标记方案）。→文档。单独的出版物也将致力于此功能。 更新（4月3日）：一篇详细的文章已经发表。记录级别
用户可以控制输出，设置日志记录级别以及使用调试信息。添加的选项--log-quiet，--log-verbose，--log-debug。默认情况下，输出包含最少的信息：
使用详细输出（--log-verbose）时，您可以跟踪werf的工作方式：
详细输出（--log-debug）除了werf的调试信息外，还包含所用库的日志。例如，您可以看到与Docker Registry的交互如何发生，还可以修复花费大量时间的地方：
未来的计划
注意！以下标记为v1.1的功能将在此版本中可用，其中许多功能将在不久的将来提供。使用multiwerf时，更新将通过自动更新进行。这些功能不会影响v1.1功能的稳定部分；其外观将不需要用户手动干预现有配置。全面支持各种Docker Registry实现（NEW）
目的是在使用werf时，用户应使用不受限制的任意实现。迄今为止，我们已经确定了以下将保证全面支持的解决方案：- 默认值（库/注册表）*，
- AWS ECR，
- 天蓝色*，
- Docker中心
- GCR *，
- Github软件包
- GitLab注册中心*，
- 港口 *，
- 码头。
星号表示werf当前完全支持的解决方案。剩下的就是支持，但是有局限性。可以区分两个主要问题：- 某些解决方案不支持使用Docker Registry API删除标签，后者不允许用户使用werf中实现的自动清理。适用于AWS ECR，Docker Hub和GitHub软件包。
- 有些解决方案不支持所谓的嵌套存储库（Docker Hub，GitHub Packages和Quay）或支持，但是用户必须使用UI或API（AWS ECR）手动创建它们。
我们将使用解决方案的本机API解决这些以及其他问题。该任务还包括用每个测试覆盖整个werf周期。分布式图像组合（↑）
目前，werf v1.0和v1.1只能在一个专用主机上使用，以在Kubernetes中组装和发布映像以及部署应用程序。为了打开werf分布式工作的可能性，当在多个任意主机上启动Kubernetes中应用程序的组装和部署并且这些主机未在程序集之间保持其状态（临时运行器）时，需要werf来实现使用Docker Registry作为阶段存储库的可能性。以前，当werf项目仍称为dapp时，它就有这样的机会。但是，在werf中实现此功能时，我们遇到了许多必须考虑的问题。注意。此功能并不意味着Kubernetes Pod内的收集器会工作，因为 为此，请摆脱对本地Docker服务器的依赖（在Kubernetes窗格中，无法访问本地Docker服务器，因为进程本身在容器中运行，并且werf不支持也不支持使用网络上的Docker服务器）。对Kubernetes中工作的支持将单独实施。官方GitHub Actions支持（NEW）
包括werf文档（参考和指南部分），以及用于werf的官方GitHub Action。此外，它将允许werf在短暂的跑步者上工作。用户与CI系统交互的机制将基于在请求请求上放置标签以启动某些操作来构建/推出应用程序。使用werf开发和部署本地应用程序（↓）
主要目标是实现一个统一的配置，以开箱即用地在本地和生产环境中部署应用程序，而无需复杂的操作。Werf还需要一种操作模式，在该模式下，可以方便地编辑应用程序代码并立即从工作的应用程序接收反馈以进行调试。新的清洗算法（NEW）
在当前版本的werf v1.1中，该过程cleanup未提供用于基于内容的标记方案的清理图像-这些图像将累积。另外，在当前版本的werf（v1.0和v1.1）中，对于标记方案发布的图像使用了不同的清理策略：Git分支，Git标记或Git提交。根据Git中的提交历史，为所有标记方案发明了一种新的统一图像清除算法：- 对于每个git HEAD（分支和标签），最多存储与N2个最后提交关联的N1个图像。
- 对于每个git HEAD（分支和标签），最多存储与N2个最后提交关联的N1个图像阶段。
- , - Kubernetes ( kube- namespace'; ).
- , , Helm-.
- , HEAD git (, HEAD ) Kubernetes Helm.
(↓)
当前版本的werf顺序收集所述的图像和工件werf.yaml。有必要并行化图像和伪像的独立阶段的组装过程，并提供一个方便且内容丰富的结论。*注意：由于增加了实施分布式程序集的优先级，因此更改了截止日期，这将增加水平缩放的更多功能，以及将werf与GitHub Actions结合使用。并行组装是下一步的优化步骤，在组装单个项目时提供垂直可伸缩性。切换至头盔3（↓）
它包括向新的Helm 3代码库的过渡，以及用于迁移现有安装的行之有效的便捷方法。*注意：向Helm 3的过渡不会为werf增加重要的功能，因为werf中已经实现了Helm 3的所有关键功能（三向合并和分of）。此外，werf 除了已指出的功能外，还具有其他功能。但是，此过渡仍在我们的计划中，并将予以实施。Jsonnet for Kubernetes配置说明（↓）
Werf将支持Jsonnet格式的Kubernetes的配置描述。同时，werf将继续与Helm兼容，并且可以选择描述格式。原因是事实上，按照许多人的说法，Go语言模式的入门门槛很高，而且这些模式的代码清晰度也受到影响。还考虑了用于实现Kubernetes配置描述系统的其他选项（例如Kustomize）。在Kubernetes内部工作（↓）
目的：使用Kubernetes中的运行程序来确保图像的组装和应用程序交付。那些。新图像的组装，其发布，清洁和部署可以直接从Kubernetes吊舱中进行。要实现此功能，您首先需要具有分布式构建映像的能力（请参见上文）。它还需要支持没有Docker服务器的构建操作模式（即类似Kaniko的构建或用户空间中的构建）。Werf不仅将通过Dockerfile支持Kubernetes的组装，还将通过带有增量重建和Ansible的Stapel构建器来支持在Kubernetes中进行组装。迈向开源开发
我们热爱我们的社区（GitHub，Telegram），我们希望越来越多的人来帮助使werf更好，了解我们的发展方向，并参与开发。最近，决定切换到GitHub项目板，以打开我们团队的工作流程。现在，您可以在以下方面查看近期计划以及正在进行的工作：有关问题的很多工作已经完成：- 删除无关的。
- 现有的都简化为单一格式，足够多的详细信息和详细信息。
- 添加了新的想法和建议问题。
如何启用版本v1.1
该版本是目前可用的通道1.1 EA（发布在稳定和稳固的渠道将显示为他们稳定，但EA本身已经是使用足够稳定，因为它通过传递阿尔法和贝塔渠道）。通过multiwerf通过以下方式激活它：source $(multiwerf use 1.1 ea)
werf COMMAND ...
结论
新的舞台存储架构和Stapel和Dockerfile收集器的优化收集器性能为在werf中实现分布式和并行程序集提供了可能性。这些功能很快就会出现在同一版本v1.1中，并且将通过自动更新机制（对于multiwerf用户）自动可用。在此版本中，添加了基于内容的标记策略，该策略成为默认策略。日志中还重新设计了基本命令：werf build，werf publish，werf deploy，werf dismiss，werf cleanup。下一步是添加分布式程序集。从v1.0开始，分布式程序集比并行程序集具有更高的优先级，因为它们增加了更多的werf价值：收集器的垂直缩放和对各种CI / CD系统中的临时收集器的支持，以及对GitHub Actions进行正式支持的能力。因此，并行装配的实施时间已经改变。但是，我们正在努力快速实现这两种可能性。关注新闻！并且不要忘了到我们的GitHub来创建一个问题，找到一个现有的问题并加上一个加号，创建一个PR，或者只是看项目的发展。聚苯乙烯
另请参阅我们的博客：