【.com快译】今天，很多团队都在争先恐后地在各种项目中使用与DevOps相关的最佳实践，例如版本控制、代码审查和CI/CD流水线。但是，你有没有注意到，这些方法主要是针对软件开发生命周期中的自动化。在基础设施设置和部署方面，项目团队仍然主要依赖手动流程。在这方面，GitOps提供了一套用于管理基础架构的自动化方法。项目团队可以使用GitOps通过使用各种声明文件编写基础架构即代码（infrastructureascode，IaC）来自动化配置过程。也就是说，我们可以像存储应用程序开发代码一样将基础架构存储在Git存储库中，以提高整体交付能力和产品质量。GitOps的工作原理GitOps的概念最初是由Kubernetes管理公司Weaveworks提出的（参见https://www.weave.works/）。基于容器的应用程序非常复杂且难以配置和管理。因此，GitOps主要针对：在Kubernetes的背景下，如何将编排平台转化为运行在容器中的微服务，并采用DevOps领域成熟的技术帮助简化流程。下面我们将深入讨论GitOps的主要组件：InfrastructureasCode(IaC)如前所述，IaC可以通过将各种声明性文件存储为代码来配置和管理基础设施。因此，通过利用IaC和版本控制，项目团队可以优化当前的操作流程。这里所说的声明式意味着你的配置将不再是一组命令，而是一些预期状态的声明。例如，在Kubernetes中，您可以在清单文件中定义服务所需的Pod数量。系统将自行处理以获得所需的容器编号，而无需工程师编写额外的命令脚本。在这里，任何符合声明式模型的云原生软件都可以被认为是代码。通常，我们将各种期望状态声明为代码，并通过系统应用的更改，以自动方式实现目标状态。例如：我们可以使用AWSCloudFormation等声明式工具来编写AWS基础设施。PullRequests的GitOps概念背后的主要思想是版本控制系统是唯一的来源。我们既可以将Git用作应用程序代码的变更管理系统，通过拉取请求实现操作变更，也可以将Git用作基础设施代码以将整个声明文件集中在一个地方。在应用开发的工作流程中，我们需要使用一个master分支作为发布分支。从那里，开发人员从主分支创建各种功能分支，以开发特定的功能或故事情节。在功能分支上，一旦做出更改，它们就会通过创建拉取请求合并回主分支。这使我们能够透明地看到谁在何处进行了哪些更改，同时促进了协作。此外，由于所有更改都在Git上提交，因此对于开发团队从根本原因追查问题也非常有用。可见，创建pullrequest的好处在于，我们可以让代码在被集成到代码库的另一个分支之前通过codereview流程。而codereview正好可以防止各种不好的代码进入测试或者生产环境。显然，这对于消除故障以及基础架构代码非常重要。Git构成了GitOps，并且不依赖于任何工具或技术。它适用于任何基于Git的系统，例如GitHub、BitBucket或GitLab。在部署过程中，GitOps至少需要两个存储库，即：包含应用程序源代码的应用程序存储库，及其部署清单；并使用每个环境的声明式规范，包括整个系统目标有状态的环境配置库。您可以将代码存储库中的目标环境定义和描述为开发环境、测试环境、生产环境或包含运行特定版本的应用程序和基础设施服务的环境。CI/CD要实现完整的GitOps，你不可避免地需要一个CI/CD流水线，以便每次Git存储库发生变化时，开发团队都可以将相应的基础设施变化交付到指定的环境中。自动交付管道可以将Gitpullrequest连接到编排系统，使得pipeline可以被请求触发，编排系统执行指定的任务。一般来说，GitOps有两种可能的部署策略：推送管道和拉取管道。您可以根据您当前架构需要部署的实际环境在两者之间进行选择。我们来看看这两种策略的各种特点：PushPipelines目前很多流行的CI/CD工具都在使用这种策略。开发人员通常将应用程序的源代码及其部署清单存储在存储库中。当应用程序代码更改时，管道会触发容器映像的构建并将更改推送到适当的环境。由于此策略支持任何类型的基础架构，因此它具有更大的灵活性。然而，它的缺点是它会给CI/CD工具提供对目标环境的写入权限。基于推送的DevOps部署拉式管道（PullPipelines）在开发者社区中，普遍认为GitOps的拉式管道方式是一种更安全的策略。这种方法引入了运算符的概念。它是管道和编排工具之间的组件。运维人员能够不断地将环境存储库中的目标状态与已部署基础设施的实际状态进行比较。如果操作员检测到任何修改，它会更改基础架构以适应环境存储库。同样，它可以监控镜像注册表以识别需要部署的新版本镜像。正如在基于拉取的DevOps部署中所见，在GitOps中，相应的环境仅在环境存储库中发生修改时才会更新。相反，如果未以环境存储库中定义的任何方式修改已实施的基础架构，则系统将自动恢复。在实际项目中，大多数应用程序同时涉及多个环境。为此，GitOps允许您创建多个管道以同时对多个环境存储库进行更改。当然，你也可以在环境仓库中使用单独的分支来管理多个环境。我们可以通过将算子部署到生产环境来响应单个分支的变化，通过部署到测试环境来响应另一个分支的变化。GitOps的优势由于GitOps专注于Git工作流、IaC、CI/CD管道、不可变服务器、跟踪和可观察性等良好实践模型，它代表了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修改的应用程序、软件和框架，开发团队可以清楚地了解整个项目端到端的工作流程，并可以通过Gitday-to全面复现-日常业务运营。GitOps的实施建立稳定的代码审查和测试流程。通过仔细检查代码变更，我们能够及时发现添加全局变量等操作，并且可以通过提交拉取请求而不是直接提交变更来验证代码。在审查和合并拉取请求之前，不会触发管道。此举有效维护了代码的高标准和后续系统的稳定性，同时避免了错误代码的发布。持续测试。合并到GitOps通常意味着通过高级自动化机制对要发布的应用程序进行彻底测试。有了GitOps，我们不仅可以相对轻松地实现回滚，还可以通过良好的测试用例，保证代码的质量和可靠性。重点监控。GitOps允许开发人员重复各种操作流程，改进、发布和审查各种可追溯的系统状态。通过专注于监控，我们可以识别并防止任何意外的漂移和系统配置的更改。因此，在开始使用GitOps之前，开发团队有必要检查他们的监控水平和处理变更的能力。拥抱文化。DevOps文化作为当今开发领域的一种优秀策略，可以促进团队协作，更有效地管理基础架构稳定性，更快更流畅地执行应用程序。而GitOps可以让我们在此基础上进一步理解开发运维的协同价值，并提供一套完整的自动化管理方式。总结作为一个非常好的工作流模型，GitOps不仅可以帮助我们有效地处理云基础架构，还可以在更好的协调性、透明度、稳定性和系统持久性方面为工程团队提供许多好处。.原标题：GitOps–DevOpsforInfrastructureAutomation，作者：SaraMiteva
