一种处理云原生项目的新方法- GitOps是什么 为什么要研究它?
Around 2017, a new way of approaching Cloud Native projects emerged. It is a framework in which decentralized version management, CI/ CD, and error tracking are merged to make life easier for operators: the GitOps.
2017 年左右,出现了一种处理云原生项目的新方法。它是一个框架,其中分散的版本管理,CI/CD和错误跟踪被合并,以使操作员的生活更轻松:GitOps。
The History of GitOps GitOps历史
Before we go into more detail about what exactly GitOps is, it's interesting to look at its origin and the problems it tries to solve.
在我们更详细地介绍 GitOps 到底是什么之前,看看它的起源和它试图解决的问题很有趣。
The GitOps story begins in 2016 at Weaveworks, a company that had just released a Software As A Service (SaaS) offering - Weave Cloud - powered by Kubernetes and EC2.
GitOps的故事始于2016年的Weaveworks,该公司刚刚发布了由Kubernetes和EC2提供支持的软件即服务(SaaS)产品Weave Cloud。
有一天,一名员工说,他计划对他们的基础设施进行更改,如果出现问题,可能会摧毁他们的整个系统。正如墨菲定律所指出的那样,进行了更改,导致了一系列故障,导致几乎所有服务都无法运行,包括Weave Cloud和所有托管软件。
However, the Weaveworks team managed to restore their entire infrastructure in less than an hour, without any loss of data or significant customer impact. This performance was made possible by one key factor: their entire configuration was declared and versioned on Git repositories.
但是,Weaveworks 团队设法在不到一个小时的时间内恢复了整个基础架构,没有丢失任何数据或对客户产生重大影响。这种性能是由一个关键因素实现的:它们的整个配置是在 Git 存储库上声明和版本控制的。
Indeed, the life cycle of their infrastructure was simple: never allow an irreversible change and always be able to roll back in case of a problem.
事实上,他们的基础设施的生命周期很简单:永远不允许不可逆转的更改,并且始终能够在出现问题时回滚。
After this incident, satisfied with their high resilience capacity, the Weaveworks teams wrote down the first major rules of what they would later call GitOps:
在这次事件之后,Weaveworks团队对他们的高弹性能力感到满意,他们写下了他们后来称之为GitOps的第一个主要规则:
- The entire system must be described in a declarative manner 必须以声明性方式描述整个系统
- The desired state of the system is versioned in Git 系统的所需状态在 Git 中进行版本控制
- Approve only those changes that can be automatically applied to the system 仅批准可自动应用于系统的更改
- Use software to verify and ensure system compliance and alert in case of divergence. 使用软件验证并确保系统合规性,并在出现分歧时发出警报。
This operational framework addresses the need for good Infrastructure as Code (IaC) management in a Cloud Native framework (an approach to software development that uses cloud computing to build and run scalable cloud applications).
该操作框架满足了云原生框架(一种使用云计算构建和运行可扩展云应用程序的软件开发方法)中对良好基础架构即代码 (IaC) 管理的需求。
As a result, it has been rapidly adopted by other companies as well as large Cloud Providers (AWS, Google Cloud, and Azure) due to their dominant market position.
因此,由于其市场主导地位,它已被其他公司以及大型云提供商(AWS,Google Cloud和Azure)迅速采用。
With simple and clear principles, everyone can propose their own concrete application of the GitOps method via numerous technologies. Even if the framework was originally designed for tools like Kubernetes, it is possible to use it with other tools like Terraform, Ansible, or any other system using IaC. The important thing is that the tools are compatible with the GitOps philosophy.
通过简单明了的原则,每个人都可以通过众多技术提出自己的 GitOps 方法的具体应用。即使该框架最初是为 Kubernetes 等工具设计的,也可以将其与其他工具(如 Terraform、Ansible 或任何其他使用 IaC 的系统)一起使用。重要的是这些工具与 GitOps 理念兼容。
What is GitOps? 什么是GitOps
Weaveworks defines GitOps today as "A path to a developer-centric application management experience. " The idea is to manage infrastructure provisioning and deployment in an automated way via tools like Git, all in line with Infrastructure as Code.
Weaveworks 将今天的 GitOps 定义为“通往以开发人员为中心的应用程序管理体验的途径”。这个想法是通过 Git 等工具以自动化的方式管理基础架构配置和部署,所有这些都符合基础架构即代码。
As a reminder, Infrastructure as Code (IaC) is about managing and provisioning infrastructure using lines of code rather than manual processes.
提醒一下,基础结构即代码 (IaC) 是关于使用代码行而不是手动过程来管理和预配基础结构。
By using adapted technical tools, it becomes possible to build infrastructure via simple configuration files. This allows great flexibility of use and the guarantee of providing similar environments at each execution.
通过使用适应的技术工具,可以通过简单的配置文件构建基础设施。这提供了极大的使用灵活性,并保证在每次执行时提供类似的环境。
It is in the continuity of the infrastructure as Code that GitOps is registered.
GitOps 是在基础结构即代码的连续性中注册的。
The infrastructure of a project is no longer managed manually according to the needs and updates, but processed and described in the form of code defining the desired state of the latter.
项目的基础设施不再根据需要和更新手动管理,而是以定义后者所需状态的代码形式进行处理和描述。
The desired state of infrastructure is then "declared", it is not a set of instructions allowing the implementation of a system on a particular type of machine but a set of facts, and expected final results.
然后“声明”所需的基础设施状态,它不是一组允许在特定类型的机器上实现系统的指令,而是一组事实和预期的最终结果。
This reference state will be used as the only source of truth when it comes to the infrastructure, whether by the teams or for the various IT tools used on the project. So if a change is made to its declaration, the infrastructure should be updated to match the latest version of the desired state.
当涉及到基础结构时,此引用状态将用作唯一的事实来源,无论是由团队还是针对项目中使用的各种 IT 工具。因此,如果对其声明进行更改,则应更新基础结构以匹配所需状态的最新版本。
The idea of automation is very important in GitOps. Once a change is approved, it should be implemented as quickly as possible with minimal human intervention.
自动化的概念在 GitOps 中非常重要。一旦更改获得批准,应以最少的人为干预尽快实施。
This desire for automation translates into a continuous integration and continuous deployment (CI/CD) approach that is usually found on the software development side. Indeed, the GitOps workflow is similar since code is sent to remote repositories but this time if to manage the infrastructure.
这种对自动化的渴望转化为通常在软件开发端发现的持续集成和持续部署 (CI/CD) 方法。事实上,GitOps 工作流是类似的,因为代码被发送到远程存储库,但这次是为了管理基础设施。
When a new change is proposed, CI/CD pipelines can be launched to check that it is compliant with the project standard. If it is, the change can be validated and merged to give a new desired state.
提出新的更改时,可以启动 CI/CD 管道以检查它是否符合项目标准。如果是,则可以验证并合并更改以提供新的所需状态。
This new state is then detected by a software operator. The operator will then compare this state with the actual state of the deployed infrastructure and update it if there is a difference.
然后,软件操作员会检测到此新状态。然后,操作员将此状态与已部署基础结构的实际状态进行比较,并在存在差异时对其进行更新。
With a GitOps approach, there's no need to manage clusters by applying your new configurations by hand: if the CI tests pass, it will be automatically deployed for you. The use of CI/C techniques avoids many careless mistakes and saves a lot of time for your teams.
使用 GitOps 方法,无需通过手动应用新配置来管理群集:如果 CI 测试通过,它将自动为你部署。使用 CI/CD 技术可以避免许多粗心的错误,并为您的团队节省大量时间。
Finally, the last essential point of GitOps is the idea of monitoring.
最后,GitOps 的最后一个要点是监控的思想。
Once the infrastructure is deployed by the CI/CD, we want to know if the current state of the infrastructure corresponds to what we asked.
CI/CD 部署基础结构后,我们想知道基础结构的当前状态是否与我们要求的内容相对应。
For this, there are many software solutions that will perform this monitoring and automatically fix problems. This way, an infrastructure will constantly repair itself, guaranteeing a high level of service and freeing up the time of maintenance teams.
为此,有许多软件解决方案可以执行此监视并自动解决问题。这样,基础设施将不断自我修复,保证高水平的服务并腾出维护团队的时间。
In the case of a problem that is difficult to control automatically (a program that crashes in a loop, a misconfiguration, etc.), the infrastructure managers will be notified quickly and precisely about the nature of the problem, thus making interventions more efficient.
在难以自动控制的问题(循环中崩溃的程序,配置错误等)的情况下,基础设施管理人员将快速准确地收到有关问题性质的通知,从而使干预更有效。
The benefits of GitOps GitOps 的优势
Once implemented, GitOps will greatly increase the deployment efficiency and resiliency of your infrastructure. It will be much easier to roll back in case of a problem and you will always know what resources you need to deploy your infrastructure.
实施后,GitOps 将大大提高基础结构的部署效率和复原能力。如果出现问题,回滚会容易得多,并且您将始终知道部署基础结构所需的资源。
In addition, all your systems will be more stable thanks to the automation via CI/CD of the deployments while guaranteeing greater readability on the actions which are made there. Indeed, each change in your IaC is versioned and if it leads to unexpected changes it will be easily detected by the monitoring.
此外,由于通过CI/CD实现部署的自动化,您的所有系统都将更加稳定,同时保证在那里进行的操作具有更高的可读性。实际上,IaC 中的每个更改都经过版本控制,如果它导致意外更改,则监视将很容易检测到它。
Tracing a problem thus becomes easier, which is a significant advantage for the restoration of service and the consideration of security issues while saving considerable time for teams.
因此,跟踪问题变得更加容易,这对于恢复服务和考虑安全问题具有显着优势,同时为团队节省了大量时间。
At the same time, GitOps allows you to have a global and easily readable vision of your infrastructures via the IaC. This makes it easier for you to control them and adapt the resources needed for their operation. This better control of resources also leads to better control of the costs associated with them.
同时,GitOps 允许您通过 IaC 获得基础架构的全局且易于阅读的愿景。这使您可以更轻松地控制它们并调整其操作所需的资源。这种对资源的更好控制也导致更好地控制与之相关的成本。
For example, managing the scaling of a set of Kubernetes nodes hosted by a cloud provider is now done in a few lines of code and can easily save you money without much effort.
例如,管理由云提供商托管的一组 Kubernetes 节点的扩展现在只需几行代码即可完成,并且可以轻松节省资金而无需太多努力。
By using simple and unified tools, the GitOps approach also facilitates collaboration between developers and operators by standardizing the overall development approach of your projects. The use of techniques that are already well known to developers, such as CI/CD pipelines, allows them to better understand operator issues. This makes it possible to be much more efficient in solving problems and to considerably reduce their number during development.
通过使用简单统一的工具,GitOps 方法还通过标准化项目的整体开发方法来促进开发人员和操作员之间的协作。使用开发人员已经熟知的技术(如 CI/CD 管道)使他们能够更好地了解操作员问题。这使得可以更有效地解决问题,并在开发过程中大大减少问题的数量。
A GitOps practice GitOps 实践
GitOps is not a single, ready-made product or technical solution. There are a thousand ways to use it, and each project must find a way to implement it that fits its needs. Here is a concrete example of the GitOps approach used on several projects at Padok.
GitOps 不是一个单一的、现成的产品或技术解决方案。有一千种使用它的方法,每个项目都必须找到一种适合其需求的方式来实现它。以下是在Padok的几个项目中使用的GitOps方法的具体示例。
Code management 代码管理
For all the code repository parts we use Gitlab on which we manage the arrival of all new features/modifications via the Merge Request system. This is a tool that allows us to organize the code review and validate the modifications before merging them with our common repository used as a single source of truth within the project. We use Gitlab in conjunction with Gitlab-CI, an integrated CI/CD management tool that allows us to test code, and do application builds and deployment simulations automatically. Another important point, this CI/CD tool is manageable via IaC.
对于所有代码存储库部分,我们使用Gitlab,我们通过合并请求系统管理所有新功能/修改的到达。这是一个工具,允许我们组织代码审查并验证修改,然后再将它们与项目中用作单一事实来源的通用存储库合并。我们将 Gitlab 与 Gitlab-CI 结合使用,Gitlab-CI 是一个集成的 CI/CD 管理工具,允许我们测试代码,并自动进行应用程序构建和部署模拟。另一个重要点是,此 CI/CD 工具可通过 IaC 进行管理。
Application deployment 应用部署
For the deployment of applications on the infrastructure, we use Kubernetes and ArgoCD.
为了在基础设施上部署应用程序,我们使用 Kubernetes 和 ArgoCD。
Kubernetes is a container orchestrator, it aims to simplify and automate the deployment and maintenance of distributed systems. It declares in the form of code (still the IaC) the applications and other desired services, and Kubernetes automatically ensures their proper functioning.
Kubernetes是一个容器编排器,它旨在简化和自动化分布式系统的部署和维护。它以代码(仍然是 IaC)的形式声明应用程序和其他所需的服务,Kubernetes 自动确保它们正常运行。
ArgoCD is a tool that connects to a Git repository and will automatically detect the validation of a Merge Request and that of the new code. When this happens, ArgoCD will synchronize the Kubernetes cluster to match the new desired state. Thus, all applications are always up to date and operational, while limiting the number of direct human interventions.
ArgoCD是一个连接到Git存储库的工具,它会自动检测合并请求和新代码的验证。当这种情况发生时,ArgoCD将同步Kubernetes集群以匹配新的所需状态。因此,所有应用程序始终是最新的和可操作的,同时限制了直接人为干预的数量。
Infrastructure management 基础设施管理
For the broader management of the infrastructure (network management, internal resources, security policies, etc.) we use Terraform. This is a resource provisioning tool that will automatically deploy the resources/infrastructure declared in a configuration file. Once again, Terraform takes on all the concepts of Infrastructure as Code.
为了更广泛地管理基础设施(网络管理、内部资源、安全策略等),我们使用 Terraform。这是一个资源预配工具,将自动部署配置文件中声明的资源/基础结构。再一次,Terraform采用了基础设施即代码的所有概念。
Monitoring 监测
Finally, for the monitoring tools, we use Prometheus and Grafana to have a graphical view of the different metrics concerning our infrastructures. Prometheus is the tool that collects information on our various machines and Grafana is the tool that will format them (graphs, tables, etc.) to manage any alerts.
最后,对于监控工具,我们使用 Prometheus 和 Grafana 来查看有关我们基础设施的不同指标的图形视图。Prometheus 是收集我们各种机器信息的工具,而 Grafana 是格式化它们(图形、表格等)以管理任何警报的工具。
Conclusion 结论
In the end, GitOps stands out as a reliable and efficient framework when it comes to Cloud Native projects. These simple and affordable concepts make the method easily accessible. If you are already working with IaC tools, the productivity gains and the daily management comfort will be major assets for you and your teams.
最后,GitOps 在云原生项目中脱颖而出,成为一个可靠且高效的框架。这些简单且经济实惠的概念使该方法易于访问。如果您已经在使用 IaC 工具,那么生产力的提高和日常管理的舒适度将是你和团队的主要资产。
However, be careful to keep in mind that this is not a miracle method adapted to all projects without any adjustment. Certain flexibility with regard to this framework is necessary to reveal its full potential. Indeed, the "limitation of human intervention" part is an objective that can quickly turn out to be a constraint if it is taken at face value.
但是,请注意,这不是适用于所有项目的奇迹方法,无需任何调整。这一框架必须有一定的灵活性,以充分发挥其潜力。事实上,“人为干预的限制”部分是一个目标,如果从表面上看,它很快就会变成一种约束。
It's important to think ahead about your project challenges to determine how to use the GitOps framework to maximize the way you work without making your life more difficult.
重要的是要提前考虑您的项目挑战,以确定如何使用 GitOps 框架来最大化您的工作方式,而不会使您的生活更加困难。
文章转载自公众号:DevOps云学堂