【51CTO.com快译】如今，许多团队都在各种项目中争相使用着诸如：版本控制、代码审查、以及CI/CD管道等，与DevOps有关的优秀实践。不过，您是否注意到，这些方法主要针对的是软件开发生命周期中的自动化。而在涉及到基础架构的设置和部署时，项目团队仍然主要依赖的是手动的过程。
对此，GitOps提供了一套管理基础架构的自动化方法。项目团队可以借助GitOps，并通过使用各种声明文件，将基础架构编写为代码(infrastructure as code，IaC)，进而自动化配置的过程。也就是说，我们可以像存储应用程序的开发代码那样，将基础架构存储放在Git存储库中，以提高整体的交付能力和产品质量。
GitOps的工作原理
GitOps的概念最初是由Kubernetes管理公司--Weaveworks(请参见https://www.weave.works/)提出的。众所周知，基于容器的应用往往比较复杂，而且难以进行配置和管理。因此，GitOps主要针对的是：在Kubernetes背景下，如何将编排平台转换到运行在容器中的微服务上，并采用DevOps领域的成熟技术，来协助简化该过程。下面我们将深入讨论GitOps的各个主要组成部分：
基础架构即代码(IaC)
如前所述，IaC可以通过将各种声明性文件存储为代码，进而实现基础架构的配置和管理。据此，通过利用IaC和版本控制，项目团队可以优化当前的各项操作进程。此处提到的声明式(Declarative)，意味着您的配置将不再是一组命令，而是对某种预期状态的声明。例如，在Kubernetes中，您可以在清单文件(manifest)中定义服务所需的Pod数量。系统将通过自行处理，获取所需的容器编号，而无需工程师额外编写命令脚本。
在此，任何符合声明性模型的云原生软件，都可以被视为代码。通常，我们会将各种所需的状态声明为代码，并通过系统应用的更改，以自动化的方式实现目标状态。例如：我们可以使用诸如AWS CloudFormation之类的声明性工具，来编写AWS的基础架构。
拉取请求(Pull Requests)
GitOps概念背后的主要思想是：版本控制系统是唯一的来源。我们既可以将Git用作应用代码的变更管理系统，通过拉取请求来实现各项操作性的变更，又可以将其用于基础架构的代码上，以便将整个声明文件集中于一处。
在应用开发的工作流中，我们需要将某个主分支作为发布分支。在此基础上，开发人员会从主分支处创建各个功能性分支，以便开发出特定的功能或故事线。而在功能性分支上，一旦完成了更改，他们会通过创建拉取请求的方式，重新合并回主分支。这样一来，我们就可以在方便实现协作的同时，透明地获悉到谁在何处进行何种更改。而且，由于所有更改都是在Git处被提交的，因此这对于开发团队从根本原因处进行问题的跟踪，也是非常实用的。
可见，创建拉取请求的好处在于，我们可以让代码在被集成到代码库的另一个分支之前，事先经历代码的审查过程。而代码审查恰好能够阻止各种不良的代码，进入测试或生产环境。显然，这对于故障的消除，以及基础架构代码而言，都是非常重要的。
Git的组成
GitOps并不依赖于任何工具或技术。它可以与诸如：GitHub、BitBucket或GitLab等，任何基于Git的系统协同使用。
而在部署过程中，GitOps至少需要两个存储库，即：包含了应用源代码、及其部署清单的应用程序存储库;和使用着每个环境的声明性规范描述的，包含了整个系统目标状态的环境配置存储库。您可以在代码存储库中将目标环境定义并描述为开发环境、测试环境、生产环境、或是包含了运行着特定版本的应用和基础架构服务的环境。
CI/CD
要实现完整的GitOps，您势必需要一个CI/CD管道，以实现Git存储库在每次发生更改时，开发团队都能将对应的基础架构变更交付到指定的环境中。该自动交付管道能够将Git的拉取请求连接到编排系统中，以便通过请求来触发管道，并让编排系统执行指定的任务。
一般而言，GitOps有两种可能的部署策略：推送管道和拉取管道。您可以根据当前架构需要部署的实际环境，在两者间做出选择。下面我们来具体看看两种策略的各种特点：
推送管道(Push Pipelines)
目前，许多流行的CI/CD工具都在使用这种策略。开发人员通常将应用程序的源代码、及其部署清单存储在一个存储库中。当应用代码发生变更时，管道将触发容器映像的构建，并将变更推送到相应的环境中。由于该策略支持任何类型的基础架构，因此它具有较大的灵活性。不过，其缺点是：它会赋予CI/CD工具对于目标环境的写入权限。
基于推送的DevOps部署
拉取管道(Pull Pipelines)
在开发者社区中，人们普遍认为：对于GitOps的拉取管道方法是一种更安全的策略。这种方法引入了操作符(operator)的概念。它是管道和业务流程工具之间的组件。操作符能够不断将环境存储库中的目标状态，与已部署的基础架构的实际状态，进行比较。如果操作符检测到任何修改，那么它就会更改基础架构，以适应环境存储库。同样地，它也可以监视镜像注册表，以识别出需要部署的镜像新版本。
基于拉取的DevOps部署
可见，在GitOps中，只有在环境存储库中出现修改时，对应的环境才会更新。相反，如果已实施的基础架构在环境存储库中并未定义任何方式的修改，那么系统将会自动还原。
在实际项目中，大多数应用程序都会同时涉及到多个环境。对此，GitOps允许您创建多个管道，以同时更改多个环境存储库。当然，您也可以在环境存储库中使用单独的分支，来管理多个环境。我们既可以通过将操作符部署到生产环境中，来对单个分支的修改及时做出反应，又可以通过部署到测试环境中，来响应另一个分支。
GitOps的优势
由于GitOps专注于Git工作流、IaC、CI/CD管道，不可变服务器(immutable servers)、跟踪、以及可观测性等优秀实践模型，因此它代表了对于Kubernetes云原生应用管理的高级状态。据此，开发团队可以从如下方面受益：
简化持续部署
顾名思义，持续部署(https://microtica.com/cracking-the-continuous-deployment-code/)意味着更快、更频繁的部署。通过GitOps，部署操作符提供了必要的结构和自动化，而且这一切都在版本控制系统中发生，因此我们无需各种工具，便可管理系统的状态、停机时间、上游/下游依赖关系、以及其他与组织相关的流程。
此外，GitOps不但提高了项目团队的生产率，而且加快了他们的平均部署时间(Mean-time-to-deployment，MTTD)。有证据表明，自动化持续部署能够确保团队每天触发30到100次以上的变更，并将生产环境的性能平均提高2到3倍。
缩短平均修复时间(Mean-time-to-repair，MTTR)
MTTR是衡量DevOps团队绩效的一项关键指标(https://microtica.com/13-devops-metrics-for-increased-productivity/https://microtica.com/13-devops-metrics-for-increased-productivity/)。由于GitOps保留了版本控制系统中的所有修改，并且能够实现自动化的管理，因此，开发团队能够全面了解目标环境中的变化，轻松发现和修复错误，从而显著降低MTTR。
简化Kubernetes管理
在无需透彻了解Kubernetes的情况下，开发人员可以使用Git等较为熟悉的工具，更加轻松地管理Kubernetes的升级和各项功能。据此，新加入的成员也能够在几天时间快速上手Kubernetes。
全面掌握并标准化工作流
由于GitOps提供了一站式的应用程序、软件、以及针对Kubernetes修改的框架，因此开发团队可以清晰地洞悉整个项目的端到端工作流，并能通过Git来完全复现日常的业务运营活动。
GitOps的实现
- 建立稳定的代码审查与测试过程。通过仔细地检查代码的更改，我们能够及时发现诸如全局变量的添加等操作，并且可以通过提交拉取请求(而非直接提交更改的方式)，来验证代码。而在拉取请求被检查与合并之后，管道才会被触发。此举在避免发布错误的代码的同时，有效地保持了高标准的代码，以及系统后续的稳定性。
- 持续测试。合并到GitOps中，往往意味需要通过高级的自动化机制，对待发布的应用程序进行彻底的测试。有了GitOps，我们不但能够相对轻松地实现回滚，还能够通过良好的测试用例，保障代码的质量和可靠性。
- 专注监控。GitOps允许开发人员重复各项操作流程，改进、发布并回顾各种可追溯的系统状态。而通过专注于监控，我们可以识别并防止任何意外的漂移(drift)、以及系统配置的变更。因此，在开始使用GitOps之前，开发团队有必要检查自己的监控水平，以及处理变更的能力。
- 拥抱文化。作为目前在开发领域的优秀战略，DevOps文化能够促进团队的共同协作，更有效地管理基础架构的稳定性，更快、更流畅地执行应用程序。而GitOps又能够让我们在此基础上，进一步理解开发和运营的协同价值，提供一整套自动化的管理方法。
小结
作为一种非常好的工作流模式，GitOps不但可以帮助我们有效地处理云基础架构，还能够为工程团队提供：更好的协调性、透明度、稳定性、以及系统耐用性等方面的诸多好处。
原文标题：GitOps – DevOps for Infrastructure Automation，作者：Sara Miteva
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
