在设计或实施 GitOps 的早期阶段，考虑可能需要的各种工具和实践可能会让人望而生畏。你要确保自己设计的是一个强大、可扩展的工作流程，用于管理基础架构和应用程序的部署。同时，您也不希望引入任何会导致流程过于复杂或增加团队发布代码变更难度的工具。
缩小关注范围的方法之一是寻找能够支持部署实践的工具和实践。主要的考虑因素是采用推式方法还是拉式方法。这两种方法各有利弊，您使用哪种方法将影响到您的 GitOps 战略中包含的工具和流程。
工作流程和基础设施自动化
首先，让我们回顾一下 DevOps 的两个核心实践：基础设施即代码（IaC）以及持续集成和持续交付（CI/CD）自动化。
IaC 是一种通过代码而非一系列手动步骤或交互流程来部署和管理基础设施的技术。这种方法不仅限于基础架构基元或托管云服务，还适用于配置文件、软件安装、网络和安全策略等所有可管理的方面。这种类型的统一管理通常被称为 "X 即代码"，它为您的部署提供了模板化和文档化的理想状态。
CI/CD 是一种方法和一套通用实践，使开发人员能够快速、可靠地交付高质量、安全编码的应用程序。接受 CI/CD 就是接受一种文化，在这种文化中，开发团队可以通过在软件开发生命周期的正确阶段实施自动化，始终专注于业务和最终用户的需求。
在软件开发中，集成是将更改提交到代码库中的过程。持续集成（CI）是通过以可靠、一致的方式构建、测试和打包更新的应用程序代码，自动验证变更的过程。在每次推送事件中触发 CI 工作流可提供更顺畅、更快速的开发流程，因为在将更改部署到环境之前就能发现错误、安全漏洞和冲突。
持续交付（CD）工作流在 CI 工作流成功完成后接管。这是将更新的应用程序代码交付到选定环境的自动化一致流程。这可以是一个工作流，便于将应用程序直接部署到暂存或生产服务器上，或将新版本发送到容器注册表或移动分发平台上。
这些都是围绕开发人员工作流程自动化的核心主题。GitOps 方法依赖于这些核心 DevOps 实践，并将其付诸实施。利用 git 仓库作为 IaC 定义文件的唯一真实来源，并利用自动化管道，就能有效地对基础架构的理想状态进行版本控制。
这里我们又回到了您的部署实践：决定推式还是拉式最适合您的应用程序和 GitOps 战略。
推式架构与拉式架构的比较
基于推送或无代理是一种更传统的方法，即通过 Jenkins 或 CircleCI 等外部 CI/CD 客户端将变更推送到所选环境。对于非 Kubernetes 环境或混合了多种工作负载类型的环境来说，这种方法更为可取，因为在每个组件上运行单独的代理和 webhooks 会很麻烦。
优点
- 在单一环境中跨多种类型的工作负载实施更简单。
- 不同环境（如云原生环境和内部部署环境）之间部署方法的标准化。
- 工具灵活性，因为大多数 CI/CD 框架都采用基于推送的模式。
缺点
- CI/CD 客户端不具备可观察性，无法知道变更是否成功部署，或服务器端是否因此出现问题。
- 可能需要安装其他工具（如 kubectl、Helm、Docker、Ansible 、Terraform 、SSH），以便 CI/CD 客户端部署更改。
- 需要让 CI/CD 客户端从外部访问环境，这增加了安全和合规问题的风险。
基于拉动的方法或代理方法则相反，它将环境作为 CD 管道的一部分。代理或操作员会监视 git 仓库中的变更，然后拉取并应用这些变更。当代理检测到配置偏离单一真实源时，也会执行这项任务。这种方法尤其适用于 Kubernetes 原生环境。
优点
- 代理/操作员可观察环境的当前状态和部署状态。
- 更高的安全性和简化的合规性，因为环境只需要查看源的权限。
- 快速检测人工干预或其他来源造成的配置偏移。
缺点
- 对非 Kubernetes 部署而言更为复杂。
- 需要设计用于特定环境类型的工具。
在您开始规划 GitOps 战略时，请考虑不同的部署策略将如何支持您的应用程序。基于推和基于拉的方法各有优势，适用于不同的场景。需要考虑的工具和实践有很多，只要有一定的视角，你就会知道什么是适合你的团队和堆栈的解决方案。
想要了解更多信息？下载我们免费的GitOps策略电子书，或免费咨询Akamai云计算专家。
注释