为什么您应该关心GitOpsGitOps是一个范例或一组实践，它授权开发人员执行通常属于IT操作权限的任务。GitOps要求我们用声明性规范来描述和观察系统，这些规范最终形成了连续的一切的基础。（作为一种更新，continuous everything包括但不限于持续集成（CI）、测试、交付、部署、分析、治理以及更多后续工作）。GitOps将Git与Kubernetes的聚合属性结合起来，并作为开发和交付基于Kubernetes的基础设施和应用程序的操作模型。GitOps允许开发人员以一种"你拥有它，你发布它"的方式进行操作毕业生们从科技会议上人人喊的口号变成了日复一日可以执行的现实出去。进来在本博客中，我们将更详细地探讨GitOps的用途、原因和方式，以便团队更好地了解投资带来的收益。最后，我们将讨论Jenkins X，这是一个开源软件项目，它集成了GitOps的巧妙实现，以帮助开发和交付云原生应用程序库伯内特斯。什么是GitOpsPretty Git tyGitOps坚持Git是真理的唯一来源的原则。GitOps要求将所需的系统状态存储在版本控制中，这样任何人都可以查看更改的整个审核跟踪。对所需状态的所有更改都是与提交者信息、提交ID和时间戳相关联的完全可跟踪提交。这意味着应用程序和基础设施现在都是版本化的工件，可以使用软件开发和交货.GitOps基于基于Git的源代码管理系统，因此GitHub、GitLab和Bitbucket是很自然的选择。请注意，Bitbucket使用BDDA的名称浮动GitOps-y方法，发音类似"Buddha"，表示"Build Diff，Deploy Apply"。每个环境的声明性规范GitOps要求我们使用每个环境的声明性规范来描述整个系统的所需状态。这就是记录系统。您可以在代码库中描述您的环境，如测试、登台和生产，以及其中驻留的应用程序版本环境。为了例如，我们可以将Kubernetes模型中的所有内容都描述为一个声明。kubernetesapi服务器接受一个声明作为输入，然后不断地尝试驱动（或聚合）集群到所需的状态，如声明。责任可观测（可控）可观测性（o11y）是物理系统的一个可测量属性，它使它能够被观测到。GitOps主张系统的设计方式应使其易于被观察、探索和理解。Git提交导致对Kubernetes集群进行可验证的更新。团簇的性质在簇中是可观测的，这样我们就可以检测出所期望的和观测到的状态是：一样（如，期望状态和观察状态是否最终会聚）或不同（如，期望状态和观察状态分开）。毕竟，眼见为实！与可观测性一起，可控性是现代控制系统理论的一个重要概念。在受控输入下，为了使动态系统能够做任何我们想做的事情，系统必须是可控的。可观测性在使我们能够就如何控制系统做出正确的决策方面有很大的帮助更好。为什么使用GitOpsGitOps是一组如上所述的实践，与工具无关。正如我们所看到的，它的原则植根于源代码管理中的版本控制，声明用于所需状态和可观察性的规范。然而，在本博客中，我们将深入了解Kubernetes及其收敛特性如何使吉托普。多云随着KubernetesWith集装箱的出现，Docker成为了一个连续的everything平台的标准交换货币。经过一些最初的斗争，Kubernetes已经成为集群管理和容器编排的实际领导者。这给一个高度分散的行业提供了一些喘息的机会，这个行业见证了数量惊人的竞争工具在不断循环门。但是，而对于那些喜欢修补基础设施的人来说，建立和管理Kubernetes集群会很有趣，一些应用程序开发人员和测试人员不希望陷入后勤和行政消防演习的泥潭。即使是那些对自己管理Kubernetes感到舒服的人也承认，这会抬高他们的总拥有成本（TCO）。主要的云提供商利用托管Kubernetes解决方案，如Google Kubernetes Engine、Amazon Elastic Container Service for Kubernetes、Azure Kubernetes服务，Oracle云基础设施容器引擎，用于Kubernetes和其他，从而减轻了管理Kubernetes的一些痛点。我们的行业拥有各种各样的技术堆栈、工具、平台和云战略，因此我们需要一个Kubernetes的操作模型，该模型可以扩展，并且不会受到供应商锁定的影响。让我高兴的是，吉托普斯降落在了斑点草皮!=人工交接和签核职责分离（SoD）是一个有争议的话题，通常被视为阻碍所有事情持续进行的障碍。SoD警告我们不要把全部控制权交给一个人或一群人，以确保问题的明确分离。这可以防止任何个人或团体成为强大。传统团队错误地解释了这种平衡权力的概念，通过手动将版本化的工件从一个筒仓传递到下一个筒仓，并通过票务系统请求签核。手动切换和签核中断了连续的范例，并且常常导致两个或多个不相交的管道，这些管道必须手动编排。此外，把东西扔到墙上，然后又扔到我们身上的弊端，反映了文化的贫乏，电子商务数据分析，而且常常会招致责难游戏。和GitOps，所有的更改都是使用具有时间戳和相关参与者的pull请求来完成的。根据定义，请求请求会通知团队成员，我已将更改推送到存储库中，需要按照指导的工作流推进。因此，对于谁改变了什么，何时以及谁批准了变更，就有了充分的明确性。此外，在审核和生产问题期间，淘客返利，GitOps可以轻松地将问题追溯到根本原因，因为所有更改都记录为版本中的提交控件.CI/CDKubernetes上不需要dauntingKubectl揭示了Kubernetes对象模型的机制，这是相当复杂的。团队应该在更高的抽象层次上与系统交互，而不是使用kubectl直接更新集群。通常倾向于将kubectl命令分组的更新脚本并不总是确定性的或幂等的。使用这种脚本方法，CI不会收敛到集群的声明性模型。相反，大数据服务，它抛出一个错误和管道中止。还有，为了编写有效的脚本，团队需要理解复杂的系统语义，这些语义需要大多数人不具备的专业知识，而其他人则不愿意投入。所以，问题是：我们如何才能避免这种反模式，即编写一组Kubernetes更新，并将该脚本作为管道步骤执行，以将更改推送到集群？通过GitOps风格的管道，团队可以通过Git更新他们的Kubernetes集群。第无数次，让我们试着（重新）讨论一下持续集成和连续交付（CD）之间的不太好的界限，这次，云服务器和服务器，在GitOps这个勇敢的新世界！如果不分裂头发，CI意味着将更新合并到主分支，CD意味着Kubernetes集群应该基于这些CI更新进行自我更新。够直截了当吗？下一节继续剥洋葱皮并揭示GitOps的内部机制。它应该与开发和交付云原生应用程序的团队产生共鸣库伯内特斯，怎么了GitOps工作更改是通过pull请求和GitOps进行的，因为我们通过pull请求而不是直接对运行中的系统进行修补来修复生产问题，因此故障排除变得更容易和更快。如果我们将集群访问限制为少数特权管理员，那么我们可以将相同的Git工作流应用于操作和开发。对应用程序和集群的更改可以包含到以下活动：更新容器映像更新到声明性规范，或者换句话说，环境中所需的状态错误，就像容器故障一样，通过拉请求操作可以减少将部署转换为犯罪现场的变量的数量！幸运的是（或者，不幸的是，对于那些热衷于英雄和戏剧的人来说），代码部署者不再被授予"战争英雄"身份，因为手动将比特从A点移动到B点。聚合确保了最终的一致性，如果一组配置更新是由人完成的，集群中观察到的状态可能会偏离Git中声明的所需状态，从而导致分歧。当期望状态和观察状态不同时，Kubernetes提供了一种收敛机制，将观察到的状态驱动到团队在版本控制中声明的期望状态。Kubernetes orchestrator将对集群应用更改，直到其状态收敛到声明的状态配置。之后一个可配置的时间间隔，如果状态仍然不一致，则可以生成警报。作为实现细节，淘客api，可以发送警报的工具是kubediff。融合是最终的，可以用零警报表示。作为一种复习，幂等性是数学和计算机科学中某些运算的性质，在这种运算中，它们可以多次应用而不改变最初应用的结果。收敛性应该是幂等的，例如，收敛的多个应用应该有相同的结果。总而言之，可以将聚合看作是一个协调循环，它最终将集群带到其所需的位置陈述。这个模型适用于