本文来自微信公众号“开源云中文社区”。
现在GitOps已经得到了足够的关注，所以简要介绍一下它的原则是合适的。
去年，OpenGitOps社区发布了GitOps Principles 1.0。GitOps得到了普遍支持，在开发GitOps引擎方面也有许多相互竞争的项目，例如与Argo和Flux这两个来自CNCF的毕业项目。但专注于原则可以让每个人都知道什么是GitOps，更重要的是，它有助于定义什么不是GitOps。
开源软件工程师Scott Rigby写道，OpenGitOps将GitOps定义为一套操作和管理软件系统的原则。“当使用GitOps时，系统或子系统的期望状态被声明性地定义为版本化的、不可变的数据，并且运行的系统的配置是从这些数据中不断派生出来的。这些原则源于现代软件操作，但植根于预先存在并被广泛采用的最佳实践。”
通过DevOps，运维和开发团队在自己选择的工具上进行协作。GitOps提供了一种声明性方法，并补充了DevOps。它允许应用程序交付和集群管理。GitOps与Kubernetes共享相同的概念，使已经使用它的团队更容易适应。
在cdCON+GitOpsCon会议上，Rigby和红帽高级首席产品经理Christian Hernandez介绍了GitOps原则。
以下是本次演讲和会议上其他演讲的要点：
原则1：GitOps是声明性的。
由GitOps管理的系统必须具有以声明方式表示的期望状态。
《纽约时报》的软件工程师Eve Ben Ezra在cdCON+GitOps Con上表示，GitOps允许自动化安全实践。DevOps鼓励协作，这意味着将安全性纳入软件开发生命周期的每个阶段。
原则2：GitOps应用程序是有版本的且不可变的
期望状态的存储方式可以强制执行不变性、版本控制和完整的版本历史记录。
一般观点：回滚应该很简单。
Ezra说：“GitOps为基础设施和应用程序的所有更改提供了可审计的跟踪，这更进一步。”
Ben Ezra说，版本控制允许组织发现其安全性中的漏洞，还允许测试和声明性基础设施。使用像Open Policy Agent这样的工具，这是一个用于在云原生环境中建立授权策略的开源项目，可以提高生产力，因为一旦实现自动化，团队就可以减少为基础设施是否合规而烦恼的时间，这给了他们更多的时间进行创新和功能开发。
Ben Ezra说：“虽然自动化是DevOps的重要组成部分，但它绝不是唯一的方法。它还需要跨职能协作，打破孤岛，在整个组织中共享知识。GitOps建立在这些原则之上，即利用自动化和基础设施作为代码来减少配置漂移，并为整个团队或组织提供单一的真相来源。”
通过写下来，所有团队成员都可以为基础设施代码做出贡献，这促进了整个软件开发生命周期的共同责任。同样重要的是，每个人都意识到了这些变化，所以如果他们看到你错过的东西，他们可以大声说出来。
Ben Ezra说：“例如，在《纽约时报》，我们利用OPA的实用程序来提高GitOps运营框架内的反馈和开发人员生产力。”
原则3：GitOps应用程序是自动拉取的
软件自动化自动从源中拉取声明的状态声明。
以Flux为例。Flux是一套面向Kubernetes的持续和渐进交付解决方案，具有开放性和可扩展性，为开发人员和基础设施团队提供GitOps和渐进交付。
Weaveworks的开发人员体验工程师Priyanka Pinky Ravi表示：“因此，Flux是一套专注于安全性、速度和可靠性的持续交付工具。”
“他们专注于自动化。因此，我们的想法是，你有一个安装在集群上的Kubernetes控制器，它们在一个协调循环上运行，这只是你设置的一个间隔。每次运行时，源控制器都会进入并从你说的任何源中提取，例如git存储库、home或repo Image、Image注册表、OCI注册表。这个想法是，它提取在那里找到的清单，然后将它们实际应用到集群上。”
原则4：GitOps应用程序不断协调
“软件代理不断观察实际的系统状态，并尝试应用期望状态。”
值得注意的是，GitOps社区有多种不同观点。但有了一套原则，社区可以构建反映GitOps是什么和不是什么的核心焦点的方法；至少，这就是概念。
