GitOps初阶指南:将DevOps扩展至K8S

标签: gitops devops 扩展 | 发表时间:2020-07-30 18:38 | 作者:Rancher
出处:http://weekly.dockone.io

本文转自 Rancher Labs

在过去十年的编程中,出现了一些革命性的转变。其中之一是源于围绕DevOps的实践,它将开发和运维团队整合到一个共享的工作流程中,此外还有持续集成和持续交付(CI/CD),通过CI/CD,Devops团队可以向代码库提供持续的更新。另一个变革来自于从单体代码库到基于云的微服务的迁移,这些微服务运行在由Kubernetes等编排平台管理的容器中。

即使有Kubernetes这样的平台来编排协调,在集群系统或云端运行的基于容器的应用程序依旧可能是复杂的、难以调配和管理的。GitOps是一套新兴的实践,旨在通过应用Devops和CI/CD世界的技术来简化这一管理任务。

GitOps的关键是基础设施即代码(IaC)的理念,它采用与DevOps用于提供应用程序一样的方法来提供基础设施。所以,不仅是应用,还有底层的主机和网络都被描述在文件中,这些文件可以像版本控制系统中的其他代码一样,然后由自动化流程来将现实世界的应用与这些文件中描述的应用进行融合。



用GitOps的说法,版本控制系统中的代码是关于应用在生产中应该是什么样子的唯一真相来源(single source of truth)。

定义GitOps

Weaveworks是在GitOps概念普及方面贡献最大的公司。稍后我们会详细介绍Weaveworks在其中扮演的角色,但首先,我们先来看看该公司对GitOps的定义,它有两个方面:

  • Kubernetes和其他云原生技术的运维模式,为统一部署、管理和监控容器化集群和应用提供了一套最佳实践。

  • GitOps是一条通往管理应用的开发者体验之路;在这里,端到端的CI/CD流水线和Git workflow可以同时应用于运维和开发。


换句话说,GitOps是一套特定的实践,旨在管理Kubernetes和类似的平台。随着越来越多的开发团队采用DevOps实践,并将代码迁移到云端,GitOps也将会适合更广泛的应用。但要了解GitOps的秘诀和它所能解决的问题,我们需要谈谈它的组成部分。

Git定义

在GitOps中Git指的是由Linus Torvalds在2005年开发的极为流行的分布式版本控制系统。Git是一个工具,它允许开发者团队在一个应用程序代码库上共同工作,存储各种代码分支,在将它们合并到生产代码之前,他们可以对这些代码进行修补。Git 的一个关键概念是拉取请求,即开发人员正式要求将他们正在编写的一些代码整合到代码库的另一个分支中。

Git 拉取请求为团队成员提供了一个协作和讨论的机会,然后再就是否应该将新代码添加到应用程序中达成共识。Git 还会存储旧版本的代码,如果出了问题,可以很容易地回滚到上一个好的版本,并可以让你快速查看两次修改之间的变化。Git 最为人所知的部分可能是作为GitHub 这一云端托管版本控制系统的底层,但 Git 本身也是一个开源软件,可以部署在任何地方,无论是公司内部的服务器还是你的PC。

需要注意的是,虽然我们通常认为Git是一个计算机编程工具,但实际上取决于你如何使用它。Git 很乐意将任何文本文件作为你的 “代码库”,例如,它可以被作者用来记录合作作品的编辑情况。这一点很重要,因为GitOps的核心代码库大多由声明式配置文件而非可执行代码组成。

在我们继续之前,最后要强调一件事—— 尽管名字中就有 “Git”,但GitOps实际上并不必要使用Git。 已经投入使用其他版本控制软件(如Subversion)的团队也可以实现GitOps。但在Devops领域,Git被广泛用于实现CI/CD,所以大多数GitOps项目最终都会使用Git。

什么是CI/CD流程?

关于CI/CD的完整解释其实不在本文讨论的范围内,但是因为CI/CD是 GitOps 工作的核心,因此我们需要对其进行简单的介绍。CI/CD中的一半持续集成是由版本控制仓库(如Git)实现的。开发者可以对代码库进行持续的小改进,而不是每隔几个月或几年就推出巨大的、单一的新版本。持续部署这一块是通过被称为流水线(pipeline)的自动化系统来实现的,这些流水线可以构建、测试和部署新的代码到生产中。

同样,我们在这里一直在谈论代码,这通常会让人联想到用C语言、Java或JavaScript等编程语言编写的可执行代码。但在GitOps中,我们所管理的 “代码” 主要是由配置文件组成的。这不是一个小细节,而是GitOps工作的核心。正如我们所说,这些配置文件是描述我们的系统应该是什么样子的 “唯一真理来源(single source of truth)”。它们是声明式的,而不是指导性的。这意味着,配置文件不会说 “启动十台服务器”,而会简单地说 “这个系统包括十台服务器”。

GitOps方程中的CI那一半允许开发人员快速推出对这些配置文件的调整和改进;当自动化软件代理竭尽全力确保应用程序的实时版本能够反映配置文件中的描述时,CD这一部分会以GitOps语言趋向于声明式模型。

GitOps和Kubernetes

正如我们所提到的,GitOps的概念最初是围绕管理Kubernetes应用而出现的。通过我们现在对GitOps的了解,让我们重温一下Weaveworks的GitOps讨论,看看他们是如何描述如何对基于GitOps原则管理的Kubernetes进行更新的。下面是对整个流程的总结:

  • 一个开发者为一个新功能提出Git 拉取请求。

  • 审查和批准代码,然后将其合并到主代码库中。

  • 合并会触发 CI/CD 流水线、自动测试和重建新代码,并将其部署到仓库。

  • 软件代理注意到更新,从仓库中提取新代码,并更新配置仓库中的配置文件(用YAML编写)。

  • Kubernetes集群中的软件代理根据配置文件,检测到集群已经过时,拉取更改,并部署新功能。


Weaveworks和GitOps

显然,这里的第4步和第5步做了很多繁重的工作。将Git仓库中的 "真理来源 "与现实世界中的Kubernetes应用进行神奇同步的软件代理,就是让GitOps成为可能的魔法。正如我们所说,在GitOps术语中,让实时系统更像配置文件中描述的理想系统的过程叫做融合。当实时系统和理想系统不同步时,那就是分歧。理想情况下,融合可以通过自动化流程来实现,但自动化所能做的事情是有限度的,有时人工干预是必要的。

我们在这里用通用术语描述了这个过程,但事实上,如果你真的去看Weaveworks的页面,我们提到的 “软件代理” 是该公司Weave Cloud平台的一部分。“GitOps” 这个词是由Weaveworks的CEO Alexis Richardson创造的,它的部分作用是让Weaveworks平台对已经沉浸在DevOps和CI/CD世界的开发者有吸引力。

但Weaveworks从未宣称自己垄断了GitOps, GitOps更多的是一种理念和一套最佳实践,而不是某种具体的产品。 正如提供CI/CD解决方案的公司CloudBees的博客所指出的那样,GitOps代表了一种开放的、厂商中立的模式,它是针对亚马逊、谷歌和微软等大型云厂商推出的管理型专有Kubernetes解决方案而开发的。CloudBees提供了自己的GitOps解决方案,这个领域的另一些玩家也是如此。

GitOps和DevOps

Atlassian是一家为敏捷开发者制造了许多工具的公司,它有一篇关于GitOps的历史和目的的深度博文( https://www.atlassian.com/git/tutorials/gitops ),值得你花时间去了解。在他们看来,GitOps代表了作为devops的理念的逻辑延伸。具体来说,GitOps是对基础架构即代码(IaC)这一概念的阐述,而基础架构本身就是DevOps环境下产生的一种思想。在Atlassian看来,GitOps弥补了现有DevOps技术与分布式、云托管应用的特殊需求之间的关键差距,现有DevOps技术是为了解决系统管理问题而发展起来的。各个云厂商提供的自动融合是GitOps的特别之处。

虽然GitOps今天仍然专注于Kubernetes,但我们希望我们已经明确了它如何适用于更广泛的分布式、基于云的应用世界。开源安全厂商WhiteSource的一篇博文概述了GitOps的优势:

  • 可观察性:GitOps系统为复杂的应用提供了监控、日志、跟踪和可视化功能,因此开发人员可以看到什么地方出现了故障,在哪里出现了故障。

  • 版本控制和变更管理:很明显,这是使用Git这样的版本控制系统的一个关键优势。有缺陷的更新可以轻松回滚。

  • 易于采用:GitOps建立在许多开发人员已经掌握的开发技能之上。

  • 提高生产力:GitOps 可以像开发项目和 CI/CD 那样提高工作效率。

  • 审计:有了Git,每一个操作都可以追踪到一个特定的提交,这样就可以很容易地追踪到错误的原因。


即使你不使用Kubernetes,GitOps也很有可能迟早会成为你工作流程的一部分。

相关 [gitops devops 扩展] 推荐:

GitOps初阶指南:将DevOps扩展至K8S

- - DockOne.io
本文转自 Rancher Labs. 在过去十年的编程中,出现了一些革命性的转变. 其中之一是源于围绕DevOps的实践,它将开发和运维团队整合到一个共享的工作流程中,此外还有持续集成和持续交付(CI/CD),通过CI/CD,Devops团队可以向代码库提供持续的更新. 另一个变革来自于从单体代码库到基于云的微服务的迁移,这些微服务运行在由Kubernetes等编排平台管理的容器中.

DevOps实践一:DevOps概述 - 知乎

- -
DevOps系列文章包含了本人在工作中的实践和认知理论,现总结并分享出来,希望能够给“迷你型”团队在DevOps上的实践提供一个“反面教材”和可行性建议. 本系列主要包含以下文章(过程中可能也会有所更改):. DevOps实践一:DevOps概述. DevOps实践二:持续集成、持续交付和持续部署.

让DevOps起作用

- - InfoQ cn
根据Neil Garnichaud在Dr. Dobb’s上发表的文章《 究竟什么是DevOps》,想要频繁地发布高质量的软件,首先需要弄清如何使开发人员、QA人员和运营人员在一起协同工作. 在软件公司里,特别是在开发基于云的网络应用, 而又缺少有才华的、合格的员工的公司中,压缩的时间进度和最低限度的QA是压力的根源.

DevOps,你真的了解吗?

- - IT经理网
与大数据和PRISM(NSA的监控项目之一),DevOps(开发运维)如今是科技人士挂在嘴边的热词,但遗憾的是,类似圣经,每个人都引用DevOps的只言片语,但真正理解并能执行的人极少. 根据CA的一项 调查,45%的受访者并不了解DevOps的含义,其余则有17%认为DevOps只不过是炒作. DevOps如今几乎成了创新的同义词,但其原本的含义却在业界的流传中被人们弃之脑后.

Kubernetes 会不会“杀死” DevOps?

- - InfoQ推荐
DevOps 这个概念最早是在 2007 年提出的,那时云计算基础设施的概念也才刚刚提出没多久,而随着互联网的逐渐普及,应用软件的需求爆发式增长,软件开发的理念也逐渐从瀑布模型(waterfall)转向敏捷开发(agile). 传统的软件交付模式(应用开发人员专注于软件开发、IT 运维人员负责将软件部署到服务器运行),再也无法满足互联网软件快速迭代的需求.

DevOps最佳实践(200711)

- - 人月神话的BLOG
今天准备谈下DevOps过程最佳实践以及DevOps支撑平台建设中的一些思考. 在前面文章里面我就已经谈到了传统企业IT架构转型或企业数字化建设需要解决两个方面问题. 其一:业务层面,重点是中台规划和建设. 其二:技术层面,重点是云原生解决方案,包括了微服务,DevOps和容器云. 当然,如果你是传统的软件开发框架技术,或者传统的基于虚拟机的PaaS平台也可以上DevOps实践,但是我们更加推荐的还是基于微服务和容器云技术来实践DevOps.

DevOps的“定义”:DevOps究竟要解决什么问题?

- - InfoQ - 促进软件开发领域知识与创新的传播
近些年来,DevOps 在我们身边出现的频率越来越高了. 各种大会上经常出现 DevOps 专场,行业内的公司纷纷在都招聘 DevOps 工程师,企业的 DevOps 转型看起来迫在眉睫,公司内部也要设计和开发 DevOps 平台……这么看来,DevOps 似乎无处不在. 可回过头来想想,关于 DevOps,很多问题我们真的想清楚了吗.

你的团队里没有DevOps文化?

- Quantum - LinuxEden开源社区-Linux伊甸园
本文是从 Do you have a DevOps Culture. 全球很多的系统负责人和程序开发者都在 撰写 、 聚会 和 讨论 关于DevOps的事:如何能更加有效的协作、让我们更快的创造商业价值. 阅读全文 | 邮件推荐 | 评论回复.

再谈DevOps实践和价值(12.11)

- - 人月神话的BLOG
今天再谈下DevOps过程实践和实际的收益价值问题. 对于DevOps先引用网上的一段总结如下. 这里我们先分析一下DevOps是什么. 大部分人对DevOps的解释都是从这个单词直译过来的就是开发运维一体化,其实这样理解很片面. 其实我们不难从Patrick提出DevOps的过程得出结论,DevOps的精准解释应该是通过敏捷的软件开发与敏捷的运维管理相结合达到业务的快速、灵活响应,也就是DevOps = Dev Agile Ops Agile.

2019十大最佳DevOps工具

- - IT瘾-tuicool
【编者的话】DevOps落地重要的一方面是选好工具集,本文介绍了最流行的DevOps工具. 开发和运维的集成翻开了软件开发的全新篇章. 如果你还是DevOps的新手,或者正在寻求改进已有流程的方法,那么第一道关卡就是调研哪些工具最适合你的团队. 本文整理了工具列表,为大家选择所需的工具提供详实的参考信息.