GitOps 是一个以 Git 为中心的应用程序部署框架，可极大地简化云原生环境中的软件开发。它使用 DevOps 最佳实践（如版本控制和 CI/CD），并将其应用于基础结构自动化。从 GitOps 的基础知识到如何构建 DIY-GitOps 管道，请继续阅读以了解有关 GitOps 的更多信息。
什么是 GitOps？
GitOps 于 2017 年率先推出，是一种管理由 Kubernetes 提供支持的云原生系统的现代方式。它利用策略即代码方法来定义和管理现代应用程序堆栈的每一层 – 基础结构、网络、应用程序代码和 GitOps 管道本身。
GitOps 利用 Git 作为单一事实来源来定义云原生系统的每个部分。在 Git 中声明后，GitOps 代理 （Flux） 会自动跨开发、测试、过渡和生产环境应用所有代码、配置和策略。使用 GitOps，只要 Git 与集群中运行的内容之间存在任何差异，开发人员就会收到警报。根据具体情况，Kubernetes 协调器会自动更新或回滚集群。将 Git 置于交付管道的中心，开发人员可以使用熟悉的工具发出拉取请求，以加速和简化端到端管理软件交付的应用程序部署和策略。
阅读 GitOps 的历史，了解有关 GitOps 创建和实现的更多信息。
GitOps 如何提供帮助？
GitOps 从根本上为开发人员提供了对其应用程序生命周期的更多控制，可以概括为以下两件事：
- 它是 Kubernetes 和其他云原生技术的操作模型，它提供了一组最佳实践，将容器化集群和应用程序的 Git 部署、管理和监控结合在一起。
- 它提供了一条通往自助服务开发人员体验的途径，用于管理应用程序和自动化 CI/CD 管道，从而统一开发和运营团队。
GitOps 工作组是在 CNCF App Delivery SIG（特殊兴趣组）下成立的，旨在定义 GitOps 的供应商中立含义。作为第一步，他们启动了OpenGitOps项目。让我们看看 OpenGitOps 项目定义的 GitOps 的四个核心原则是什么。
GitOps 的核心原则是什么？
经过大量的辩论和讨论，OpenGitOps 项目被提炼成这四个简洁的原则，但准确地抓住了 GitOps 的关键思想。
#1.声明性：必须以声明方式描述整个系统
借助 GitOps，Kubernetes 只是许多现代云原生工具的一个例子，这些工具是“声明性的”，并且可以定义为代码。当我们说“声明式”时，我们的意思是配置是由一组事实而不是一组指令保证的。以声明方式定义应用程序的配置后，可以将 Git 作为单一事实来源。然后，您的应用程序可以轻松部署并在 Kubernetes 之间回滚。更重要的是，当灾难发生时，集群的基础设施也可以快速重现。
#2.版本化且不可变：规范的所需系统状态在 Git 中进行版本控制
通过将系统的声明存储在版本控制系统中，并作为规范的事实来源，您就拥有一个最终的存储库，从中派生和驱动所有内容。这轻视了回滚 – 您可以随时使用“Git 还原”返回到以前的应用程序状态。借助 Git 出色的安全保证，您还可以使用 SSH 密钥对所有提交进行签名，从而对代码的作者身份和出处进行强有力的保证。这个版本存储的重要之处在于它是不可变的——换句话说，它不会随着时间的推移而改变。这对于建立审计跟踪非常有用。
#3.自动拉取：批准的更改会自动应用于系统
将声明的状态保留在 Git 中后，下一步是允许对该状态的任何更改自动应用于您的系统。这样做的重要一点是，您不需要群集凭据即可实现此目的。使用 GitOps，您可以访问定义状态之外的隔离环境。这使您可以区分您做什么和如何做。当然，有时您可能希望在某些部署类型之前包含手动审查步骤，而 GitOps 允许这样做。但是，我们的目标是让更改从 Git 到 Kubernetes 集群，如果它通过了所有自动化测试和检查，则无需人工接触或审查。策略对于启用此类自动化部署过程至关重要。
#4.持续协调：软件代理确保正确性并在出现分歧时发出警报
一旦系统状态被声明并受到版本控制，软件代理就可以在现实与您的期望不同时通知您。使用代理还可以确保您的整个系统能够自我修复。这不仅仅是节点或 Pod 故障（可由 Kubernetes 直接处理）来修复人为错误。在这种情况下，软件代理充当操作的反馈和控制循环。
了解 GitOps 如何在 GitOps 中推动运营：拉取请求和 GitOps 管道的操作，以及它如何使开发人员受益。
平台模型支持自助式开发人员体验
根据 2021 年 DevOps 现状报告，DevOps 已成熟为流对齐团队 （Dev） 和平台团队 （Ops） 的模型。GitOps 通过使平台团队能够构建和管理应用程序开发团队使用的内部平台来鼓励此模型。平台团队创建用于定义云计算、存储等资源的模板。开发人员在准备好将代码部署到生产环境时可以访问这些模板。开发人员选择一个预先批准的模板，并根据该模板中的配置部署其新代码。这样，开发人员可以专注于编写代码，而不是部署代码，而 Ops（或平台团队）可以放心，所有部署的代码都在他们预先批准的基础架构上运行。
GitOps 的主要优势
自动交付管道会在对 Git 进行更改时推出对基础结构的更改。但 GitOps 的思想远不止于此——它使用工具将整个应用程序的实际生产状态与源代码管理下的状态进行比较，然后告诉您集群何时与 Git 中声明的状态不匹配。
图：GitOps – 用于持续部署的以 Git 为中心的框架
通过应用 GitOps 最佳实践，您的基础架构和应用程序代码都有一个预定义的最终事实来源，让您的开发团队能够提高速度并提高系统可靠性。
为此，应用 GitOps 最佳实践的好处是深远的，因为它提供了：
1. 提高生产力
具有集成反馈控制回路的持续部署自动化可加快“平均部署时间”（MTTD）。团队每天可以发送 30-100 倍的更改，将整体开发输出提高 2-3 倍。
2. 增强的开发人员体验
使用 GitOps，您可以推送代码而不是容器。开发人员可以使用熟悉的工具（如 Git）更快地管理 Kubernetes 的更新和功能，而无需了解其内部工作原理。即使是新入职的开发人员也可以在几天而不是几个月内快速上手并提高工作效率。由于平台模型以及 GitOps 支持的自助服务开发人员体验，所有这些都成为可能。
3. 提高可听性
当您使用 Git 工作流管理集群时，您会自动获得 Kubernetes 外部所有集群更改的便捷审核日志。有关谁执行了哪些操作以及何时进入群集的审计跟踪可用于满足 SOC 2 合规性并帮助您确保稳定性。
4. 更高的可靠性
借助 Git 的还原和分叉功能，您可以获得稳定且可重现的回滚。此外，由于您的整个系统都是在 Git 中描述的，因此您还拥有单一事实来源，您可以在崩溃后从中恢复，从而将平均恢复时间 （MTTR） 从几小时缩短到几分钟。
5. 一致性和标准化
由于 GitOps 为您提供了一种用于进行基础架构、应用程序和 Kubernetes 附加组件更改的模型，因此如果需要，您可以在整个组织中提供一致的端到端工作流。不仅持续集成和持续部署 （CI/CD） 管道全部由拉取请求驱动，而且操作任务也可以通过 Git 完全重现。
6. 更坚固的安全护栏
Git 提供强大的正确性和安全护栏，由用于跟踪和管理更改的强大加密技术提供支持。这一点，再加上对更改进行签名以证明作者身份和来源的能力，是安全定义集群所需状态的关键。
7. 更快的开发
通过采用 GitOps 最佳实践，开发人员可以使用熟悉的工具（如 Git）更快地管理 Kubernetes 的更新和功能。通过不断推送功能更新，企业可以更加敏捷，可以更快地响应客户需求，并在市场上更具竞争力。
8.更好的运营
使用 GitOps，您可以拥有一个完整的端到端管道。不仅持续集成和持续部署管道都由拉取请求驱动，而且您的操作任务也可以通过 Git 完全重现。策略允许对流程进行无休止的自定义，同时不影响安全性和操作速度。
9. 更坚固的安全护栏
Git 强大的正确性和安全性保证，由用于跟踪和管理更改的强大加密技术提供支持，以及签署更改以证明作者身份和来源的能力，是正确和安全定义群集所需状态的关键。这与每个步骤的基于策略的自动审查一起，使 GitOps 成为保护软件交付管道的好方法。
如果确实发生了安全漏洞，可以使用不可变且可审计的事实来源来独立于受感染的系统重新创建新系统，从而减少停机时间并允许更好的事件响应。
打包软件并将其发布到生产环境之间的责任分离也体现了最小特权的安全原则，从而减少了入侵的影响并提供更小的攻击面。
10. 更轻松的合规和审计
由于以安全的方式跟踪和记录更改，因此合规性和审核变得微不足道。使用 GitOps 代理 Flux 可以将群集状态的可信定义与实际运行的群集进行比较，从而确保跟踪和可审核的更改与现实相符。
Puppet 每年发布的 DevOps 状态报告为我们提供了当时 DevOps 运动的近乎准确的脉搏。2021 年的报告强调了文化的重要性，以及通过使用平台方法明确定义角色和责任的必要性。GitOps 是实现这两个目标的最佳方式。
自助服务开发人员平台、策略即代码、渐进式交付和本地 GitOps 等理念将在应用程序和基础架构的部署和管理方面带来革命性的发展。无论 GitOps 朝哪个方向发展，Weave GitOps 都将把最新、最有效的 GitOps 理念融入一个易于使用的解决方案中。亲自尝试一下 Weave GitOps。
还想了解更多？这些文章充满了有用的信息，可帮助您更好地了解 GitOps：
GitOps 如何实现持续交付？
GitOps 构建和迭代了从 DevOps 和站点可靠性工程中汲取的想法，这些想法始于 Martin Fowler 在 2006 年的全面持续集成概述。
自由选择所需工具
作为 CI/CD 管道的工作流，GitOps 被描述为开发过程的圣杯。由于没有单一的工具可以完成 CICD 管道中所需的一切，因此 GitOps 使您可以自由地为不同部分选择最佳工具。您可以从开源生态系统或闭源中选择一组工具，或者根据您的用例，甚至可以组合它们。创建 CICD 管道最困难的部分是将所有部分粘合在一起。
无论您为交付管道选择什么，使用 Git（或任何版本控制）应用 GitOps 最佳实践都应作为流程不可或缺的组成部分。这样做将使过渡到持续交付变得更加容易。这不仅从技术角度来看是正确的，而且从文化角度来看也是如此。
“GitOps 正在改变行业的游戏规则。它是一个可复制的、自动化的、不可变的构造，你的变更管理，一切都发生在 Git 中。
GitOps 支持基础结构即代码 （IAC） 工具
Kubernetes 只是许多现代云原生工具的一个例子，这些工具是“声明性的”，可以被视为代码。声明式意味着配置由一组事实而不是一组指令来保证，例如，“有十个 Redis 服务器”，而不是“启动十个 Redis 服务器，并告诉我它是否有效”。
使用声明性工具，可以在 Git 中对整个配置文件集进行版本控制。通过使用 Git 作为事实来源，您的应用程序可以更轻松地部署和回滚到 Kubernetes 和从 Kubernetes 回滚。更重要的是，当灾难发生时，集群的基础设施可以可靠、快速地全部从 Git 中复制。
IAC 工具 vs. GitOps
可以按需配置服务器的基础结构即代码工具已经存在了相当长的一段时间。这些工具起源于保持基础结构配置的版本控制、备份和可从源代码管理重现的概念。
但是现在，由于 Kubernetes 几乎完全是声明式的，再加上不可变的容器，可以将其中一些概念扩展到管理应用程序及其操作系统。
管理和比较基础结构和应用程序的当前状态的能力是 GitOps 理念及其最佳实践的组成部分。采用 GitOps 后，您可以使用完整的审计跟踪来测试、部署、回滚和前滚代码 — 所有这些都来自 Git。这是可能的，因为 Kubernetes 几乎完全通过声明式配置进行管理，并且因为容器是不可变的。
在 GitOps 常见问题解答中详细了解基础结构即代码工具与 GitOps 的区别
如果我的系统偏离了事实来源怎么办？
声明性预配工具允许你在 Git 中描述所需的真实状态。但是他们遇到了一个问题，即“现在真正真实”的内容在实时系统中，这可能与源代码管理中描述的内容不同。
- 如何知道实时系统是否已收敛到所需状态？
- 当情况有所不同时，您会收到通知吗？
- 当你遇到麻烦时，“煤矿里的金丝雀”会告诉你什么？
- 如何触发群集和源代码管理之间的收敛？
Chef、Puppet 和 Ansible 等 IaC 工具支持“差异警报”等功能。这些可帮助操作员了解何时可能需要采取措施将实时系统“融合”到预期状态（由配置脚本定义）。最近，最佳实践是部署不可变的映像（例如容器），以便不太可能出现分歧。
在“GitOps”模型中，我们使用 Git 来解决发散和收敛问题，借助将预期状态与实际状态进行比较的 Flux 代理。
阅读 什么是真正的 GitOps？ 了解 GitOps 如何维护状态。
与 IAC 工具配合使用
GitOps 充分利用了向不可变基础结构和声明性容器编排的转变。为了最大限度地降低部署后的更改风险，无论是有意的还是意外的“配置漂移”，都必须保持可重现且可靠的部署过程。
将 GitOps 原则应用于“所有内容”（包括计算机配置、应用程序和服务以及警报规则和仪表板）时，所有这些都受源代码管理。GitOps 允许您定义管理每个组件的策略。这些策略可以通过软件工具进行审查，除非通过 Git，否则不需要访问正在运行的系统。任何一组更改都可以原子方式应用并相应地有所不同。然后，Git 记录不仅是审核日志，也是可用于来回回滚到任何快照的事务日志。
如何构建 GitOps 管道？
GitOps 管道由许多组件组成。以下是最常用于构建 GitOps 管道的工具：
- Git 托管服务：GitHub、GitLab、BitBucket
- 容器注册表：AWS ECR
- 构建服务器：詹金斯
- GitOps agent： Weave GitOps， Flux
- Kubernetes 配置自动化：Helm、Kustomize
- 策略即代码：编织 GitOps、OPA
- 服务网格：Istio、Linkerd
- 渐进式交付：旗手
- 容器编排：Kubernetes
- 监控：普罗米修斯、格拉法纳
图：GitOps 管道
这只是一个基本列表。实际上，您的管道可能看起来比这更长，具体取决于您的目标。虽然此列表乍一看可能令人生畏，但有一些现成的解决方案可以将这些工具以方便的方式组合在一起，以便您可以快速入门。让我们看看这些选项
拉流水线与推流水线
目前可用的大多数 CI/CD 工具都使用基于推送的模型。基于推送的管道意味着代码从 CI 系统开始，并可以通过一系列编码脚本继续其路径，或者手动使用“kubectl”将任何更改推送到 Kubernetes 集群。
您不想将 CI 系统用作部署动力或在命令行上手动执行此操作的原因是，可能会在群集外部公开凭据。虽然可以同时保护 CI/CD 脚本和命令行，但您是在群集的信任域之外工作。这通常不是好的做法，这就是为什么 CI 系统可以称为生产的攻击媒介。
在群集外部具有读/写权限的典型推送管道：
图：典型推送流水线
在 Weave GitOps 中，映像被拉取，凭据保存在集群内：
图：基于拉取的管道
我们可以使用的大多数 CI/CD 工具都基于基于推送的模型，其中代码从 CI 系统开始，经过一系列编码脚本，或者手动使用 ‘kubectl’ 将更改推送到 Kubernetes 集群。但是，使用一个人的 CI 系统作为部署动力并不总是被认为是一种好的做法，因为您在信任域之外工作。
另一方面，Weave GitOps 的拉取管道使用两个战略组件：负责监视映像注册表的部署自动操作和驻留在群集中以维护其状态的部署同步器。在这一切的中间，我们有一个单一的清单真相来源。
图：编织 GitOps 拉取管道
链接：
拉动管道
Weave GitOps 是一套开源持续交付工具，旨在在任何 Kubernetes 集群中运行应用程序。在后端，它由Flux提供支持，Flux是Weaveworks开发并捐赠给CNCF的领先GitOps代理。除了Flux之外，它还可以轻松集成到所有最常用的GitOps工具中。Weave GitOps在设置GitOps管道时非常易于使用和高效。
编织 GitOps 的拉动管道
Weave GitOps 使用由两个关键组件组成的拉取策略：监视映像注册表的“部署自动化器”和位于群集中以维护其状态的“部署同步器”。
拉取管道模式的核心是清单（或配置存储库）的单一事实来源。开发人员将更新的代码推送到代码库存储库;其中更改由 CI 工具拾取并最终构建 Docker 映像。Weave GitOps“部署自动化器”会注意到映像，从存储库中提取新映像，然后在配置存储库中更新其 YAML。然后，部署同步器检测到群集已过期，从配置存储库中提取更改的清单，并将新映像部署到群集。
编织 GitOps Enterprise
Weave GitOps Enterprise 将 Weave GitOps 提升到一个新的水平。它具有开源版本的 GitOps 的所有内置优势，并添加了许多旨在在企业级扩展 GitOps 的功能。它使 Kubernetes 更易于操作，并使您的团队能够交付快速安全的云原生应用程序。有了它，您可以使用策略自动执行平台配置，甚至可以将类似的集群堆栈部署到不同的环境。
Weave GitOps Enterprise 解决了第 2 天的操作问题。其先进的集群生命周期管理可处理从引导到维护、升级和修补的每个阶段，一直到跨多个云平台和本地机构的大规模集群队列管理。
Weave GitOps Enterprise 提供了一个功能齐全的 GitOps 系统，以及集成的可观测性和日志记录功能、GitOps 运行时和策略引擎。
Weaveworks如何帮助您？
Weaveworks 是 Weave GitOps 的创建者，Weave GitOps 是一款持续交付产品，用于运行和管理在 Kubernetes 中运行的应用程序。在其众多属性中，它简化了容器和微服务的部署监视和管理，并扩展和补充了流行的业务流程协调程序，使开发人员和 DevOps 团队能够进行更快的部署、有洞察力的监视、可视化和网络。
我们也是 CNCF OSS GitOps 项目（如 Flux 和 Flagger）的创建者和维护者，这些项目受到数千名客户的信任，可以帮助他们解决独特的用例。
但更重要的是，Weave GitOps 有自己多样化的用例集，这些用例肯定会解决您在组织中面临的基本挑战。阅读我们的博客文章《塑造 GitOps 的 6 个想法》了解更多信息。
此外，我们还是 AWS 战略合作伙伴，帮助他们加速采用 EKS。Weaveworks 还创建了 Eksctl，如今它是为 EC2 提供托管 Kubernetes 服务不可或缺的 CLI 工具。此外，Weaveworks是Microsoft Azure的重要合作伙伴，它在Microsoft GitOps部署中为Flux提供支持。
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/303663.html