应用GitOps PrinciplesGit是事实上的代码存储库标准；如今几乎没有人反对这种说法。我们可能不同意的地方是Git是否是真理的唯一来源，甚至是我们所认为的那。什么时候我和团队交谈，问他们Git是否是他们唯一的真相来源，几乎每个人都回答是。然而，当我开始挖掘的时候，结果往往不是这样。你能只用Git中的代码重新创建所有的东西吗？我指的是整个集群和运行在其中的所有东西。您的整个生产系统是否在一个存储库中进行了描述？如果这个问题的答案是肯定的，你做得很好，但是我们还没有结束提问。您的系统是否可以通过不按Jenkins或任何其他工具中的任何按钮发出pull请求来应用任何更改？如果你的回答仍然是肯定的，那么你很可能已经在应用GitOps原则了。它假定Git是唯一的真理来源，并且基础设施和应用程序都是使用声明性语法（例如YAML）定义的。对基础设施或应用程序的更改是通过将更改推到Git而不是通过单击中的按钮来实现的詹金斯。开发商很早以前就知道他们的应用程序需要一个单一的真相来源。没有人再争论是否应用程序需要的所有内容都必须存储在该应用程序的存储库中。这是代码所在的地方，是测试的地方，是构建脚本的位置，也是定义应用程序管道的地方。目前还不常见的一点是将相同的原则应用于基础设施。我们可以把一个环境（例如，生产）看作一个应用程序。因此，我们需要的与环境相关的所有内容都必须存储在单个Git存储库中。我们应该能够通过仅基于存储库中的信息执行单个进程来重新创建整个环境，从无到有。我们还可以利用我们应用于应用程序的开发原则。回滚是通过将代码还原为Git修订版来完成的。接受对环境的更改是一个以请求请求开始的过程。等等，等等第四，那个应用GitOps原则的主要挑战是将特定于应用程序的步骤与整个环境的创建和维护相关的步骤统一起来。有时，专用于我们的应用程序的管道需要将更改推送到包含该环境的存储库中。反过来，由于每个进程都是通过Git webhook在发生更改时触发的，所以将某些内容推送到环境repo应该启动另一个管道。在哪里许多与"Git作为唯一真相来源"的分歧是在部署阶段。团队通常构建一个Docker映像，并使用它在集群内运行容器，而不将特定版本的信息存储到Git。声明有关发布的信息存储在Jenkins中，这违反了只有一个真相来源的原则。它使我们无法通过单个Git存储库中的信息重新创建整个生产系统。类似地，关于发布的数据被存储为Git标记，打破了以声明性格式存储所有内容的原则，这种格式允许我们从单个存储库。很多为了让GitOps背后的想法成为现实，我们可能需要改变一些事情。为了使更改成功，我们需要定义一些规则，我们将使用这些规则作为必须遵循的戒律。考虑到理解事物最简单的方法是通过生动的例子，我认为持续交付和DevOps所采用的流程与白金汉宫的运作方式相似，与霍格沃茨魔法学校大不相同。如果这不能激发你的想象力，那就没有什么能激发你的想象力了。但是，由于人类喜欢用规则和戒律来证明自己的行为是正当的，我们将其中一些定义为好吧。十个GitOps的命令应用于连续交付，而不是列出其他人的规则，我们将尝试自己推导它们。到目前为止，我们只有一个，这是最重要的规则，很可能会定义其余的头脑风暴和讨论。那个统治他们的规则是Git是唯一的真理来源。这是第一条也是最重要的戒律。所有原始格式的特定于应用程序的代码都必须存储在Git中。所谓代码，我指的不仅是应用程序的代码，还包括它的测试、配置以及特定于该应用程序或系统的所有其他内容。我故意说它应该是原始格式，因为在Git中存储二进制文件没有好处。这不是它设计的目的。真正的问题是我们为什么要这些东西？首先，应该遵循良好的开发实践。尽管我们可能不同意哪些实践是好的，哪些不是，但它们都在Git周围漂浮。如果你在做代码审查，你是通过Git来做的。如果需要查看文件的更改历史，可以通过Git查看。如果你发现一个开发人员怀疑代码是否应该在Git或其他代码库中，请确保他与世界其他地方隔离开来，因为你刚刚发现了一个濒危物种的标本。只剩下几个了，他们一定会的灭绝了。而毫无疑问，开发人员将他们创建的文件存储在何处，对于其他类型的专家来说，这并不一定是正确的。我看到测试人员、操作员和其他角色的人员仍然不相信这是正确的方法，也不确定是否应该将所有的东西都记录下来并存储在Git中。举个例子，我仍然遇到在服务器上运行特别命令的操作员。我们都知道，在服务器内部执行的特别命令不具有可靠的可复制性，它们通常没有文档记录，而且执行的结果通常也不是幂等的，让我们创建第二个规则。每件事都必须被跟踪，每件事都必须是可重复的，而且每件事都必须是幂等的。如果您只是运行命令而不是创建脚本，则不会记录您的活动。如果您没有将其存储在Git中，其他人将无法复制您的操作。最后，无论我们执行多少次，该脚本必须能够产生相同的结果。今天，实现这一点最简单的方法是通过声明性语法。通常，这将是描述所需结果的YAML或JSON文件，而不是命令式脚本。让我们以安装为例。如果这是必须的（安装一些东西），它将失败，如果这个东西已经安装。不会的幂等元必须记录（跟踪）变更。实现这一点最可靠、最简单的方法是只允许人们将更改推送到Git。只是这样，没有什么是可以接受的人类行为！这意味着，如果我们希望我们的应用程序有一个新特性，我们需要编写代码并将其推送到Git。如果我们想测试它，我们编写测试并将它们推送到Git，最好是与应用程序的代码同时进行。如果需要更改配置，我们会更新一个文件并将其推送到Git。如果我们需要安装或升级操作系统，我们会对用于管理基础设施的任何工具的文件进行更改，然后将它们推送到Git中。这样的规则是显而易见的，我可以继续很长一段时间来说明我们应该做什么。这一切都归结为以push It to Git结尾的句子。更有趣的是我们不应该这样做是的。你不允许通过直接在生产服务器内更改代码来添加应用程序的功能。不管变更有多大或多小，都不能由您完成，因为您无法保证变更将被记录、可复制和跟踪。在生产系统内部执行操作时，机器比您更可靠。你是他们的霸主，你不是他们中的一员。你的工作是表达你想要的状态，而不是改变系统来遵守它。那个真正的挑战是决定如何进行沟通。我们如何表达我们的愿望，使机器能够执行将导致实际状态收敛到期望状态的行为？我们可以认为我们是贵族，机器是佣人。那个贵族的好处是不需要做太多的工作。事实上，不做任何工作是成为国王、王后或王位继承人的主要好处。如果这意味着做汽车修理工，谁会想当国王呢？没有女孩梦想成为公主，如果这意味着在超市工作。所以，如果做贵族意味着不做太多的工作，我们还是需要别人来帮我们做。否则，我们的欲望将如何变成现实？这就是贵族需要仆人的原因。他们的工作就是投标。给定人类的奴役在世界上大多数地方是被禁止的，我们需要寻找人类以外的仆人。今天，仆人是被转换成在机器内运行的进程的字节。我们（人类）是霸主，机器是我们的奴隶。然而，在政治上，我们称他们为奴隶是不正确的。因此，我们（人类）是代理（机器）的霸主，如果我们是真正的霸主，相信机器来完成我们的投标，那么这种交流就没有必要是同步的。当我们相信有人总是听从我们的命令，我们就不必等到我们的愿望实现了满足了。让想象一下你在一家餐馆里，你对服务员说"我想要一个加奶酪和薯条的汉堡"，接下来你会怎么做？你是否起床，走出餐厅，购买一些土地，并建立一个农场？你要种动物和土豆吗？你能等他们成熟了再带他们回餐厅吗。你要开始炸土豆和肉吗？明确地说，如果你喜欢拥有土地，如果你是一个农民，这是完全可以的。喜欢做饭没什么不对的。但是，如果你去了一家餐馆，你这么做正是因为你去了
