werf是一个
开源的 GitOps CLI实用程序，用于构建应用程序并将其交付给Kubernetes。 werf支持使用Dockerfile或它自己的内置收集器（基于YAML语法，具有Ansible支持和基于Git的增量重建）来组装应用程序映像。 Helm兼容的配置格式用于交付应用程序。 应用程序代码，收集的图像的配置以及应用程序的部署配置都存储在一个Git存储库中。
期待已久的
稳定版本1.0是实用程序通过功能完成的基本版本
（第一个稳定版本的确切版本号是1.0.6） 。 在基本版本中，werf支持应用程序交付和维护的整个周期。 这包括组装应用程序映像，部署到Kubernetes以及清理未使用的映像。
重要的是，在1.0版中，必须在一个主机上执行一个项目的所有操作（
build ，
deploy ，
cleanup ）。 这意味着在CI系统中必须使用固定工人。 同时，对任务的并行性没有任何限制：werf可以完全解决此问题。 您还可以在不同的工作人员之间分配不同的项目。
在这篇专门针对该版本的文章中，我们将仔细研究此版本提供和不提供的内容，以及我们对将来版本的计划。 但是，我们将从理解“ GitOps”一词的理解以及werf在持续集成和应用程序交付（CI / CD）过程中的作用开始。
为什么werf是GitOps
那么，GitOps是什么意思，werf涵盖哪些领域？
“ GitOps”一词由Weaveworks于2.5年前提出，最近我们
翻译了其作者的文章，揭示了博客这种新现象的实质。 根据我们的理解，GitOps的主要思想和主要含义是
Git是“真理的唯一来源” 。 Git商店：
- 申请代码
- 所有依赖
- 有关如何收集容器的信息；
- 有关如何部署到Kubernetes的信息;
- 和其他
然后，有一种“东西”使
现实的变化与Git的变化保持一致 。 这种方法不仅可以通过在Kubernetes中安装一些监视Git的操作员来实现，还可以使用可以从任何CI系统调用的控制台实用程序来实现。 而且，从我们的角度来看，使用CLI实用程序的方法没有施加不必要的限制：我们可以使用任何工具和任何细微差别进行CI，调用CLI实用程序将“真实性”（即Kubernetes）与Git状态同步。 。
werf提供了一个高级CLI界面，其中包含用于构建和发布映像，交付应用程序和清理映像的基本命令：
werf build-and-publish ，
werf deploy ，
werf dismiss ，
werf cleanup 。 假定这些非常基本的命令已嵌入特定的CI系统中，并提供了与现实的必要同步。 此外，werf还提供了用于管理各种子系统的低级CLI界面-请参阅文档中的
低级管理命令 。
内置的CI / CD是否可以根据推入或推入模型工作
（ 在此处了解更多信息）都没有关系 ，因为
werf可以内置到任何模型中 。 同时，werf解决了诸如使用单独的低级实用程序（例如
git ，docker和kubernetes api-server）等问题，它们是配置统一CI / CD应用程序的“缺失部分”。
什么是werf 1.0稳定版
1.图像的组装，出版和清洁
如果您的应用程序需要构建Docker映像，则可以使用werf 1.0：
- 在单个
werf.yaml配置中描述组装图像的规则（可以有多个）； - 收集图像并发布到Docker Registry
- 定期清理Docker Registry以获取自定义策略。
werf支持
两种描述程序集的方式 ：将
werf.yaml连接
werf.yaml 现有Dockerfile以及
Stapel收集器的说明 。 使用Stapel进行构建有其优点：在Git中更改应用程序代码时使用更快的增量重建，使用Ansible语法进行汇编等。 您可以
在文档中了解有关此收集器和语法的更多信息，并且在
手册中提供了其用法示例。
参考Git提交，分支和标签，可以使用不同的标记/版本化所收集图像的方案。
组装映像是应用程序部署的可选阶段，如果没有您自己的组装映像，则可以跳过。
2.仅在一个主机上暂存
werf引入了阶段存储的概念。 主要的werf命令使用阶段存储，如下所示：
- 保存装配结果-舞台存储中的Docker映像
- 使用舞台存储中的图像作为缓存来重建和组合新图像；
- 使用存储库获取有关所收集图像的信息以供进一步使用（例如，将应用程序交付给Kubernetes时）。
部署单个应用程序时，应为所有团队使用单个阶段的存储（组装，发布，图像清理，应用程序部署）。
在1.0版中，只有本地主机存储可以充当阶段存储（命令的相应参数为：--
--stages-storage=:local ）。 使用时
:local阶段存储在磁盘上。 结果是：
werf 1.0只能
在一个主机上使用
，以组织
单个应用程序的部署。 该主机必须在命令启动之间保存数据，以使werf正常工作。
在1.0版中，不支持将阶段存储在外部存储中，您可以使用该阶段来组织分布式程序集。 但是，此类功能将出现在werf的未来版本中
（有关更多详细信息，请参见下文） 。
3.推出应用程序并检查可用性
为了推出该应用程序，用户以与Helm兼容的格式描述该图表：一组Kubernetes清单和模板参数。
werf在Kubernetes中启动该应用程序，并确保它在完成应用程序推出过程之前启动并运行。 这包括组件日志的输出以及出现问题时对推出错误的即时响应-推出命令将使用非零代码删除。 因此，在CI / CD中使用werf推广时，
我们会从软件中获得足够的反馈 ：是否下载了应用程序，并且有足够的信息来调试和修复问题（而无需运行其他实用程序来查找诸如
kubectl问题）。
werf与现有的Helm 2安装完全兼容，但是werf具有许多优点。 例如，作为一种更新资源的机制，Kubernetes使用
3向合并补丁程序 ，并且在将应用程序交付到集群时也有可能接收反馈。
此页面上描述了差异的完整列表。
4.收集的图像与应用程序交付过程的关系
werf将收集的图像集成到单个系统中，将图像标记和版本化以及将应用程序交付给Kubernetes的过程。 werf收集的图像可以在Kubernetes资源描述模板中使用。
正是由于这些功能，我们可以说
werf提供了比Helm，Docker和其他构建器和实用程序
更高级别的接口 ，以便分别进行部署。 这个接口使您可以将werf轻松集成到任何现有的CI / CD系统中，而不必解决将所有使用的组件组合在一起的问题-他负责此任务。
5.与现有CI / CD系统集成
在1.0版中，自动集成仅可用于
GitLab CI系统 。 为此，提供了
werf ci-env命令。 它从CI / CD系统接收必要的信息，并自动将werf配置为在CI环境中正常工作。
您可以在手册中阅读有关与任何CI / CD系统集成的工作方式的更多信息（
复习 ，
GitLab CI规范 ，
与其他系统的集成 ）。
6.针对Linux，Windows和macOS的跨平台开发
werf 1.0是一个静态链接的二进制文件，可与Docker和Helm发行版独立工作。 主机系统上的外部依赖项：
werf可以在GNU / Linux，Windows或macOS的任何操作系统和环境上运行。 而且，无论使用什么系统，汇编的结果都是相同的：高速缓存阶段的相同签名，阶段的相同填充，无论该阶段的收集系统是什么。 也不需要为在不同系统中工作而更改配置。
因此，werf 1.0提供了用于构建应用程序并将其交付给Kubernetes的跨平台工具。
在此还应注意，werf收集用于在Linux环境中工作的标准Docker映像，但版本1.0不支持
Windows容器 。
7.测试覆盖功能
目前，集成e2e测试和单元测试涵盖了werf代码的60％。
werf在所有受支持的操作系统（Linux，Windows和macOS）上均使用GitHub Actions进行了测试，以组织其启动过程。 一些测试细节也可以在
Code Climate中找到 。
8.版本控制
目前，通过1.0
版的发布 ，该项目已经制作了
大约700个版本 。
werf使用具有稳定通道的高级发布系统：
alpha ，
beta ，
ea（早期访问） ，
稳定和
坚如磐石 。 该帖子的发布时间与
稳定版中第一个1.0版本的发布时间一致。 对版本的不稳定更改首先要经过一系列渠道，然后最终
陷入僵局 。 通常会进行发布（有时每天发布几次），并且更改会以“小部分”形式连续交付。
稳定性渠道和许多频繁发布的版本使您能够不断获得有关新更改的反馈，能够快速回滚这些更改，并通常确保软件的高稳定性，同时可以接受可接受的开发速度。
重要的一点是，在版本1.0-> 1.1、1.1-> 1.2之间切换时，可能需要用户手动干预对werf的更改（这可以是迁移脚本，也可以是发行版中描述的手动执行指令）。 更新1.0内的版本（1.0.1、1.0.2，... 1.0.6-alpha1、1.0.6-beta.2等）可确保不需要进行此类手动更改。
您可以
在此处阅读有关向后兼容性Promise的更多信息。
进一步的计划
以下是未来版本的主要工作领域及其实现的大致术语：
1.使用werf在本地开发和部署应用程序
主要目标是实现一个统一的配置，以开箱即用地在本地和生产环境中部署应用程序，而无需复杂的操作。
Werf还需要一种操作模式，在该模式下，可以方便地编辑应用程序代码并立即从工作的应用程序接收反馈以进行调试。
版本1.1，2020年1月至2月2.基于内容的标记
仅在发布图像时标记图像，仅基于该图像的内容即可。 与绑定到Git提交的模式不同，此模式将完全摆脱不必要的重建。 Git-commit-id不是工作树内容的通用标识符（尽管取决于它）。
如果应用程序代码未更改，但是已进行了新的提交，则Git提交的当前标记模式将在发布图像时使用新名称创建图像。 这还将需要在Kubernetes中使用该映像回滚资源。 同时，图像本身的内容没有改变。
为了解决这些问题，werf将基于应用程序
内容校验和的计算引入一种新型的标记-
基于内容的标记 。
版本1.1，2020年2月至3月3.过渡到头盔3
它包括过渡到新的
Helm 3代码库，以及一种行之有效的迁移现有安装的便捷方法。
版本1.1，2020年2月至3月4.并行组装图像
目前，werf 1.0
werf.yaml顺序收集
werf.yaml声明的图像和工件的所有阶段。 需要具有并行化平台组装过程的能力。
版本：1.1，2020年1月至2月5.分布式图像集合
目前，werf 1.0只能在一个专用主机上使用
（请参阅上面有关仅在一个主机上的阶段存储的要点） 。
为了打开分布式程序集的可能性，当程序集在多个主机上启动并且这些主机不保持程序集之间的状态（临时运行程序）时，需要werf来实现使用Docker Registry作为阶段存储库的可能性。
以前，当werf项目也称为dapp时，它就有这样的机会。 但是，在werf中实现此功能时，我们遇到了许多必须考虑的问题。
版本1.2：2020年3月至4月6. Jsonnet描述Kubernetes配置
werf将支持
Jsonnet格式的Kubernetes的配置描述。 同时，werf将继续与Helm兼容，并且可以选择描述格式。
原因是，事实上，Go语言模板的入门门槛很高，而且这些模板的代码清晰度也受到影响。
还考虑了用于实现Kubernetes配置描述系统的其他选项（例如Kustomize）。
版本1.1：2020年1月至2月7.在Kubernetes中工作
目的：为了确保使用Kubernetes中的运行程序组装图像并交付应用程序。 即 新映像的组装，其发布，清洁和部署可以直接从Kubernetes吊舱中进行。
要实现此功能，您首先需要具有分布式构建映像的能力
（请参见上文） 。
它还需要支持没有Docker守护程序的构建操作模式（即类似Kaniko的构建或
userspace中的
构建 ）。
werf将不仅通过Dockerfile支持Kubernetes构建，还将通过带有增量重建的Stapel构建器来支持Kubernetes构建。
版本1.2：2020年4月-5月8.其他
还计划：
- Ansible版本升级以及使用不同版本的Ansible的能力；
- 支持角色扮演；
- 支持Stapel中的任意组装阶段（当前werf支持一组静态阶段：
beforeInstall ， install ， beforeSetup ， setup ）； - 改进的语法
werf.yaml ，过渡到configVersion: 2 （尤其与前两个要点相关），支持OpenAPI规范； - Stapel中的Git LFS支持，用于在Git中存储大文件；
- 改进了图像清理机制（当前版本中的非严重缺陷与未在主master分支的
werf.yaml配置中声明的图像有关-这些图像将通过定期清理而删除）； - 在一个命名空间中部署多个应用程序时，使用共享的Kubernetes命名空间可以更正确地工作；
- 如果部署失败，则将应用程序自动回滚到最新的工作版本。
合计
我在总结中会简短。 我们是：
- 长期走向1.0版的问世；
- 考虑了很多实际经验；
- 我们展示了经过验证的实用程序，它具有稳定的功能，并已通过成千上万次部署进行了验证。
1.0版的发布标志着werf进入新开发阶段的开始，在此阶段中将从根本上添加新功能。 关注新闻！ 并加入
werf_ru tg频道 ，直接的werf开发人员以及我们在Flant公司之外的工程师和实用程序的用户都将参与。
聚苯乙烯
另请参阅我们的博客：