主页 / 问题 / 1215757
Accepted
muturgan
Asked:2021-12-08 19:00:29 +0000 UTC2021-12-08 19:00:29 +0000 UTC

为什么需要werf？

  • 772

当然，这个问题是广泛而模糊的。但还是。
这里我们有一个集群。这里我们有 gitlab-ci（例如）。
应用程序已组装，测试正在运行，部署正在运行。
这就是为什么现在每个人都挤进这个故事的原因werf？他带来了以前不存在的东西。对我来说（从我的菜鸟的角度来看）这似乎是一个不必要的附加组件。
请解释一下造船厂的使命是什么？

непрерывная-интеграция

2 个回答

  1. Best Answer

    werf，首先，执行一些特定的功能（见下文），其次，它将 CI / CD 中涉及的不同组件（Docker、容器注册表、Helm、Kubernetes 和 CI 系统本身）“粘合”到一个单一的系统。

    具体功能：

    1. 大会。

    能：

    • 只需保留之前使用的同一个 Dockerfile 并继续从同一个构建（它将与 werf 兼容）；
    • 切换到 werf 格式本身（不是那么困难）并获得许多用于优化/加速它们的附加功能：共享缓存、工件、基于 Git 历史的增量构建、与 Bash 脚本/Ansible 任务的集成、用于调试构建的便捷工具问题……

    无论选择何种路径，都有共同的优势：并行和分布式组装、高级标记系统（基于内容的标记）。即使不需要特定功能，将程序集转移到 werf（包括 Dockerfile）这一事实允许您在其生命的后续阶段使用相同的图像（见下文）。

    1.1。另一个可以被视为构建一部分的功能是将 werf 构建的映像发布到容器注册表。不仅支持 Docker Registry，还支持其他流行的实现（包括 GitLab Registry、Harbor、云解决方案等）。

    1. 部署.

    或许，我将其称为 werf 的主要特性——在 Kubernetes 中的便捷部署，与镜像生命周期的其他阶段集成。在内部，为此使用了 Helm 的改进版本（不需要单独的 Helm）。应用程序镜像在构建后会自动部署到 K8s（Helm-charts）。与 Helm 的一个重要区别是部署过程是可视化的，即 显示真实状态（日志和状态），并在出现问题时执行回滚。

    在最新版本的 werf (v1.2) 中，构建和部署操作合并为一个命令（converge），同时强调 GitOps 方法，当“Git 是单一数据源”时， IE。应用程序已完全定义（其源代码、构建说明、部署图表），而werf 是一个不断（即每次新提交）将 Kubernetes 带入本 Git 中描述的状态的系统。

    1. 清洁。

    存储在注册表中且不再需要的应用程序镜像（不是发布，没有在任何地方推出到 Kubernetes，不需要回滚）会被自动检测和清理。

    最后一刻——所有这些功能都与任何 CI 系统集成。有用于与GitLab CI和GitHub Actions集成的现成指南，其余部分是一般说明。

    项目网站上有一个简短的介绍，您可以在其中更详细地了解 werf 的作用以及它的一般工作原理。

    总结：

    1. 使用 werf，您可以在一个地方描述应用程序的生命周期：它的组装（Dockerfile 或等效文件）和部署（Helm 图表形式的基础设施），以及实用程序（与 CI 系统一起）将使其运行。对于开发人员来说，每次新提交时，都会收集更新的图像，将其放置在注册表中，然后部署到 Kubernetes。因此，部署在 Kubernetes 中的应用程序始终是最新的。只需要 Git、werf 和您首选的 CI 系统即可实现这一切。

    2. 除了这种统一/自动化之外，在应用程序生命周期的所有阶段，都添加了它们自己的功能：优化和分布式组装，部署期间的调试和回滚，清理旧图像......

    PS 对于尚未深入研究基础架构的开发人员，有一个在线教程，其中逐步介绍了使用 werf（以及相关问题的最低要求理论）。

    • 6

  2. 简而言之，造船厂的使命就是保证 Cube 中推出的应用和容器注册表中发布的镜像对应某个 git commit。1.2 版引入了 giterminism 的概念，意思是“gith 确定性”。

    为此，除其他外：

    • 图像根据基于内容的摘要发布，仅在必要时重建；
    • 保证来自 git 的任意提交的基于内容的摘要的可重复性和已发布图像的不变性；
    • 提供了对推出过程的监控，并且推出的成功完成保证了应用程序已经真正推出，可以配置这个过程；
    • 根据应用程序的 git 存储库的历史实现对未使用图像的高级清理（可以清理旧提交，保留分支提交的图像，以及保留 N 个历史提交等，更多详细信息：https://werf. io/documentation/reference/werf_yaml.html#cleanup和https://werf.io/documentation/advanced/cleanup.html )。

    Werf 创建了一个易于配置的连贯系统，在该系统中，随时按下 rollout 进行某些提交，我们会获得一些可重现的状态。

    当然，这一切都是通过结合一些现有的解决方案（Dockerfile builder，helm）来实现的，一些部分是独立实现的（通过 stapel builder 优化图像组装，通过应用 git 补丁进行增量重建，通过 kubedog 进行部署跟踪，基于内容的标记与 git 相关联，清理未使用的镜像（所有可能的 docker-registry 实现的实现），构建镜像和部署到集群时的分布式锁，支持 helm 的秘密，支持 helm 的注入注释和标签，集成用 helm-templates 构建图像）。

    • 3

相关问题