理解GitOps:原则、工作流和部署类型
什么是GitOps?
GitOps是一组用于管理基础设施和应用程序配置的实践。它利用了开源版本控制系统Git，该系统通常用于软件开发项目。
GitOps构建在基础设施即代码(IaC)技术之上，该技术可以获取指定所需基础设施状态的配置文件，并自动将基础设施调整到该状态。这称为声明性配置。使用GitOps, Git存储库成为所有声明性配置的真实来源。
GitOps使用Git拉请求自动管理基础设施配置和部署。Git存储库包含整个系统状态，因此您可以查看和检查系统状态更改的跟踪。
GitOps建立在开发人员经验的基础上，并授权团队使用与软件开发相同的工具和流程来管理他们的基础设施。它不仅基于Git，还集成了持续集成/持续交付(CI/CD)和云原生工具集中的其他技术。
在本文中:
GitOps的3个原则
以下是GitOps模式的三个主要原则。
声明式系统
在GitOps模型中，整个系统是声明式配置的。这种声明性方法关注的是结果(期望的状态)，而不是实现期望结果所需的步骤。
这种声明式方法允许用户指定最终目标，而不必担心所有必要的步骤——称为命令式方法。GitOps创建状态感知的声明性配置，允许用户将这些状态存储在Git中，以便于部署和回滚。
Git存储库中捕获的系统状态
所有声明性状态都存储在Git存储库中，作为唯一的真相来源。这种版本控制方法使所有系统基础设施更改按时间顺序可用，允许用户轻松识别基础设施随时间的更改。这使得执行回滚、故障排除部署失败以及审计遵从性和安全性变得更加容易。
自动部署
当发出拉取或合并请求时，所有更改都存储在Git中，因此它们会得到验证和批准。在GitOps模型中，最好立即自动部署任何已批准的更改。这使得系统能够快速地达到所需的状态。它还确保当前版本的Git配置始终与实际的基础设施相匹配。
GitOps工作流
GitOps是基于拉请求的。初始化拉请求时，用户可以看到每个基于存储库的分支的变更概览。然后，用户可以添加建议更改的摘要，查看建议更改，添加标记，并提及其他贡献者。
在开发人员创建一个拉请求之后，他们可以在主题分支中添加一个提交。这允许所有贡献者看到实际提议的更改。一旦每个人都批准了更改，它们就可以与pull请求合并。
哪些配置更改可以包含在拉取请求中?
GotOps拉取请求可以包括配置更改，例如:
- 应用程序配置的更改
- 容器图像的更改
- Kubernetes集群配置的更改
- 修复环境中的错误
- 通过声明性配置定义新的基础设施
- 更新环境以满足新的需求
故障排除
在批准拉取请求并部署更改之后，如果有任何问题，故障排除就很简单了。使用GitOps，环境中的任何问题都可以跟踪到特定的拉取请求，然后故障排除可以集中在这些拉取请求中引入的更改上。
与其他系统集成
GitOps还可以使用其他工具进行Git推送、开发和持续集成:
- GitOps可以与任何CI和Git服务器一起工作。
- GitOps可以使用为Kubernetes环境构建的CI/CD工具，例如Ocean CD和Jenkins X。
- GitOps可以使用任何Git存储库，如GitHub, Bitbucket, Azure pipeline或AWS CodeDeploy。
为什么使用GitOps?
采用GitOps的组织希望走在敏捷开发实践的前沿。与现有的开发流程相比，GitOps提供了以下优势:
- 生产力gitops是一种实现持续部署的实用方法，它可以提高开发效率。GitOps团队可以将每个更改部署到生产环境中，而不是每天只推送选定的版本几次。这种更快的反馈循环可以显著提高开发速度。
- 开发人员的经验现代CI/CD管道是复杂的，有各种各样的工具，不是所有的开发人员都熟悉。随着Kubernetes的出现，环境变得更加复杂。但是，所有开发人员都熟悉Git源代码控制。因此，基于所有开发人员都熟悉的概念，GitOps模型可以实现更快的升级和更流畅的体验。
- 可靠性git分叉和恢复允许团队在某个环境中发现问题时执行简单、可重复的回滚。Git存储库还提供了一个单一的真相来源，允许在几分钟内从主要问题恢复到稳定状态。
- 遵从性和安全性-GitOps使它更容易满足法规遵从性要求，因为它自动创建所有Kubernetes集群更改的审计日志。这使得可以很容易地调查问题，并向审计人员证明安全措施已经到位。此外，GitOps提供了强大的安全保证，并能够签署所有更改以证明作者和来源。
- 一致性-GitOps使Kubernetes与发生在其他环境中的开发保持一致。它为跨传统环境和云原生环境的变更管理提供了一个模型。
GitOps vs DevOps
GitOps和DevOps从两个不同的角度来处理开发过程:
- DevOps是一个管道过程，主要关注软件开发的操作方面。开发人员和运维专业人员都使用它。
- GitOps是一种开发机制，主要侧重于以声明的方式自动化和跟踪环境更改。它以开发人员为中心。
下面是DevOps和GitOps的区别。
命令式和声明式配置
- DevOps可以是命令式的，也可以是声明式的。许多DevOps工具执行显式的部署操作脚本，采用命令式方法。同时，DevOps可以同样应用于容器化和声明性配置环境。
- GitOps只允许声明式配置。
集装箱的环境
- DevOps最常用于传统的IT基础设施，如裸机服务器和虚拟机(vm)。它可以与容器和Kubernetes一起工作，但如果没有GitOps，管理起来可能会很有挑战性。
- GitOps几乎总是在云原生和容器环境中使用。
整体与微服务
- DevOps更适合于单片应用程序，或者组件数量有限的应用程序。
- GitOps最适合具有数十或数百个组件的大型微服务应用程序。
他们能一起工作吗?
- DevOps可以适应并受益于GitOps开发工作流
- 对于只专注于Kubernetes作为基础设施的组织，GitOps可能就足够了，可能不需要额外的DevOps工具和流程。
GitOps部署策略
部署策略是开发人员可以用来在最短的停机时间内修改或更新应用程序的技术。GitOps使得以一致的方式实现部署策略变得更加容易。下面是一些最常见的部署策略。
轧制策略
滚动部署逐步用新版本替换应用程序的实例。它更新一些pod，执行准备就绪检查，当确认它们正在工作时，关闭旧的实例。这意味着在出现重大问题时，滚动更新可以被中止，新实例将被终止并被当前版本取代。
金丝雀的部署
金丝雀部署是一种滚动策略。它涉及到为一小部分应用程序用户引入新版本，并观察他们的行为，时间跨度从几分钟到几周不等。如果用户对更改的响应良好，就会向其他用户推出，直到新版本取代旧版本。
相关内容:阅读我们的金丝雀部署指南(即将发布)
蓝绿色的部署
在蓝绿部署中，开发人员并行运行应用程序的两个版本。使用负载均衡器或服务路由，它们逐渐将流量从当前生产版本(绿色)转换到新版本(蓝色)。在这一点上，仍然可以通过将流量从蓝色重路由到绿色来回滚到旧版本。
当确认蓝色版本工作正常时，将重新配置生产路由以指向它，它将成为新的生产版本。然后关闭旧的绿色部署。
A / B部署
A/B部署类似于蓝绿部署，因为它也并行运行应用程序的两个版本。然而，与蓝绿不同的是，它定义了每个版本应该使用的流量的百分比(例如，50/50或20/80)，并根据此规则转移流量。随着时间的推移，当人们对新版本更有信心时，转向新版本的流量百分比就会增加。
这种方法通常用于试验不同版本的用户体验。换句话说，两个版本运行相同的后端，但用户界面略有变化，开发团队可以观察到用户粘性和转化率等指标的差异。
GitOps最佳实践
下面是一些您可以用来改进GitOps实现的最佳实践。
- 规划分支策略-记住，你在源代码控制存储库中使用的分支策略对你的环境有直接的影响。您必须根据需要设置的环境的分类仔细规划源代码控制分支。
- 避免混合环境-GitOps是“全有或全无”。为了使其有效，环境的所有部分都必须由基础设施即代码(IaC)工具控制，并且必须将所有配置签入存储库。有些组件是通过GitOps管理的，而其他组件是手动或通过其他自动化技术管理的，在这样的环境中运行将会产生不可预测的结果。
- 利用合并请求讨论当提交合并请求时，开发者有很好的机会讨论变更的含义。建立有效的合并请求过程，使用适当的自动化模式，建立通信协议，指定开发人员在拉请求期间应该询问什么，以及什么类型的交换适合于早期计划阶段。
- 上游有东西破裂时作出反应-只要GitOps部署的上游环境中出现故障，这就表明用于构建该环境的配置有问题。设置监控和触发器以从上游环境获取这些信号。当出现故障时，应该将其视为一个Andon线，它会停止GitOps配置的工作，直到问题得到解决。
- 政策即代码-GitOps可以而且应该由与组织策略相一致的自动化策略来补充。开放策略代理(OPA)是一种可以用来实现这一目标的框架。策略自动化对于确保部署的环境与安全性和遵从性需求保持一致尤其重要。
- 幂等性-无论你从什么开始，或者你运行了多少次声明性配置，结果应该总是相同的。确保使用保证幂等性的模板引擎和部署系统。
