gitops

在这里插入图片描述

1	顾名思义，基于 Git 的 DevOps 工作流水线。

devpos 最佳实践推荐

KubeSphere-v2.1
KubeSphere-v3.1.1

什么是gitops

GitOps是为云本地应用程序实现连续部署的一种方法。
它通过使用开发人员已经熟悉的工具（包括Git和连续部署工具），着重于在操作基础设施时以开发人员为中心的体验
giops的核心思想是拥有一个Git存储库，该存储库总是包含对生产环境中当前需要的基础设施的声明性描述，
以及一个自动流程，以使生产环境匹配存储库中所描述的状态。
如果您想要部署一个新的应用程序或更新一个现有的应用程序，您只需要更新存储库—自动流程处理其他所有事情。
这就像使用巡航控制来管理生产中的应用程序一样。

giops:在声明性基础设施之上的版本化CI/CD。停止编写脚本并开始发布

我为什么要使用giops ?

`1.更快、更频繁地部署`

可能每一种持续部署技术都承诺使部署更快，并允许您更频繁地部署。GitOps的独特之处在于你不需要切换工具来部署你的应用程序。
无论如何，所有事情都发生在用于开发应用程序的版本控制系统中。
这样，Git记录不仅是审计日志，也是事务日志。您可以回滚和回滚到任何快照。

2.简单快速的错误恢复

当您的生产环境坏了!
有了giops，您就可以了解环境如何随时间变化的完整历史。
这使得错误恢复非常简单，只需发出git恢复并观察环境被恢复

3.简单的凭证管理

GitOps允许您从环境内部完全管理部署。为此，您的环境仅需要访问您的存储库和映像注册表。而已。您不必让开发人员直接访问环境。

4.自动记录的部署像git 提交历史一样

您是否曾经SSH到服务器并想知道那里运行着什么?使用giops，对任何环境的每个更改都必须通过存储库进行。
您总是可以检出主分支，并获得关于部署内容的完整描述，以及对系统所做的每个更改的完整历史。
您还可以免费获得系统中任何更改的审计跟踪!

5.信息共享

使用Git存储对已部署基础设施的完整描述，可以让团队中的每个人查看它随时间的变化。
有了出色的提交消息，每个人都可以重现改变基础设施的思维过程，也可以很容易地找到如何设置新系统的示例。

giops是如何工作的?

1.环境配置为Git存储库

> GitOps围绕代码库作为中心元素来组织部署过程。
> 至少有两个存储库:应用程序存储库和环境配置存储库。
> 应用程序存储库包含应用程序的源代码和用于部署应用程序的部署清单。
> 环境配置存储库包含部署环境当前所需基础设施的所有部署清单。
它描述了在部署环境中，应用程序和基础设施服务(消息代理、服务网格、监控工具……)应该在什么样的配置和版本下运行。

2.基于推的部署与基于拉的部署

有两种方法可以实现GitOps的部署策略:

1.基于推的部署和基于拉的部署。这两种部署类型的区别在于如何确保部署环境实际上类似于所需的基础设施。
2.如果可能的话，应该首选基于拉的方法，因为它被认为是更安全的，因此是实现gitops的更好实践。

3.推动基于部署

基于推送的部署策略是由流行的CI/CD工具实现的，
如Jenkins、CircleCI或Travis CI。

应用程序的源代码和部署应用程序所需的Kubernetes YAMLs一起驻留在应用程序存储库中。
每当更新应用程序代码时，就会触发构建管道，它将构建容器映像，最后使用新的部署描述符更新环境配置存储库。

对环境配置存储库的更改将触发部署管道。该管道负责将环境配置存储库中的所有清单应用到基础设施。
使用这种方法，向部署环境提供凭据是必不可少的。
所以管道启用了上帝模式。
在某些情况下，当运行云基础设施的自动化供应时，基于推送的部署是不可避免的。
在这种情况下，强烈建议使用云提供商的细粒度可配置授权系统来获得更严格的部署权限

使用此方法时要记住的另一件重要事情是，只有在环境存储库更改时才触发部署管道。
它不能自动注意到任何环境和其期望状态的偏差。
这意味着，它需要某种适当的监视方式，以便在环境与环境存储库中描述的不匹配时进行干预。

操作员应该始终与要部署的应用程序处于相同的环境或集群中。
这就避免了基于推送的方法中的god模式，即CI/CD管道知道用于部署的凭证。
当实际部署实例存在于相同的环境中时，外部服务不需要知道凭据。
可以利用正在使用的部署平台的授权机制来限制执行部署时的权限。
这在安全方面有巨大的影响。在使用Kubernetes时，可以使用RBAC配置和服务帐户。