采用GitOps的11大原因

时间: 2020-08-12阅读: 61标签: git

Kubernetes允许我们单纯地使用声明性的配置文件来管理我们的应用部署和其他基础设施组件(例如,我们现在都是YAML开发者)。这使我们能够把所有这些文件放到Git仓库中,然后把它挂到流水线上(Jenkins、GitLab等),流水线会把这些变化应用到集群上,然后就有了GitOps。如果你还不了解GitOps是什么,可以查看我们之前发布过的文章: GitOps初阶指南:将DevOps扩展至K8S

为了使工作正常进行,我们必须确保改变集群的唯一方法是在Git仓库上提交。GitOps并不是专门针对Kubernetes的,同样的原理也可以应用于任何其他声明式配置管理的环境。

可以说,很多企业已经开始采用GitOps了,但现在是业界开始充分认识到其潜力的时候。所以,让我们深入了解一下它如此出色的原因吧!


1、存储环境变更历史记录

只有通过更新相应Git仓库中的配置,才能改变应用环境。这将创建一个完整的状态变化的历史记录,包括谁做了更改和为什么更改的记录。你可以通过正在使用的Git用户界面来读取历史记录。


2、轻松回滚到之前的状态

一旦我们所有的变更都被存储为Git历史记录,就可以很容易地将一个环境回滚到之前的任何状态。通过还原一些commit,我们可以回到以前的工作状态。


3、保障部署安全

一旦对集群的所有更改都通过GitOps repo,用户和持续集成(CI)流程就不需要再访问集群了。这大大降低了攻击面,尤其是还可以减少对Kubernetes API的网络访问。

部署过程无论如何实现,都可以在集群内部运行,并从Git中拉取配置。其对API的访问使用基于角色的访问控制(RBAC)进行限制。这极大地提高了集群的安全性,防止任何恶意的远程更改在API服务器上。


4、轻量化审批程序

在修改生产环境时,开发人员总是不受信任。因此在许多公司中都建立了四眼审批流程(four-eyes approval processes),不论是出于什么原因建立的审批流程,GitOps都提供了一个简单的方法来实现它们。

具体实现方式取决于你使用的Git服务器,但重点是给开发人员在Git repo上创建拉取请求的权利,同时给另一组人审查和合并的权利。大多数Git服务器都有一个很好的UI来检查修改和批准拉取请求——所以这个解决方案不仅便宜,而且对用户也相当友好。


5、模块化架构

GitOps有3个部分:Git repo、部署流程以及一个在Git repo中自动更新版本的过程。这三者可以相互独立演化或替换。

一边是一个组件在Git repo写入,另一边是一个组件在读取。Git repo的结构成为这些组件之间的桥梁。由于这是一个相当松散的耦合,两边可以用不同的方式甚至不同的技术栈来实现。


6、独立于工具的架构

第5点中提到的模块化可以看出GitOps架构是一个可以灵活组装最佳工具的架构。当然,任何流行的Git服务器都可以完成Git部分的工作,FluxCD或ArgoCD可以负责将repo同步到集群。JenkinsX是一个处理这个过程所有部分的工具,包括创建Git repos,并在构建新的Docker镜像时用新版本更新它们。


7、复用现有知识

将 Git 置于部署流程的核心,可以充分利用大多数开发人员和运维人员已经掌握的 Git 知识。不需要新的工具来浏览部署历史或实施审批流程。所有的流程都是用大家都熟悉的工具来完成的。


8、比较不同的环境

当你有一个从开发到用户接受度测试(UAT)再到生产的环境链时,跟踪这些环境之间的差异是一件很麻烦的事情。多亏了存储在Git repos中的声明式配置,它使得处理环境间差异就像比较一组YAML文件一样简单。

我们有非常棒的工具来做这件事,所以这将不再是一个问题。更重要的是,从头开始创建一个新的环境,就像复制和粘贴这些文件到一个新的repo中一样简单。


9、开箱即用的备份

由于你的环境状态存储在Git中,如果Kubernetes上的etcd发生了什么事情,你也永远不会丢失数据。因为它是你集群状态的自然备份。


10、像应用程序代码一样测试你的更改

你可以用测试应用程序代码的方式来测试环境中可能出现的破坏性变化。将更改放在一个分支上,然后在其上运行 CI 流水线。你的 CI 工具将能够运行测试,并根据测试结果将 Git 中的 pull-request 状态设置为绿色或红色。一旦所有的东西都经过测试和审查,你就可以合并到master。

这听起来非常简单,但自动化测试是基础设施管理中经常被忽视的任务。虽然GitOps并没有让它变得更容易,但至少它为你提供了与你在其他地方使用的相同的熟悉工作流程。


11、高可用部署基础设施

部署基础设施保持一致很重要。Git repo服务器通常已经以复制、高可用的方式进行了设置。源代码是所有开发人员在大多数时间都需要访问的东西,所以使用Git作为部署的源码并不会给Git本身增加额外的负担。

原文 http://dockone.io/article/10738
站长推荐

1.云服务推荐: 国内主流云服务商,各类云产品的最新活动,优惠券领取。地址:阿里云腾讯云华为云

2.广告联盟: 整理了目前主流的广告联盟平台,如果你有流量,可以作为参考选择适合你的平台点击进入

链接: http://www.fly63.com/article/detial/9652

关闭

通过git命令,上传本地文件到git服务器

把本地代码上传到git的方法:步骤一:首先进入需要上传的项目文件夹,通过命令git init初始化,步骤二:将本地文件添加到版本库中,使用命令 git add . 将文件提交到本地的暂存区,步骤三:使用命令git commit将文件提交到本地仓库...

Git命令总汇

创建一个新的 git 版本库。这个版本库的配置、存储等信息会被保存到.git 文件夹中;更改设置。可以是版本库的设置,也可以是系统的或全局的

当我们git merge的时候到底在merge什么?

用git add、git commit、git branch等命令的时候,Git在背后究竟做了什么,我是答不上来的。好在互联网上有许多这方面的资料可供学习,现在,我试着循序渐进地讲解一遍吧。

如何在Git提交大小写敏感的文件

大意是说, 忽略大小写敏感是为了在不同的文件系统上更好的工作。比如APFS,HFS +,FAT,NTFS等。例如,如果在目录列表里, Git期望找到一个文件叫Makefile,却找到了makefile,这时候,Git就假定它是同一文件,并继续将其记住为Makefile。

Git忽略文件不起作用的解决方法

开发过程中,我们自己会在gitignore 文件中添加一些忽略项,然而,每次使用git status 的时候都未列在 untracked里面,比如 用IDEA 开发,.idea 文件夹添加到该文件,再提交还是会提示。

总结Git 不同情况下撤销和如何回滚

在未进行git push前的所有操作,都是在“本地仓库”中执行的。我们暂且将“本地仓库”的代码还原操作叫做“撤销”,进行git push,即已推送到“远程仓库”中。我们将已被提交到“远程仓库”的代码还原操作叫做“回滚”!注意:对远程仓库做回滚操作是有风险的,需提前做好备份和通知其他团队成员!

git合并分支

假如我们现在在dev分支上,刚开发完项目,执行了下列命令:想将dev分支合并到master分支,操作如下:首先切换到master分支上,如果是多人开发的话 需要把远程master上的代码pull下来

Git报错:remote: HTTP Basic: Access denied的解决方法

账号密码验证不通过,密码或者权限不对,导致 Git 操作失败。输入:git config --system --unset credential.helper,再次进行 Git 操作,输入正确的用户名,密码即可。

git pull/push时总需要输入用户名密码的解决方案

在提交项目代码或者拉代码的时候,git会让你输入用户名密码,解决方案:执行命令git config --global credential.helper store

通过 41 个 问答方式快速了解学习 Git

个人比较喜欢 git add -p. 这增加了“补丁模式”的变化,这是一个内置的命令行程序。它遍历了每个更改,并要求确认是否要执行它们。这个命令迫使咱们放慢速度并检查更改文件。作为开发人员,咱们有时常常急于提交

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!