【.com速译】英国作家AldousHuxley曾说过：“速度才是真正的快乐源泉”。我觉得在生活中如此，在软件领域也是如此。随着DevOps和GitOps等辅助实践的兴起，软件从架构设计到代码部署再到生产环境的速度越来越快。事实上，DevOps是关于通过定义一组实践和文化转变来提高我们生成代码的速度并确保代码的可靠性。DevOps本身只是一个广义的术语，不同的组织和团队围绕其核心原则制定了各种具体的实践，包括：ChatOps、DevSecOps、AIOps，以及一种称为GitOps的较新实践。GitOps的出现和兴起，主要得益于Kubernetes在软件开发行业的广泛采用。在各个组织转向Kubernetes的过程中，开发团队的逐渐壮大和扩大集群的管理实践将变得势在必行。所以GitOps旨在将Git和Kubernetes结合在一起，为开发人员提供某种形式的操作模型，以及基于Kubernetes的基础设施和应用程序。可以说，在Kubernetes开发过程中，GitOps可以在保证“速度”的基础上，实现软件方案的持续交付。下面，让我们看看GitOps的工作原理、启动和运行，以及如何在Kubernetes中使用GitOps来为您的团队提供DevOps体验。工作原理GitOps坚持DevOps的核心理念——“builditanddeliverit(youbuiltityoushipit)”。它使开发人员能够在他们选择的Git工具中发出拉取请求，以触发Kubernetes集群的部署，使Git成为唯一的来源。显然，这个想法是用基于拉的管道取代基于推的管道，允许开发人员直接从他们的拉请求执行部署。一旦开发人员执行合并或打开请求，基础设施就会在部署过程中触发一系列事件。每当GitOps操作员检测到此类更改时，它都会导致另一个操作员声明更改并将其部署到集群。例如，你可以使用以下工具栈来实现GitOps：使用Bitbucket作为你的GitVCS（译者注：VersionControlSystem，版本控制系统）工具。使用Docker来存储您的各种图像。使用AmazonS3存储各种Helm图表。使用AWSLambda拉取图形并提交到集群存储库。使用Wea??veworksFlux检测集群存储库中的更改并进行相应调整。当然，实现此类功能的实际基础架构在您的工具堆栈中可能会有所不同，但机制是相似的。下面是一个可以实现的GitOps工作流程：使用像BitbucketPipelines这样的CI（持续集成）工具将各种Docker镜像推送到像Quay这样的托管工具。各种云功能函数将不同的配置和helm图表从主存储桶复制到主git存储库。WeaveworksFlux等GitOps算子会根据各种配置图表更新集群，通过Lambda函数拉取不同的helm图表。当然，上面技术栈中描述的每个工具都有替代方案，开发团队可以选择最合适的工具来实现DevOps目标。例如，同样属于Atlassian套件的Jira可以轻松地与Bitbucket配合使用。因此，如果在Bitbucket中创建拉取请求，它会自动将Jira中的问题发送到自定义“部署”。这将大大简化从设计到发布的DevOps实践过程。同样，在考虑通过GitOps实现的持续交付机制中可能出现的故障时，我们可以添加其他监控工具来提供急需的可见性。例如，Thundra.io可用于监控S3触发的AWSLambda函数，以确保在向集群存储库提交更改时没有失败。同样，我们也可以使用Thundra.io集成向Opsgenie等警报工具发送警报，然后通知相应的值班人员快速解决由拉取请求触发的部署引起的任何问题。可见，我们可以通过为GitOps引擎增加更多的功能来提高GitOps实践的可靠性和便利性。Kubernetes给你带来的便利一般来说，GitOps可以为Kubernetes部署提供集成、幂等、确定性和自动化的功能。根据Kubernetes强大的收敛机制，它会不断尝试改变集群的状态，使各种收敛应用得到相同的结果。这些都是自动快速触发的。Kubernetes编排器（orchestrator）会持续对集群应用各种变更，直到集群收敛到配置更新所定义的状态，即满足开发者或SRE人员预期的配置状态。这不仅适用于所有Kubernetes资源，还适用于自定义资源定义(CRD)或Kubernetes扩展。整个GitOps流程从在Git存储库中定义某个期望状态开始，然后将Git定位为单一来源。此外，我们需要确保提交的更改与集群匹配，以便标记集群是否已经收敛到所需状态或已经偏离它。当期望状态与实际状态不同时，Kubernetes中的收敛算子会主动尝试弥补两种状态之间的差异，即根据针对Git的那些提交触发一个已更改的“差异”警报，以识别仍然需要进一步收敛。因此，这意味着所有提交都会导致对集群的可验证和幂等更改。当然，Kubernetes也可能会按需生成回滚。就其机制而言，回滚可以看作是对先前状态的进一步收敛。最后，如果系统中不再有“差异”警报，或者只有“聚合”警报，则该机制认为实际状态已达到所需状态。事实上，我们可以使用回调或回写事件的方法来设置此类聚合状态。至此，我们可以意识到GitOps依赖于IAC（译者注：InfrastructureasCode）的概念。即：基础设施是程序化定义的，基础设施的实际状态会随之改变。这就是我们前面提到的拉式部署方式，它不同于传统的推式部署。相关工具如您所知，DevOps是一个广阔的领域，并不局限于软件行业。GitOps只是软件行业在向更敏捷、更可靠的方向发展过程中出现的一种开发实践。更准确地说，随着技术趋势的变化，开发实践必须适应可用的技术，而GitOps是团队和组织如何跟踪技术发展并不断推进开发实践的一个很好的例子。值得一提的是，WeaveworksFlux等操作器可以很好地帮助您在集群中启用GitOps。当然，您也可以选择其他替代方案，例如Spinnaker。此外，考虑到持续部署可能会给生产环境带来风险，我们可以通过添加Thundra.io、Opsgenie等工具对系统进行全覆盖测试，降低风险点，保证一定的可观察性和事件管理能力。总结总的来说，我们可以把GitOps看作是一种实践，它可以利用Kubernetes的核心力量来加速软件从设计到发布的整个过程。只有掌握了GitOps的工作原理，才能充分发挥Kubernetes在容器服务方面的巨大潜力，为持续部署和持续交付保驾护航。原标题：UndertheHoodofGitOps作者：SarjeelYusuf
