共计 4199 个字符，预计需要花费 11 分钟才能阅读完成。
GitOps 提供一种自动化基础设施治理办法，曾经在泛滥团队中失去利用的 DevOps 最佳实际——包含版本控制、代码审查以及 CI/CD 流水线——都将被囊括于其中。目前，许多公司都在采纳 DevOps，看中的正是它在进步生产率和软件品质方面领有的微小后劲。在这一过程中，咱们曾经找到了自动化软件开发生命周期的办法。然而，当波及到基础设施的设置和部署时，手动操作的比重依然相当可观。有了 GitOps，团队就能够自动化基础设施配置过程。这是因为在 GitOps 办法中，咱们可能应用申明将基础设施编写为代码（IaC），而后像存储利用程序开发代码一样将基础设施即代码存储在 Git repo 当中。
GitOps 如何发挥作用？
GitOps 的概念最后是由 Kubernetes 治理公司 Weaveworks 所提出，因而对于 GitOps 的探讨次要是在 Kubernetes 的背景下进行的。随着整体设施转向运行在容器内的微服务架构，咱们天然须要更多可行的编排平台作为撑持。事实上，基于容器的应用程序也往往领有极为简单且难以治理的配置体系。GitOps 则通过利用在 DevOps 畛域曾经失去理论验证的技术，帮忙咱们简化了这一过程。现在，这一思路曾经在 DevOps 支持者中失去宽泛认可，也代表着 IaC 概念的降级模型。其中蕴含三大次要组成部分：
- 基础设施即代码
- Pull 申请
- CI/CD
上面具体来看。
基础设施即代码
IaC 是一种将基础设施以申明文件的模式进行配置和治理，并将其存储为代码的实际。通过利用 IaC 和版本控制，团队即可轻松优化所有的经营过程。GitOps 以 IaC 的申明性模型为外围，同时也为 Kubernetes 提供了良好的施展平台。申明性意味着配置更多关注指向预期状态的申明，而不是一组具体命令。例如，在 Kubernetes 中，你能够在 manifest 中定义服务所需的 Pod 数量。以此为根底，零碎将依据服务的运行状态主动为其提供 Pod，而不再由工程师编写固定的 Pod 配置数量。任何合乎申明式模型的云原生软件都能够被视为代码。咱们应用 AWS CloudFormation（一种申明性工具）来编写 AWS 基础设施，借此实现基础设施即代码准则。所需的状态将被申明为代码模式，零碎则利用更改以主动达到这一指标状态。当然，申明式模型并不是实现 GitOps 的惟一路径。大家也能够应用命令式定义环境实现雷同的经营成果。
Pull 申请
GitOps 概念背地的外围思路，是将版本控制系统视为繁多的主观起源。咱们应用 Git 作为利用程序代码的变更管理系统，也能够将其用于基础架构代码。所以所有的申明文件都托管在对立地位以供合作应用。在此基础之上，咱们得以应用 Git 的要害概念——操作更改的 pull 申请。在利用程序开发工作流中，咱们应用一个主分支作为公布分支。开发人员在主分支内创立性能分支。在开发一项特定的性能或故事之后，咱们创立一个 pull 申请以将其合并回主分支。同样的办法也能在基础设施代码中便捷起效。通过创立 pull 申请，咱们能够保障代码在被集成至代码库的另一个分支之前，首先通过残缺的代码审查流程。代码审查能够阻止低质量代码进入测试或生产环境，这一点对于基础架构代码来说尤为重要。通过代码审查取得正式的批准，也将有助于后续的审核和故障排查工作。
Git 组织
GitOps 的部署过程至多须要两个 repo：应用程序 repo 与环境配置 repo。前者蕴含应用程序的源代码及其部署 manifest；后者则蕴含了整个零碎所需的状态，该状态应用申明性标准来对环境中的各项因素加以形容。你能够在代码 repo 中将环境形容为开发、测试和生产环境，同时蕴含能够在该环境的特定版本中运行的应用程序和基础设施服务。在基础设施的状况下，主分支能够示意一个环境。咱们能够在性能分支中实现这些更改，而后创立一个 pull 申请来合并主分支中的变更。通过这种形式，咱们能够在实现合作的同时，以更加通明的形式理解谁执行了哪些更改。因为所有的更改都是在 Git 中提交实现，因而这也有利于跟踪引发问题的根本原因。GitOps 实用于任何基于 Git 的零碎，包含 GitHub、BitBucket 或 GitLab。其不依赖于任何特定工具或技术。
CI/CD
为了建设残缺的 GitOps 实现，你还须要一条 CI/CD 流水线。通过应用自动化的交付流水线，每当 Git 存储库中产生更改时，你都能够将基础设施更改交付到指定环境当中。这条流水线将你的 Git pull 申请连贯到业务流程零碎。当你应用 pull 申请触发流水线时，业务流程零碎将相应执行该工作。GitOps 的部署策略有两种形式：push 与 pull 流水线。二者的区别，次要体现在构建基础设施时所采取的环境部署形式之上。
Push 流水线
许多风行的 CI/CD 工具都在应用这种策略。咱们将应用程序的源代码及其部署 manifest 存储在一个 repo 当中。当利用程序代码中产生新的更新时，构建流水线将触发。流水线将构建容器镜像并将更改推送到环境。这种策略带来了更高的灵活性，足以反对任意类型的基础设施。当然，这种办法也有毛病，即容许 CI/CD 工具间接拜访你的环境。
Pull 流水线
社区普遍认为，pull 流水线办法对 GitOps 来说是一种更为平安的实际计划。这种办法引入引入了操作符。操作符属于流水线和业务流程工具之间的组件，它会一直将环境 repo 中的指标状态与已部署基础设施中的理论状态进行比拟。一旦检测到任何更改，则操作符会更改基础设施以适应环境 repo。此外，它还能够监控镜像仓库，辨认待部署的新版本镜像。正是这所有，让 GitOps 变得如此特地。在 GitOps 中，只有在环境 repo 中产生了更改时，才会引发环境更新。如果实现的基础设施以环境 repo 中未经定义的任何其余形式产生更改，零碎将复原所做的任何批改。大多数应用程序可能须要同时应用多个环境。GitOps 容许您创立多个能够更改环境 repo 的流水线。您能够在环境 repo 中应用独自的分支以治理更多环境。面对分支变更，运维人员能够在响应中将此项变更部署到生产环境当中，同时将来自另一分支的其余变更部署到测试环境。
GitOps 的劣势是什么？
DevOps 最佳实际
GitOps 是一套专一于现有 Git 工作流、IaC、CI/CD 流水线、不可变服务器、跟踪与可察看性最佳实际的模型，也代表着 Kubernetes 在云原生应用程序治理畛域的先进的理念。因而，其技术栈与操作体验可能切实为企业用户带来诸多助益。
继续部署——简化
继续部署意味着更快、更频繁的部署节奏。出于多种不同考量，例如零碎的有状态性、宕机弹性、上游 / 上游的依赖关系，以及组织内常见的其余过程与依赖项，很多敌人可能发现越来越难以建设适当的继续部署机制。GitOps 不仅可能实现继续部署，同时也让大家解脱了对大量工具计划的独自治理——这是因为所有操作都产生在版本控制系统之内。作为另一大助力，部署操作符则负责提供构造和自动化反对。这也进步了生产力并带来更快的 MTTD（均匀部署工夫）。自动化继续部署确保团队每天能够交付 30-100 倍以上的更改，将均匀生产效力进步 2 - 3 倍。
Rancher 2.5 通过 Rancher 继续交付（Continuous Delivery）简化了部署和治理。这是一项全新的性能，通过应用 Git 仓库主动存储和管理应用程序和配置信息，以确保部署的一致性，大大加重了客户的累赘，从而简化跨公有云、私有云、混合云或多云环境的部署流程。
Rancher 于 2020 年推出了海量集群治理我的项目 Fleet，这个我的项目成为了 Rancher 继续交付的引擎。Fleet 是一个 Kubernetes 集群控制器，旨在解决寰球内成千上万集群的挑战。
低 MTTR（均匀修复工夫）
MTTR 是 DevOps 团队须要掂量的要害指标之一。在微服务架构中，即便是极微小的问题也可能难以修复。因为 GitOps 将所有更改保留在版本控制系统中，同时辅以自动化管理手段，因而无望显著缩短 MTTR。你能够全面理解环境的变动过程，同时极大升高谬误复原难度。
简化 Kubernetes 治理
即便对 Kubernetes 不甚了解，开发人员能够应用相熟的工具 (如 Git) 轻松获取 Kubernetes 降级与性能实现。老手嵌入式开发人员可能很快跟上进度，将本来须要数月的适应期压缩到几天工夫。
改良企业整体的标准化程度
你能够在整个企业中建设起通明的端到端工作流，这要归功 GitOps 提供的用于出现应用程序、软件和 Kubernetes 附加组件批改的出现框架。Git 还可能全面重现你的各项操作流动。
利用 GitOps 的先决条件
建设稳固的代码审查与测试过程
深刻查看代码更改将帮忙咱们精确辨认某些重要操作，例如增加全局变量，借此避免低质量代码被公布到测试甚至生产环境当中。以此为根底，您能够通过 pull 申请提交验证过的代码，且严格禁止开发人员间接提交更改。一旦 pull 申请实现审查与合并，即可触发流水线。这是也保护高标准代码、进而加强零碎稳定性的第一步。
测试，测试，还是测试
GitOps 的染指意味着整个自动化程度都将晋升到新的高度，这也要求咱们对流水线公布的应用程序进行彻底测试。只管 GitOps 能帮忙咱们绝对轻松地实现回滚，但公布通过良好测试的高质量代码才是真正晋升过程可靠性的最佳路径。
监控为王
GitOps 可能重播操作过程，继续跟踪零碎状态并加以改进，最终据此执行公布与回滚。严格的监控体系能够帮忙你辨认并避免配置中呈现任何非预期的漂移与零碎更改。因而，在开始应用 GitOps 之前，请查看你的监控技能并着手增强，确保其有能力解决这种变动。
拥抱新文化
传统的流程束缚以及较长的公布工夫只会拖慢业务节奏。全面拥抱 DevOps 文化，意味着咱们该当全面利用最佳策略并帮忙团队了解开发和运维口头的价值。与此同时，开发与运维团队必须联手合作，建设起整体稳固的基础设施，更疾速、更顺畅地运行应用程序，进而晋升系统管理效率。而 DevOps 文化的欠缺将重大妨碍咱们享受 GitOps 带来的益处。
为什么采纳 GitOps？
GitOps 是一种弱小的工作流模式，能够帮忙您高效治理云基础设施。GitOps 能够为工程团队带来诸多劣势，极大加强零碎的协调能力、透明度、稳定性与持久性。
原文链接：https://microtica.com/blog/gi…
文章起源：分布式实验室，点击查看原文
