关于后端: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多平台公布