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

本文转自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… ),值得你花工夫去理解。在他们看来,GitOps代表了作为devops的理念的逻辑延长。具体来说,GitOps是对基础架构即代码(IaC)这一概念的论述,而基础架构自身就是DevOps环境下产生的一种思维。在Atlassian看来,GitOps补救了现有DevOps技术与分布式、云托管利用的非凡需要之间的要害差距,现有DevOps技术是为了解决系统管理问题而倒退起来的。各个云厂商提供的主动交融是GitOps的特别之处。

尽管GitOps明天依然专一于Kubernetes,但咱们心愿咱们曾经明确了它如何实用于更宽泛的分布式、基于云的利用世界。开源平安厂商WhiteSource的一篇博文概述了GitOps的劣势:

  • 可察看性:GitOps零碎为简单的利用提供了监控、日志、跟踪和可视化性能,因而开发人员能够看到什么中央呈现了故障,在哪里呈现了故障。
  • 版本控制和变更治理:很显著,这是应用Git这样的版本控制系统的一个要害劣势。有缺点的更新能够轻松回滚。
  • 易于采纳:GitOps建设在许多开发人员曾经把握的开发技能之上。
  • 进步生产力:GitOps 能够像开发我的项目和 CI/CD 那样进步工作效率。
  • 审计:有了Git,每一个操作都能够追踪到一个特定的提交,这样就能够很容易地追踪到谬误的起因。

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

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据