共计 3598 个字符，预计需要花费 9 分钟才能阅读完成。
GitOps 提供了一种自动化和治理基础设施的办法。它通过许多团队曾经利用的 DevOps 最佳实际来做到这一点，例如版本控制、代码评审和 CI/CD 管道。
因为 DevOps 在进步生产率和软件品质方面的微小后劲，许多公司始终采纳 DevOps。在这个过程中，咱们曾经找到了自动化软件开发生命周期的办法。然而，在基础设施设置和部署方面，它依然次要是一个手动过程。
应用 GitOps，团队能够自动化基础设施配置过程。这是因为能够应用申明文件将根底构造编写为代码（IaC）。咱们能够将它们存储在 Git 存储库中，就像存储利用程序开发代码一样。
GitOps 是如何运作的？
GitOps 的概念最后是由 Kubernetes 治理公司 Weaveworks 提出的。所以对于 GitOps 的探讨次要是在 Kubernetes 的背景下进行的。向在容器中运行的微服务的转换带来了对编排平台的需要。基于容器的应用程序的供给和治理可能很简单，也很艰难。GitOps 通过利用已在 DevOps 世界中验证过的技术来帮忙简化这一点。
现在，这个想法在 DevOps 的爱好者中很风行，代表了 IaC 概念的降级模型。它围绕三个次要局部开展：
基础设施即代码
拉取申请
CI/CD
基础设施即代码
IaC 是一种将基础设施作为申明文件（存储为代码）提供和治理的实际。通过利用 IaC 和版本控制团队能够优化所有的操作过程。
GitOps 以 IaC 的申明式模型为核心。这就是为什么 Kubernetes 是一个很好的实现示例。申明性意味着配置更多的是对预期状态的申明，而不是一组命令。例如，在 Kubernetes 中，您能够在清单中定义服务所需的 pods 数量。零碎会自行处理。工程师不须要编写可能达到所需 pod 编号的命令式脚本。
任何合乎申明式模型的云本地软件都能够被视为代码。咱们应用 AWS CloudFormation 来编写 AWS 基础设施，这是一个申明性工具。这意味着咱们能够将基础设施自身视为代码。将所需状态申明为代码。零碎利用变更来实现自动化状态。
话虽如此，申明式模型在 GitOps 中并不是必须的。命令式定义的环境也能够这样做。
拉取申请
GitOps 概念背地的次要思维是版本控制系统是事实的惟一起源。咱们应用 Git 作为利用程序代码的变更管理系统。咱们还能够在基础设施代码中应用它。因而，整个申明文件集都在一个能够合作的中央。这使咱们可能应用 Git 的要害概念——操作更改的 pull 申请。
在利用程序开发工作流中，咱们应用一个主分支作为公布分支。开发人员从主分支创立性能分支。开发一个特定的个性或故事，实现后创立一个 pull 申请，将其合并回主分支。同样的办法对于根底构造代码也很不便。
在咱们将代码集成到代码基的另一个分支之前，创立一个 pull request 使代码可能通过一个代码审查过程。代码查看能够阻止坏代码进入测试或生产环境。这对于基础架构代码甚至更为重要。通过代码审查取得正式的批准对审计和故障排除有很大帮忙。
Git 组织
GitOps 中的部署过程至多须要两个 repo：应用程序 repo 和环境配置 repo。第一个蕴含应用程序的源代码及其部署清单。第二个蕴含对每个环境应用申明性标准形容的整个零碎的冀望状态。您能够将您的环境形容为代码存储库中的开发、测试、生产，其中蕴含能够与该环境的特定版本一起运行的应用程序和基础设施服务。
在基础设施的状况下，次要分支能够示意一个环境。咱们能够在个性分支中实现变更。而后创立一个 pull request 来合并主分支中的更改。通过这种形式，咱们能够实现合作，同时对谁执行了哪些更改放弃通明。这也有利于问题跟踪到本源，因为所有更改都是在 Git 中提交的。
GitOps 可用于任何基于 Git 的零碎，如 GitHub、BitBucket 或 GitLab。它不依赖于任何工具或技术。
CI/CD
要实现残缺的 GitOps，您须要一个 CI/CD 管道。应用主动交付管道，每次 Git 存储库中产生更改时，您都能够将根底构造更改传递到指定的环境中。
这里的管道用于将 Git pull 申请连贯到编排零碎。当您应用 pull 申请触发管道时，业务流程零碎将执行该工作。
GitOps 部署策略有两种可能:push 管道和 pull 管道。它们之间的区别在于确保部署环境与所需的基础设施类似的形式。
Push 管道
许多风行的 CI/CD 工具都在应用这种策略。咱们将应用程序的源代码及其部署清单存储在一个存储库中。当利用程序代码中产生新的更新时，生成管道将触发。管道构建容器映像并将更改推送到环境中。这种策略带来了更大的灵活性，因为它能够反对任何类型的基础设施。毛病是它容许 CI/CD 工具拜访您的环境。
基于 push 的 DevOps 部署
Pull 管道
社区认为 Pull 管道办法对 GitOps 来说更平安的实际。通过这种办法，引入了运算符。操作符是管道和编配工具之间的一个组件。它一直地将环境存储库中的指标状态与部署基础设施中的理论状态进行比拟。操作员如果检测到任何更改，就更改根底构造以适应环境存储库。另外，还能够监督映像注册表，以确定要部署的映像的新版本。这就是 GitOps 如此特地的起因。
基于 pull 的 DevOps 部署
在 GitOps 中，只有在环境存储库中产生更改时才会进行环境更新。如果实现的基础设施以未在环境存储库中定义的任何形式更改，零碎将复原所做的任何批改。
对于大多数应用程序，您可能须要多个环境。GitOps 容许您创立多个能够更改环境存储库的管道。您能够在环境存储库中应用不同的分支来治理更多的环境。操作员能够通过部署到生产环境来响应一个分支的更改，也能够通过部署到测试来响应另一个分支。
GitOps 的劣势何在？
应用 DevOps 最佳实际
因为 GitOps 是一个专一于 Git 工作流、IaC、CI/CD 管道、不可变服务器、跟踪和可察看性等现有最佳实际的模型，它代表了 Kubernetes 云原生应用程序治理的更高级状态。因而，公司目前的教训和教训能够提供很多服务。
继续部署—简化
继续部署意味着更快、更频繁地部署。因为不同的思考因素，如零碎的状态性、抗停机能力、上游 / 上游依赖关系以及许多其余组织相干流程和依赖关系，正确的继续部署始终十分具备挑战性。
GitOps 容许您这样做，而不用治理一堆工具，因为所有的事件都产生在版本控制系统中。因为应用了部署操作，它提供了构造和自动化。
这也进步了生产率和更快的 MTTD（均匀部署工夫）。自动化的继续部署确保团队每天能够公布 30-100 倍的更改，从而将均匀生产性能进步 2 - 3 倍。
升高均匀修复工夫（MTTR）
MTTR 是 DevOps 团队应该度量的要害指标之一。在微服务体系结构中，即便是很小的问题也很难修复。因为 GitOps 在版本控制系统中保留了所有更改，并且治理是自动化的，因而能够显著升高 MTTR。您曾经全面理解了环境是如何变动的，并且谬误复原变得非常容易。
简化 Kubernetes 治理
在不深刻理解 Kubernetes 的状况下，开发人员能够应用相熟的工具（如 Git）来更轻松地解决 Kubernetes 的降级和个性。新的嵌入式开发人员将很容易跟上速度，并在几天内而不是几个月内沉闷起来。
改良了整个公司的标准化
因为 GitOps 有一个用于出现应用程序、软件和 Kubernetes 附加批改的框架，所以在整个企业中都有通明的端到端工作流。Git 还能够齐全复制操作流动。
如何筹备 GitOps？
建设一个稳固的代码评审和测试过程。仔细检查代码更改能够指出一些显著的操作，例如增加全局变量。它能够避免坏代码被开释。而后，您能够通过 pull 申请提交通过验证的代码，不容许开发人员间接提交任何更改。一旦申请被检查和合并，就能够触发管道。这是保护高标准代码和随后零碎稳定性的第一步。
退出 GitOps 意味着领有高水平的自动化，这须要对管道公布的应用程序进行彻底的测试。只管 GitOps 容许绝对容易地回滚，但公布通过良好测试用例的好代码会使流程更加牢靠。
重点监控
GitOps 容许可反复的操作过程，改良可跟踪的零碎状态、公布和回滚。认真的监督能够帮忙您辨认和避免配置中任何意外的偏移和零碎更改。所以，在开始应用 GitOps 之前，回顾一下你的监控技能，并增强你的监控能力，让他们可能应答这种变动。
承受文化
具备长公布工夫的传统流程束缚只会妨碍您。采纳 DevOps 文化意味着利用最好的策略，帮忙团队了解开发和经营口头的价值。与此同时，它们必须一起合作，以创立一个整体稳固的基础设施，更快、更安稳地执行应用程序，并无效地管理系统。不足 DevOps 文化会障碍你享受 GitOps 的益处。
为什么是 GitOps？
GitOps 是一种十分好的工作流模式，它能够帮忙你高效地解决云基础设施。GitOps 能够为工程团队提供许多劣势，包含更好的协调、透明度、稳定性和零碎的耐用性。
原文链接：https://dzone.com/articles/gi…
