实施 GitOps 以交付云原生应用程序
DevOps改变了开发和管理应用程序的方式，并带来了更快的开发周期。现在有一种新的 Ops。GitOps 正在迅速普及，以进一步扩展 DevOps 的范围包括应用程序基础设施。在本文中，我们将了解 GitOps 以及如何利用它来交付云原生应用程序。
1什么是 GitOps？
GitOps 是一组旨在管理应用程序底层基础设施的实践。它利用 Git 作为源代码管理工具来管理基础设施代码。换句话说，GitOps 是对基础设施即代码和 DevOps 实践的评估，它使用 Git 作为以声明方式配置基础设施的单一事实来源。
GitOps 一词于 2017 年由 Weaveworks 限定，主要旨在管理Kubernetes 部署。但是，现在它已发展为支持其他基础架构管理解决方案，例如 Terraform。
GitOps 的目标是简化和精简开发过程。这导致构建具有适当状态管理的可复制基础设施：
提高整体可见度
减少应用程序基础架构的管理开销
GitOps 允许开发人员或运维团队将他们的基础设施声明为代码，并通过 Git 对其进行版本控制。每当需要新更改时，都会创建包含新更改的拉取请求，执行CI/CD 管道以更新或修改基础设施。
此外，GitOps 为用户提供了选择任何工具、技术或平台的灵活性，并在创建基础设施时使用相同的 DevOps 实践。
2GitOps的原理
在实施和处理 GitOps 时，有一些适用的核心原则。让我们来看看。
声明式系统
在 GitOps 模型中，整个系统都是声明式配置的。这种声明式方法侧重于结果（期望状态），而不是实现所需结果所需的步骤。
这种声明式方法允许用户指定最终目标，而无需像命令式方法那样担心所需的每个明确步骤。作为一种状态感知的声明式方法，用户可以轻松地将这些状态存储在 Git 中，方便部署和回滚。
系统状态在 Git 中版本化
所有声明性状态都存储在版本控制系统中，作为唯一的真实来源。使用这种版本控制的方法，所有系统基础设施更改都可以按时间顺序进行，使用户能够轻松识别随时间推移的基础设施更改。它也有助于：
故障排除
审计
回滚
批准后会自动应用更改
当提出拉取或合并请求时，它将被验证然后批准，因为所有更改都存储在 Git 中。
此外，当更改被批准时，应该自动将更改应用到系统。GitOps 更喜欢立即自动化部署以快速达到所需的状态。
3GitOps 方法的好处
GitOps 使组织能够简化其基础架构配置和应用程序部署策略。这会带来广泛的好处。
易于基础设施管理
GitOps 允许用户在整个 DevOps 流程中轻松管理基础设施，方法是借助以下工具快速测试和部署更改：
CI/CD工具
自动化部署
更短的反馈循环
通过将基础设施作为 CI/CD 管道的一部分，任何需要更改基础设施的应用程序修改都可以捆绑在一起进行管理。它还可以更轻松地解决生产错误，例如网络连接，因为用户可以更好地了解部署的变化。
提高生产力
源代码控制、经过验证的基础架构减少了部署期间可能发生的配置错误，从而节省了运维团队诊断和修复这些错误的时间。此外，源代码控制允许多个团队在基础设施的不同部分工作，而不会干扰彼此的工作。
这会提高开发和运营团队的生产力，最终导致更快的开发和部署。
提高可靠性和稳定性
在版本控制的基础设施方法中，基础设施更改得到验证，状态始终保持不变。当与配置基础设施的声明式方法结合使用时，它可以大大减少应用程序基础设施中的错误。
最重要的是，版本控制允许用户轻松审核更改并回滚到以前的状态。这反过来又提高了应用程序的稳定性和可靠性。
另一个因素是管理配置迁移。作为现代应用程序，将需要应用手动修补程序或可能导致配置迁移的小更改。使用 GitOps，用户可以：
轻松识别声明的基础设施和实际基础设施之间的这种偏差
快速缓解它们
标准化
GitOps 有助于标准化基础设施部署。基础设施可以对应用程序代码进行几乎相同的验证和验证过程，并具有一致的：
端到端工作流
标准化的代码结构
文档
测试方法
这引入了标准化和完全可复制的基础设施配置。
增强的安全性
GitOps 方法可帮助组织实施安全最佳实践，并通过 Git SCM 跟踪所有基础设施更改和相应状态。此外，这种有组织的方法支持适当的审计跟踪，以识别与基础设施更改相关的详细信息，例如
负责任的用户
部署数据时间
受影响的资源
等等。
GitOps 方法还有助于简化对基础架构修改的身份验证和授权要求的管理。由于基础设施是 CI/CD 管道的一部分，个人开发人员不需要直接访问资源，因此不需要凭据来访问所述资源。
这也使得用户必须仅在管道中执行时提供凭据。这进一步对底层资源实施严格的访问控制，减少对基础设施的攻击向量。
但是，我们必须正确实施 GitOps 作为交付管道的一部分才能获得上述所有好处。在下一节中，我们将介绍如何正确实施 GitOps 工作流程。
4如何实现 GitOps?
如果您的组织已经使用 Git 作为 SCM 工具正确实施了 DevOps 管道，那么实施 GitOps 来覆盖基础设施是一个非常简单的过程。简单地：
将基础架构代码添加到 Git 存储库中。
配置 CI/CD 管道以将基础架构存储库包含为交付管道的一部分。
另一方面，如果从头开始，首先要考虑的是Git 存储库。由于 GitOps 与平台无关，因此用户可以使用任何本地或基于云的 Git 存储库，例如：
GitHub
Bitbucket
GitLab
等等。
然后是 CI/CD管道平台，它归结为您首选和熟悉的平台工具。Jenkins 和 CircleCI 等工具可用于任何 git 存储库。BitBucket Pipeline 和 GitLab Pipelines 更喜欢他们自己的代码存储库。无论选择何种管道平台，其主要目标都是：
自动化交付过程。
促进 Git 存储库和基础设施管理平台之间清晰的工作流程。
GitOps 管道的差异化因素是GitOps operator。该机制位于管道和基础设施平台之间，充当促进它们之间通信的中间人。有多个可用的operator，例如：
Kubernetes operator
Terraform Cloud Operator
Azure Services Operator
5GitOps 工作流程
现在，我们有了一个 Git 存储库和一个正确配置的 CI/CD 管道。基础架构工程师将：
将基础设施声明为代码。
将代码推送到 Git 存储库。
创建拉取请求。
之后，此代码可以由另一个团队成员审查和审查，并最终获得批准——这会触发 CI/CD 管道。然后管道将通知 Git Operator，后者将获取所有修改和所需的新状态。
然后，Git 操作员将比较现有基础设施的状态和所需的状态。这与可观察性概念有关，即测量系统内部状态的能力。这种可观察性确保基础设施的期望状态和观察状态相同。
如果状态不同，它将无缝地编排和提供底层基础设施以匹配所需的状态。
可以通过合并多个基础架构部署（例如暂存和生产）来进一步扩展此工作流程。这样，初始部署将在临时环境中执行，在最终将基础架构修改部署到生产环境之前，该环境充当进一步的故障保护。同样，GitOps 管道提供了无限的可能性来扩展和集成基础设施以满足任何需求。
<
6GitOps 示例
让我们以 GitOps 的真实场景为例，其中 Web 应用程序部署在云环境中。
假设应用程序的流量突然激增，这会产生性能问题，从而导致使用 Web 应用程序时的用户体验不理想。
为了解决这个问题，交付团队希望增加 Web 应用程序的资源分配。使用 GitOps，用户可以定义资源增量并将更改推送到 Git 存储库。然后这些更改可以由其他团队成员快速审查和验证，并批准用于生产部署。
这会触发 GitOps CI/CD 管道并初始化 git Operator。然后 git Operator将比较状态。此新配置将将此识别为状态更改，并自动编排底层基础架构以匹配所需状态。
交付团队只需要监控任何故障，这也会通过 CI/CD 管道自动通知交付团队。如果底层基础设施没有问题，它将成功地通过新的资源分配进行修改以满足用户需求。
但是，如果部署失败，或者配置错误导致网络问题，会发生什么？
GitOps 方法允许用户快速无缝地回滚到基础设施的先前状态。然后，他们可以再次查看和创建解决所有这些问题的基础架构更改，并触发 CI/CD 管道以自动部署更改。
如果没有 GitOps，恢复到以前的配置状态是一项复杂的任务，如果没有正确记录更改，这几乎是不可能的。
7简化的自动化管道
GitOps 将所有手动、复杂的基础设施管理任务转换为简化的自动化管道。这种声明性的版本控制方法使管理基础设施的耗时、艰巨的任务变得轻松，同时提高了系统的可见性、可靠性和稳定性。
本文翻译学习，原文链接：https://www.bmc.com/blos/gitops-cloud-native-app-delivery/ >>> 欢迎投稿，微信：devopsvip。
关于我们
DevOps云学堂，专注于企业级DevOps运维开发技术实践分享，主要以新Linux运维技术、DevOps技术课程为主。丰富的一线实战经验，课程追求实用性获得多数学员认可。课程内容均来源于企业应用，在这里既学习技术又能获取热门技能，欢迎您的到来！
更多DevOps实践，请关注「DevOps云学堂」
点击阅读原文，进入企业DevOps学堂