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学堂