4.7 CI/CD 管道中的工作流模型

下一个常见问题涉及工作流模型。所有的 CI/CD 管道都可以有两种类型的工作流程模型,这取决于作为管道一部分部署的自动化工具。

  1. 基于推的模式
  2. 基于拉的模式

在支持基于推模式的 CI/CD 工具中,在管道的一个阶段或阶段所做的改变会触发后续阶段或阶段的改变。例如,通过一系列的编码脚本,CI 系统中的新构建会触发管道中 CD 部分的变化,从而改变部署基础设施(如 Kubernetes 集群)。使用 CI 系统作为部署变化的基础,其安全方面的缺点是有可能将凭证暴露在部署环境之外,尽管已尽最大努力确保 CI 脚本的安全,因为 CI 脚本是在部署基础设施的信任域之外运行的。由于 CD 工具拥有生产系统的 key,基于推送的模式就变得不安全了。

在基于拉的工作流程模型中,与部署环境有关的运维(例如 Kubernetes 运维、Flux、ArgoCD)一旦观察到有新镜像被推送到注册表,就会从环境内部拉动新镜像。新镜像被从注册表中拉出,部署清单被自动更新,新镜像被部署在环境(如集群)中。因此,实际的部署基础设施状态与 Git 部署库中声明性描述的状态实现了衔接。此外,部署环境凭证(例如集群凭证)不会暴露在生产环境之外。因此,强烈建议采用基于拉的模式,即通常使用 GitOps 仓库来存储源代码和构建。

4.7.1 GitsOps 的 CI/CD 工作流程模型 —— 基于拉的模型

GitOps 工作流模型是对 CI/CD 管道的改进(针对管道的交付部分),它使用了基于拉的工作流模型,而不是许多 CI/CD 工具支持的基于推的模型。在这个模型中,流水线的 CI 部分没有变化,因为 CI 引擎(如 Jenkins、GitLab CI)仍然用于为修改后的代码创建构建。

回归测试,以及与相关存储库中的主要源代码集成 / 合并,尽管它不用于在管道中触发持续交付(直接推送更新)。

相反,一个单独的 GitOps Operator 根据主干代码的更新来管理部署。

Operator(例如,Flux、ArgoCD)是一个由协调平台管理的行为体,可以继承集群的配置、安全和可用性。使用这种行为体可以提高安全性,因为在集群内部的代理会监听它被允许访问的所有代码和镜像仓库的更新,并将镜像和配置更新拉入集群。代理使用的拉方式具有以下安全特性:

  • 只执行协调平台中定义的授权策略所允许的操作;信任与集群共享,不单独管理。
  • 与所有协调平台对象进行原生绑定,并了解操作是否已经完成或需要重试。
Copyright © 2017-2022 | 基于 CC 4.0 协议 | jimmysong.io all right reserved. Updated at 2022-03-15 03:24:19

results matching ""

    No results matching ""