关于后端:GitOps指南

GitOps 基于 CICD 和 IaC，以统一的形式治理代码和部署，是 DevOps 最佳实际之一。本文残缺介绍了 GitOps 的理念和实际，并介绍了 Weave Cloud 的 GitOps 模型和工具，从整体上提供了实际 GitOps 的门路和计划。原文：Guide To GitOps^[1]

你是否据说过 GitOps？想不想晓得什么是 GitOps？本文将介绍 GitOps 工作流的准则和模式，以及如何用来在生产中规模化运行 Kubernetes。同时还将介绍 GitOps 和基础设施即代码 (IaC, infrastructure-as-code) 配置管理工具之间的差别，当然还将展现如何将 GitOps 最佳实际作为开发环境的一部分。

什么是 GitOps？

GitOps 在 2017 年被提出作为 Kubernetes 集群治理和利用交付的一种形式，利用 Git 作为申明性基础设施和应用程序的繁多实在源（single source of truth）。在 GitOps 中，集群中运行的软件代理能够在运行状态和 Git 产生任何差别时收回告警，Kubernetes 协调器会依据状况自动更新或回滚集群。Git 作为交付流水线的核心，开发人员能够应用相熟的工具收回 pull request，从而减速和简化 Kubernetes 的利用部署和操作工作。

构建云原生应用程序的运维模型

GitOps 能够概括为以下两点:

1. Kubernetes 和其余云原生技术的运维模型，提供了一套最佳实际，用于对立容器化集群和应用程序的 Git 部署、治理和监控。
2. 利用开发人员的教训管理应用程序的门路，将端到端 CICD 流水线和 Git 工作流利用于运维和开发。

GitOps 原理

要开始应用 GitOps 工作流治理集群，必须具备以下条件:

1. 整个零碎以申明的形式形容。

有了 Gitops, Kubernetes 只是许多古代云原生工具中的一种，这些工具都是“申明式的”，能够被视为代码。申明式意味着配置是由一组事实而不是一组指令来保障的。在 Git 中对应用程序的申明进行版本化后，就有了惟一的实在起源，应用程序能够在 Kubernetes 上轻松部署和回滚。更重要的是，当产生问题时，集群基础设施也能够牢靠的疾速复制。

2. 在 Git 中对系统状态进行版本控制。

通过将零碎申明存储在版本控制系统中，并作为标准的实在起源，就有了惟一的中央派生和驱动所有货色。这种形式淡化了回滚，能够应用“Git revert”返回到之前的利用状态。基于 Git 杰出的平安保障，还能够应用 SSH 密钥对提交进行签名，以增强对代码作者和出处的平安验证。

3. 可主动将已批准的变更利用于零碎。

将申明的状态保留在 Git 之后，下一步是容许在零碎中主动利用状态的任何变更。重要的是，不须要认证就能够对系统进行更改。在 GitOps 中，环境是隔离的，状态定义位于环境之外，从而辨别要做什么和要怎么做。

4. 软件代理确保正确性并在状态不统一时收回告警。

一旦零碎状态被申明并处于版本控制之下，当理论状况与冀望不匹配时，软件代理就会发出通知。应用代理还能够确保整个零碎可能自我修复。对于自我修复，指的不仅仅是节点或 pod 生效（这些由 kubernetes 解决），而是具备更宽泛的意义，比方在人为谬误等。在这种状况下，软件代理充当了操作的反馈和管制循环。

延长浏览：\
Getting Started with Weave GitOps Core^[9] \
GitOps: Operations by Pull Request^[10] \
The GitOps Pipeline – Part 2^[11] \
GitOps:‘Git Push’all the things (The New Stack)^[12] \
The Best CI/CD Tool for Kubernetes Doesn’t Exist^[3] \
The full history of GitOps 2017-2020^[13]

GitOps 的次要益处

当 Git 产生更改时，自动化的交付流水线将对基础设施进行更改。然而 GitOps 的思维远不止于此，GitOps 应用工具来比拟整个应用程序的理论生产状态与源代码管制下的状态，而后当集群状态与冀望不匹配时，就会发出通知。

通过利用 GitOps 最佳实际，基础设施和利用程序代码都有惟一“实在起源”，容许开发团队进步速度并且进步系统可靠性。

延长浏览：\
Operate Kubernetes the GitOps Way^[14]

利用 GitOps 最佳实际有很多益处:

1. 进步生产力
   集成反馈管制回路的自动化继续部署放慢了均匀部署工夫，帮忙团队将每天可交付的变更晋升 30-100 倍以上，进步总体开发产出 2 - 3 倍。
2. 加强研发体验
   推送代码而不是容器，开发人员能够应用 Git 等相熟的工具更快治理 Kubernetes 的更新和个性，而无需理解 Kubernetes 的外部状况。新入职的开发人员能够在几天内 (而不是几个月) 迅速晋升速度并进步生产率。
3. 加强稳定性
   当咱们用 Git 工作流来治理集群时，会主动取得 Kubernetes 之外的所有集群变更的审计日志。对何人、在何时、对集群做了什么进行审计跟踪，能够听从 SOC 2 的要求并确保稳定性。
4. 更高的可靠性
   借助 Git 的复原 / 回滚和 fork 性能，能够取得稳固和可反复的回滚。因为整个零碎都在 Git 中形容，所以在解体后，也有惟一的实在起源来复原，能够将复原工夫 (MTTR) 从几个小时缩小到几分钟。
5. 一致性和标准化
   因为 GitOps 为基础设施、应用程序和 Kubernetes 附加组件的更改提供了对立的模型，因而能够在整个组织中领有统一的端到端工作流。不仅继续集成和继续部署流水线都是由 pull request 驱动的，而且运维工作也齐全能够通过 Git 重复触发。
6. 弱小的平安保障
   Git 弱小的正确性和安全性保障，用于跟踪和治理更改的弱小加密技术的反对，以及为变更签名以证实作者和起源的能力，是平安定义所需集群状态的要害。

GitOps 是继续交付与云原生的联合

GitOps 基于 DevOps 和站点可靠性工程（Site Reliability Engineering）的想法进行构建和迭代，始于 Martin Fowler 在 2006 年发表的全面的继续集成概述^[2]。

自由选择须要的工具

作为 CI/CD 流水线的工作流，GitOps 被形容为开发过程的圣杯^[3]。因为没有一个工具能够实现 CICD 流水线中须要的所有工作，所以 GitOps 容许自在的为不同局部抉择最佳的工具。依据特定用例，能够从开放源码生态系统或关闭源码中抉择一组工具，甚至能够组合应用。创立 CICD 流水线最艰难的局部是将所有局部交融在一起。

无论抉择什么工具构建交付流水线，利用 Git(或任何版本控制)的 GitOps 最佳实际都应该是这一流程中不可或缺的组成部分，从而更容易过渡到继续交付。不仅从技术角度看是这样，从文化角度看也是如此。

GitOps: 在申明性基础设施之上的版本化 CI/CD。进行编写脚本，开始交付。https://t.co/SgUlHgNrnY – Kelsey Hightower (@kelseyhightower) 2018 年 1 月 17 日

Git 反对基础设施即代码 (IaC) 工具

Kubernetes 只是许多古代云原生工具之一，这些工具都是“申明性的”，能够被视为代码。申明性意味着配置是由一组事实来保障的，而不是一组指令，例如，“有 10 个 redis 服务器”，而不是“启动 10 个 redis 服务器，而后通知我它是否工作”。

应用申明性工具，整个配置文件集能够在 Git 中进行版本控制。通过应用 Git 作为实在的起源，应用程序更在 Kubernetes 上容易部署和回滚。更重要的是，当产生问题时，集群基础设施能够牢靠、疾速的从 Git 中重建。

IaC 工具 vs GitOps

基础设施即代码作为可按需配置服务器的工具曾经存在很长一段时间了，这些工具起源于通过代码管制工具保护基础架构配置的版本、备份和可复制的概念。

但当初 Kubernetes 简直齐全是申明式的，再加上不可变的容器，能够将这些概念扩大到管理应用程序及其操作系统。

Git 可能治理和比拟基础设施和应用程序的以后状态，从而通过残缺的审计跟踪进行测试、部署、回滚和前滚，这蕴含了 GitOps 哲学及其最佳实际。因为 Kubernetes 简直齐全通过申明式配置进行治理，而且容器是不可变的，让这所有成为可能。

咱们通过 Terraform 和 Ansible 来配置服务器，在 Git 中对这些配置文件进行备份和版本控制。IaC 工具及其相干配置文件形成了 GitOps 工作流的外围，以便在产生问题时，可能近乎实时的复原集群。能够在 GitOps FAQ^[4]中理解更多对于作为代码工具的基础设施与 GitOps 的不同之处。

如果零碎偏离了实在起源怎么办?

申明性配置工具容许咱们在 Git 中形容所需的实在状态，然而会遇到这样的问题:“当初真正正确的”状态存在于实在零碎中，而这可能与版本控制中形容的不同。

• 怎么晓得实在零碎是否收敛到冀望状态?
• 当状态不同时能收到告诉吗?
• 遇到麻烦时，收回告警的“煤矿里的金丝雀”是什么?
• 如何触发集群和源代码管制之间的聚合?

这些有现成解决方案。

像 Chef, Puppet 和 Ansible 等 IaC 工具反对“差别揭示”等性能，帮忙运维人员了解什么时候可能须要采取行动，将实在零碎“聚合”到预期的状态(由配置脚本定义)。最近，最佳实际是部署不可变镜像(例如容器)，因而分化的可能性较小。

在“GitOps”模型中，应用 Git 来解决一致以及收敛状态，并借助一组“diff”和“sync”工具 (kubediff^[5]，以及 terradiff 和 ansiblediff) 来比拟预期状态和理论状态。

基于不可变基础设施构建 GitOps

GitOps 充分利用了不可变基础设施和申明式容器编排，为了最小化部署后变更的危险，无论是无意的还是因为“配置漂移”引起的意外，都必须保护一个可重现的、牢靠的部署过程。

Git 形容了整个零碎的冀望状态(也就是“实在起源”)。咱们基于容器实现不变性，应用不同的云原生工具，如 terrform 和 Ansible 来自动化和治理配置。这些工具与容器和 Kubernetes 的申明性个性一起帮忙咱们实现了当产生问题时能够完全恢复整个集群的能力。

延长浏览: \
GitOps for Kubernetes: A DevOps Iteration Focused on Declarative Infrastructure^[15] \
Why we use Terraform and not Chef, Puppet, Ansible, SaltStack, or CloudFormation^[16] \
What is GitOps Really?^[17]

应用 IaC 工具

将 GitOps 准则利用于“所有”时，除了告警规定和仪表板之外，还包含机器配置、应用程序和服务，所有这些都处于源代码管制之下。

除非通过 Git，否则不须要拜访运行中的零碎。任何一组更改都能够被原子的利用，并相应的加以辨别。Git 记录不仅是审计日志，也是事务日志，能够用来回回滚到任何快照。

延长浏览: \
Weaveworks & AWS; How we manage Kubernetes clusters^[18] \
Provisioning and Lifecycle of a Production Ready Kubernetes Cluster^[19] \
GitOps FAQ^[4]

Weave Cloud 中的继续交付和 GitOps 工作流

在咱们的产品 Weave Cloud^[6]中，GitOps 的外围机制集成在 CI/CD 工具中，要害局部是反对 git 集群同步 ^[7] 的继续部署(CD)。

Weave Cloud 是专为版本控制系统和申明式应用程序栈设计的。团队中的每个开发人员可能都相熟 Git，能够收回 pull requet，当初他们也能够应用 Git 来减速和简化 Kubernetes 的利用部署。

上面是一个典型的开发人员创立或更新新个性的工作流程:

1. 一个新性能的 pull request 会被推送到 GitHub 进行审核。
2. 代码由共事审核和批准。在批改代码并从新批准之后，将其合并到 Git 中。
3. Git 合并触发 CI 和构建管道，运行一系列测试，最终构建一个新镜像，并存储到镜像仓库中。
4. Weave Cloud“Deployment Automator”监控镜像仓库，发现新镜像后，从仓库中提取新镜像并在配置仓库中更新 YAML。
5. Weave Cloud“Deployment Synchronizer”(装置在集群中)检测到集群已过期，从配置仓库中提取更改的 manifests，将新个性部署到生产环境中。

启用了 GitOps 的 CICD 流水线：

基于 Operator 模式实现的 Kubernetes 控制器

Weave Cloud 实现了自定义控制器来监听和同步 Kubernetes 集群的部署。控制器采纳 Operator 模式实现，Operator 模式有两个长处：首先是更平安；其次，自动化了简单的、容易出错的工作，比方手动更新 YAML manifests。

通过应用 Operator 模式，代理代表集群侦听与自定义资源更改相干的事件，以便利用这些事件。代理负责将 Git 中的内容与集群中运行的内容同步，并为团队提供了一种实现继续部署的简略办法。

延长浏览: \
Comparing Kubernetes Operator Pattern with Alternatives^[20] \
Introducing Operators: Putting Operational Knowledge into Software^[21] \
CI/CD for Kubernetes: what you need to know^[22]

Pull 流水线 vs Push 流水线

Push 流水线

目前可用的大多数 CI/CD 工具都基于 push 模型。基于 push 的流水线意味着代码从 CI 零碎开始，通过一系列脚本解决，或者手工应用 ’kubectl‘ 将更改推送到 Kubernetes 集群。

咱们不心愿应用 CI 零碎触发部署或在命令行上手动进行部署的起因是，这可能须要在集群外公开验证凭据。尽管能够同时爱护 CI/CD 脚本和命令行，但在集群的信赖域之外工作，通常不是良好的实际，这就是为什么 CI 零碎能够被认为是生产零碎的攻打媒介。

集群内部具备读写权限的典型 push 流水线:

在 Weave Cloud 中，image 被拉取(pull)，凭据被保留在集群中:

Weave Cloud Pull 流水线

Weave Cloud 应用 pull 策略，该策略由两个要害组件组成: 监督镜像仓库的“Deployment Automator”和位于集群中保护其状态的“Deployment Synchronizer”。

Pull 流水线模式的核心具备繁多实在源的 manifests(或配置仓库)。开发人员将更新的代码推送到代码库中，CI 工具提取这些变更的代码并构建 Docker 镜像。Weave Cloud 的“Deployment Automator”发现并从镜像仓库中提取新镜像，而后在配置文件中更新 YAML。而后 Deployment Synchronizer 检测到集群过期，从配置仓库中提取更改后的 manifests，并将新镜像部署到集群。

在集群中部署 Weave Cloud 代理

应用集群中的 Deployment synchronizer，集群凭据不会公开到生产环境之外。一旦在集群中装置了 Weave Cloud 代理并连贯上 Git 仓库，就能够通过 Git pull request 实现生产环境的任何变更，并且能够利用 Git 提供的残缺的回滚以及不便的审计日志。

延长浏览: \
How secure is your pipeline?^[23]

可察看性是部署的催化剂

有了 Kubernetes, GitOps 能够通过 pull request 治理基础设施和应用程序部署。然而 GitOps 工作流和可察看性是如何协同工作的呢?

通过将 GitOps 工作流与实时可察看性相结合，开发团队能够在部署任何新个性之前做出要害决策。行将公布的服务能够在公布之前在运行的集群中实时察看到，这意味着能够释怀部署并更快交付品质更好的个性。

可察看性能够被视为 Kubernetes 继续交付 ^[8] 周期的次要驱动因素之一，形容了零碎在任何给定工夫的理论运行状态。察看运行中的零碎是为了理解和管制它。新个性和修复被推送到 git 并触发部署流水线，当筹备好公布时，能够在运行的集群上实时察看。此时，开发人员能够依据反馈返回到流水线的终点，或者部署镜像并将其公布到生产集群。

GitOps 是面向公布的运维和个性模型。向客户交付新个性的速度，肯定水平上取决于团队在这个周期中实现各个阶段的速度。

同时应用 GitOps 工作流和可察看性的开发人员须要答复以下问题:

1. 如果一个变更是主动公布的，咱们怎么晓得它真的工作了?
2. 咱们如何能确定变更真的让产品更好?
3. 在简单的分布式系统中，如何了解问题、诊断问题和处理事件?

通过 Weave Cloud，在部署和公布过程中集成可察看性工作负载指示板，在承诺将部署公布到预发或生产环境之前，能够一眼看出部署是否胜利。不仅能够帮忙咱们更快辨认问题，而且因为可察看性工作负载指示板是实时的，并且内置在部署流程中，因而能够每天部署屡次服务，并确信部署没有重大缺点。

延长浏览: \
GitOps Observability^[24] \
Monitoring Kubernetes with Prometheus^[25]

GitOps 的益处

更快的开发

通过采纳 GitOps 最佳实际，开发人员能够应用相似 Git 这样的相熟工具更快治理 Kubernetes 的更新和个性。通过一直推动性能更新，企业更加麻利，可能更快响应客户需要，并在市场上更具竞争力。

更好的运维

有了 GitOps，就有了残缺的端到端流水线，不仅继续集成和继续部署流水线都是由 pull request 驱动，而且运维工作也能够通过 Git 齐全重现。

如果应用 Weave Cloud，部署到正在运行的集群也是平安的，不会将敏感认证凭据泄露到集群之外。

更强的平安保障

Git 弱小的正确性和安全性保障，用于跟踪和治理变更的弱小加密技术反对，以及签名变更以证实作者和起源的能力，是正确和平安定义集群所需状态的要害。如果的确产生了安全漏洞，能够应用不可变和可审计的实在起源，独立于受损的零碎从新创立新零碎，缩小停机工夫，提供更好的问题响应。

将零碎构建和生产环境公布之间的责任拆散，体现了最小特权的平安准则，缩小了斗争的影响并提供了更小的攻击面。

更容易遵循标准并不便审计

因为以一种平安的形式跟踪和记录更改，遵循标准和审计就变得很容易了。应用像 kubediff、terradiff 和 ansiblediff 这样的比拟工具，容许将集群状态的可信定义与理论运行的集群进行比拟，确保被跟踪和可审计的更改与事实相匹配。

延长浏览: \
Try GitOps out for yourself^[26] \
GitOps: High velocity CICD for Kubernetes^[27] \
GitOps workflows with Weave Cloud – Tutorial^[28] \
How to Boost Business Performance with GitOps: The Facts^[29] \
Multi-cloud Strategies with Kubernetes and GitOps^[30]

References: \
[1] Guide To GitOps: https://www.weave.works/technologies/gitops/ \
[2] Continuous Integration: https://martinfowler.com/articles/continuousIntegration.html \
[3] The Best CI/CD tool for Kubernetes Doestn’t Exist: https://thenewstack.io/the-best-ci-cd-tool-for-kubernetes-doe… \
[4] GitOps FAQ: http://www.weave.works/technologies/gitops-frequently-asked-q… \
[5] Kubediff: https://github.com/weaveworks/kubediff \
[6] Weave Cloud: https://cloud.weave.works/signup \
[7] Automated Git Cluster Synchronisation: https://github.com/fluxcd/flux/blob/master/docs/introduction.md#automated-git-cluster-synchronisation \
[8] Continuous Delivery: https://continuousdelivery.com/ \
[9] Getting Started with Weave GitOps Core: https://vimeo.com/676402260?embedded=true&source=video_title&… \
[10] GitOps: Operations by Pull Request: https://www.weave.works/blog/gitops-operations-by-pull-request \
[11] The GitOps Pipeline – Part 2: https://www.weave.works/blog/the-gitops-pipeline \
[12] GitOps:‘Git Push’all the things (The New Stack): https://thenewstack.io/gitops-git-push-all-the-things \
[13] The full history of GitOps 2017-2020: https://assets.contentstack.io/v3/assets/blt300387d93dabf50e/… \
[14] Operate Kubernetes the GitOps Way: https://vimeo.com/315294468?embedded=true&source=video_title&… \
[15] GitOps for Kubernetes: A DevOps Iteration Focused on Declarative Infrastructure: https://thenewstack.io/gitops-kubernetes-devops-iteration-foc… \
[16] Why we use Terraform and not Chef, Puppet, Ansible, SaltStack, or CloudFormation: https://blog.gruntwork.io/why-we-use-terraform-and-not-chef-p… \
[17] What is GitOps Really? https://www.weave.works/blog/what-is-gitops-really \
[18] Weaveworks & AWS; How we manage Kubernetes clusters: https://www.weave.works/technologies/weaveworks-on-aws \
[19] Provisioning and Lifecycle of a Production Ready Kubernetes Cluster: https://www.weave.works/blog/provisioning-lifecycle-productio… \
[20] Comparing Kubernetes Operator Pattern with Alternatives: https://medium.com/@cloudark/why-to-write-kubernetes-operator… \
[21] Introducing Operators: Putting Operational Knowledge into Software: https://coreos.com/blog/introducing-operators.html \
[22] CI/CD for Kubernetes: what you need to know: https://www.weave.works/technologies/ci-cd-for-kubernetes \
[23] How secure is your pipeline? https://www.weave.works/blog/how-secure-is-your-cicd-pipeline \
[24] GitOps Observability: https://www.weave.works/blog/gitops-part-3-observability \
[25] Monitoring Kubernetes with Prometheus: https://www.weave.works/technologies/monitoring-kubernetes-wi… \
[26] Try GitOps out for yourself: https://www.weave.works/product/gitops-core \
[27] GitOps: High velocity CICD for Kubernetes: https://www.weave.works/blog/gitops-high-velocity-cicd-for-ku… \
[28] GitOps workflows with Weave Cloud – Tutorial: https://www.weave.works/blog/gitops-workflows-for-istio-canar… \
[29] How to Boost Business Performance with GitOps: The Facts: https://go.weave.works/DORA_GitOps_WP.html?LeadSource=Web%20C… \
[30] Multi-cloud Strategies with Kubernetes and GitOps: https://go.weave.works/2021_multi_cloud_strategies_wp.html?Le…

你好，我是俞凡，在 Motorola 做过研发，当初在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓重的趣味，平时喜爱浏览、思考，置信继续学习、一生成长，欢送一起交流学习。\
微信公众号：DeepNoMind

本文由 mdnice 多平台公布