主持人 > 博客 > 管理 > GitOps：拉取和推送方法的比较

GitOps：拉取和推送方法的比较

笔记。 翻译。：在 Kubernetes 社区中，一种称为 GitOps 的趋势正在明显流行，正如我们亲眼所见， 拜访 KubeCon Europe 2019。这个术语相对较新 造币 由 Weaveworks 的负责人 Alexis Richardson 提出，意味着使用开发人员熟悉的工具（主要是 Git，因此得名）来解决操作问题。 特别是，我们讨论 Kubernetes 的操作，将其配置存储在 Git 中并自动将更改推送到集群。 Matthias Jg 在本文中讨论了这种部署的两种方法。

GitOps：拉取和推送方法的比较

去年 （事实上​​，正式这件事发生在 2017 年 XNUMX 月 - 大约翻译） 有一种在 Kubernetes 中部署应用程序的新方法。 它称为 GitOps，它基于在 Git 存储库的安全环境中跟踪部署版本的基本理念。

这种方法的主要优点如下：:

  1. 部署版本控制和更改历史记录。 整个集群的状态存储在 Git 存储库中，并且部署仅通过提交来更新。 此外，可以使用提交历史记录来跟踪所有更改。
  2. 使用熟悉的 Git 命令进行回滚... 清楚的 git reset 允许您重置部署中的更改； 过去的状态总是可用的。
  3. 准备好访问控制。 通常，Git 系统包含大量敏感数据，因此大多数公司都会特别注意保护它。 因此，这种保护也适用于部署操作。
  4. 部署策略。 大多数 Git 系统本身就支持逐个分支的策略，例如，只有拉取请求才能更新 master，并且更改必须由其他团队成员审核和接受。 与访问控制一样，相同的策略也适用于部署更新。

正如您所看到的，GitOps 方法有很多好处。 在过去的一年里，有两种方法特别受欢迎。 一种是基于推式的，另一种是基于拉式的。 在了解它们之前，我们首先看一下典型的 Kubernetes 部署是什么样的。

部署方法

近年来，Kubernetes 建立了多种部署方法和工具：

  1. 基于原生 Kubernetes/Kustomize 模板。 这是在 Kubernetes 上部署应用程序的最简单方法。 开发人员创建基本 YAML 文件并应用它们。 为了摆脱不断重写相同模板的情况，开发了 Kustomize（它将 Kubernetes 模板转换为模块）。 笔记。 翻译。：Kustomize 已集成到 kubectl 中 Kubernetes 1.14 发布.
  2. 舵图。 Helm 图表允许您创建一组模板、初始化容器、sidecar 等，这些模板用于部署应用程序，具有比基于模板的方法更灵活的自定义选项。 此方法基于模板化 YAML 文件。 Helm 为它们填充各种参数，然后将它们发送到 Tiller，Tiller 是一个集群组件，Tiller 将它们部署到集群并允许更新和回滚。 重要的是，Helm 本质上只是将所需的值插入到模板中，然后以与传统方法相同的方式应用它们 （阅读更多关于它是如何工作的以及如何在我们的 赫尔姆的文章 - 大约。 译）。 有各种各样的现成 Helm 图表，涵盖了广泛的任务。
  3. 替代工具。 有许多替代工具。 它们的共同点是，它们将一些模板文件转换为 Kubernetes 可读的 YAML 文件，然后使用它们。

在我们的工作中，我们经常使用 Helm 图表作为重要工具（因为它们已经准备好了很多东西，这让生活变得更加轻松）和“纯”Kubernetes YAML 文件来部署我们自己的应用程序。

拉推

在我最近的一篇博客文章中，我介绍了该工具 编织助焊剂，它允许您将模板提交到 Git 存储库，并在每次提交或推送容器后更新部署。 我的经验表明，这个工具是推广拉式方法的主要工具之一，所以我会经常参考它。 如果您想了解更多如何使用它，请点击这里 文章链接.

注意！ 对于这两种方法来说，使用 GitOps 的所有好处都是相同的。

基于拉动的方法

GitOps：拉取和推送方法的比较

拉取方法基于以下事实：所有更改均从集群内部应用。 集群内有一名操作员定期检查关联的 Git 和 Docker 注册表存储库。 如果它们发生任何变化，集群的状态会在内部更新。 此过程通常被认为非常安全，因为外部客户端无法访问集群管理员权限。

优点：

  1. 外部客户端无权对集群进行更改；所有更新均从内部推出。
  2. 有些工具还允许您同步 Helm 图表更新并将其链接到集群。
  3. 可以扫描 Docker 注册表以获取新版本。 如果有新映像可用，Git 存储库和部署将更新到新版本。
  4. 拉取工具可以分布在具有不同 Git 存储库和权限的不同命名空间中。 因此，可以使用多租户模型。 例如，团队 A 可能使用命名空间 A，团队 B 可能使用命名空间 B，基础设施团队可能使用全局空间。
  5. 一般来说，这些工具非常轻量。
  6. 与operator等工具结合 Bitnami 密封的秘密，秘密可以加密存储在 Git 存储库中并在集群中检索。
  7. 由于部署发生在集群内，因此没有与 CD 管道的连接。

缺点:

  1. 从 Helm 图表管理部署机密比常规部署机密更困难，因为它们首先必须以密封机密的形式生成，然后由内部操作员解密，只有在此之后它们才可供拉取工具使用。 然后，您可以使用已部署的机密中的值在 Helm 中运行发布。 最简单的方法是使用用于部署的所有 Helm 值创建一个密钥，对其进行解密并将其提交到 Git。
  2. 当您采用拉式方法时，您就会受到拉式工具的束缚。 这限制了在集群中自定义部署过程的能力。 例如，Kustomize 很复杂，因为它必须在最终模板提交到 Git 之前运行。 我并不是说您不能使用独立工具，但它们更难以集成到您的部署过程中。

基于推送的方法

GitOps：拉取和推送方法的比较

在推送方法中，外部系统（主要是 CD 管道）在提交到 Git 存储库后或如果之前的 CI 管道成功，则启动对集群的部署。 在这种方法中，系统可以访问集群。

优点:

  1. 安全性由 Git 存储库和构建管道决定。
  2. 部署 Helm 图表更容易，并且支持 Helm 插件。
  3. 秘密更容易管理，因为秘密可以在管道中使用，也可以加密存储在 Git 中（取决于用户的偏好）。
  4. 与特定工具没有联系，因为可以使用任何类型。
  5. 容器版本更新可以由构建管道启动。

缺点:

  1. 集群访问数据位于构建系统内部。
  2. 通过拉取过程更新部署容器仍然更容易。
  3. 严重依赖CD系统，因为我们需要的管道最初可能是为Gitlab Runners编写的，然后团队决定迁移到Azure DevOps或Jenkins......并且将不得不迁移大量构建管道。

结果：推还是拉？

通常情况下，每种方法都有其优点和缺点。 有些任务用一种方法更容易完成，用另一种方法则更困难。 起初我是手动进行部署，但在看到几篇有关 Weave Flux 的文章后，我决定为所有项目实施 GitOps 流程。 对于基本模板来说，这很容易，但后来我开始在使用 Helm 图表时遇到困难。 当时，Weave Flux 仅提供了 Helm Chart Operator 的基本版本，但即使现在，由于需要手动创建机密并应用它们，某些任务也变得更加困难。 您可能会认为拉取方法更加安全，因为集群的凭据在集群外部无法访问，这使得它更加安全，值得付出额外的努力。

经过一番思考，我得出了意想不到的结论：事实并非如此。 如果我们谈论需要最大程度保护的组件，则此列表将包括秘密存储、CI/CD 系统和 Git 存储库。 其中的信息非常脆弱，需要最大限度的保护。 此外，如果有人进入您的 Git 存储库并可以将代码推送到那里，他们就可以部署他们想要的任何内容（无论是拉取还是推送）并渗透集群的系统。 因此，需要保护的最重要组件是 Git 存储库和 CI/CD 系统，而不是集群凭据。 如果您为这些类型的系统配置了良好的策略和安全控制，并且集群凭证仅作为机密提取到管道中，则拉取方法所增加的安全性可能没有最初想象的那么有价值。

因此，如果拉式方法更加劳动密集并且不能提供安全优势，那么仅使用推式方法不是合乎逻辑的吗？ 但有人可能会说，在推送方法中，您与 CD 系统的联系过于紧密，也许最好不要这样做，以便将来更容易进行迁移。

在我看来（一如既往），您应该使用最适合特定情况或组合的东西。 就我个人而言，我使用这两种方法：Weave Flux 用于基于拉取的部署，主要包括我们自己的服务，以及使用 Helm 和插件的推送方法，这使得可以轻松地将 Helm 图表应用到集群，并允许您无缝创建机密。 我认为永远不会有一个解决方案适合所有情况，因为总是存在很多细微差别，并且它们取决于具体的应用程序。 话虽这么说，我强烈推荐 GitOps - 它让生活变得更加轻松并提高安全性。

我希望我在这个主题上的经验能够帮助您决定哪种方法更适合您的部署类型，我很高兴听到您的意见。

PS 译者注

拉取模型的缺点是很难将渲染的清单放入 Git，但是没有缺点，拉取模型中的 CD 管道与推出分开，本质上成为一个类别管道 持续申请。 因此，需要付出更多的努力来从所有部署中收集其状态，并以某种方式提供对日志/状态的访问，最好参考 CD 系统。

从这个意义上说，推送模型允许我们至少为 rollout 提供一些保证，因为可以使 pipeline 的生命周期等于 rollout 的生命周期。

我们尝试了这两种模型，得出了与文章作者相同的结论：

  1. 拉模型适合我们在大量集群上组织系统组件的更新（参见. 关于插件操作符的文章).
  2. 基于 GitLab CI 的推送模型非常适合使用 Helm 图表推出应用程序。 同时，使用该工具监控管道内部署的推出 韦尔夫。 顺便说一句，在我们这个项目的背景下，当我们在 KubeCon Europe'19 的展位上讨论 DevOps 工程师的紧迫问题时，我们听到了持续不断的“GitOps”。

来自译者的PPS

另请阅读我们的博客：

只有注册用户才能参与调查。 登录拜托

你在使用 GitOps 吗？

  • 是的，拉式方法

  • 是的，推

  • 是的，拉+推

  • 是的，还有别的东西

  • 没有

30 位用户投票。 10 名用户弃权。

来源： habr.com

添加评论