Shulou(Shulou.com)05/31 Report--

GitOps in how to extend DevOps to K8S, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can get something.

There have been some revolutionary changes in programming over the past decade. One of these stems from the practice around DevOps, which integrates development and operations teams into a shared workflow, as well as continuous integration and continuous delivery (CI/CD), through which CI/CD,Devops teams can provide continuous updates to the code base. Another change comes from the migration from a single code base to cloud-based microservices that run in containers managed by orchestration platforms such as Kubernetes.

Even if there is a platform such as Kubernetes to orchestrate coordination, container-based applications running on cluster systems or in the cloud can still be complex and difficult to provision and manage. GitOps is an emerging set of practices that aims to simplify this management task by applying technologies from the Devops and CI/CD world.

The key to GitOps is the concept of IaC, which provides infrastructure in the same way that DevOps is used to provide applications. So, not only the application, but also the underlying host and network are described in the file, which can be like other code in the version control system. then the automation process is used to integrate the real-world applications with the applications described in these files.

In GitOps's terms, the code in the version control system is the only source of truth about what the application should look like in production (single source of truth).

Define GitOps

Weaveworks is the company that has made the greatest contribution to the popularization of GitOps concepts. We'll cover the role of Weaveworks in more detail later, but first, let's take a look at the company's definition of GitOps, which has two aspects:

The operation and maintenance model of Kubernetes and other cloud native technologies provides a set of best practices for unified deployment, management, and monitoring of containerized clusters and applications. GitOps is a road to the experience of developers of management applications; here, end-to-end CI/CD pipelining and Git workflow can be applied to both operations and development. In other words, GitOps is a specific set of practices designed to manage Kubernetes and similar platforms. As more and more development teams adopt DevOps practices and migrate code to the cloud, GitOps will also be suitable for a wider range of applications. But to understand the secrets of GitOps and the problems it can solve, we need to talk about its components.

Git definition

In GitOps, Git refers to the very popular distributed version control system developed by Linus Torvalds in 2005. Git is a tool that allows developers to work together on an application code base, storing various branches of code that they can patch before merging them into production code. A key concept of Git is the pull request, where developers formally require that some of the code they are writing be integrated into another branch of the code base.

The Git pull request provides an opportunity for team members to collaborate and discuss before reaching a consensus on whether new code should be added to the application. Git also stores older versions of the code, which can be easily rolled back to the previous good version if something goes wrong, and allows you to quickly see the changes between the two changes. Git is probably best known as the underlying part of GitHub, a cloud-hosted version control system, but Git itself is open source software that can be deployed anywhere, whether it's an in-house server or your PC.

It is important to note that although we generally think of Git as a computer programming tool, it really depends on how you use it. Git is happy to use any text file as your "code base", for example, it can be used by authors to record the editing of collaborative works. This is important because most of GitOps's core code base consists of declarative configuration files rather than executable code.

Before we move on, I'd like to emphasize one last thing-- although there is "Git" in the name, GitOps does not actually need to use Git. Teams that are already in use with other version control software, such as Subversion, can also implement GitOps. But in the Devops world, Git is widely used to implement CI/CD, so most GitOps projects end up using Git.

What is the CI/CD process?

The full explanation of CI/CD is not really within the scope of this article, but because CI/CD is at the core of GitOps's work, we need to give a brief introduction to it. Half of the continuous integration in CI/CD is achieved by version control repositories such as Git. Developers can make continuous small improvements to the code base instead of launching huge, single new versions every few months or years. Continuous deployment is achieved through automated systems called pipeline, which can build, test, and deploy new code into production.

Again, we've been talking about code here, which is usually reminiscent of executable code written in programming languages such as C, Java, or JavaScript. But in GitOps, the "code" we manage is mainly made up of configuration files. This is not a small detail, but the core of GitOps's work. As we said, these profiles are the "only source of truth" (single source of truth) that describes what our system should look like. They are declarative, not instructive. This means that the configuration file will not say "start ten servers", but simply say "this system includes ten servers".

The CI half of the GitOps equation allows developers to quickly introduce adjustments and improvements to these configuration files; when automated software agents do their best to ensure that the real-time version of the application reflects the description in the configuration file, the CD part tends to be a declarative model in GitOps.

GitOps and Kubernetes

As we mentioned, the concept of GitOps originally revolved around managing Kubernetes applications. With what we now know about GitOps, let's review Weaveworks's GitOps discussion to see how they describe how to update Kubernetes managed based on GitOps principles. The following is a summary of the whole process:

A developer makes a Git pull request for a new feature. Review and approve the code and merge it into the main code base. The merge triggers the CI/CD pipeline, automatically tests and rebuilds the new code, and deploys it to the warehouse. The software agent notices the update, extracts the new code from the repository, and updates the configuration file in the configuration repository (written in YAML). The software agent in the Kubernetes cluster detects that the cluster is obsolete based on the configuration file, pulls changes, and deploys new features. Weaveworks and GitOps

Obviously, steps 4 and 5 here have done a lot of hard work. The software agent that magically synchronizes the "source of truth" in the Git repository with real-world Kubernetes applications is the magic that makes GitOps possible. As we said, in GitOps terminology, the process of making a real-time system more like the ideal system described in the configuration file is called convergence. When the real-time system is out of sync with the ideal system, that is disagreement. Ideally, integration can be achieved through automated processes, but there is a limit to what automation can do, and sometimes human intervention is necessary.

We describe this process here in general terms, but in fact, if you do look at Weaveworks's page, the "software agent" we mentioned is part of the company's Weave Cloud platform. The word "GitOps" was coined by Weaveworks's CEO Alexis Richardson to make the Weaveworks platform attractive to developers who are already immersed in the DevOps and CI/CD world.

But Weaveworks never claimed to have monopolized GitOps,GitOps more of an idea and a set of best practices than a specific product. As the blog of CloudBees, the company that provides CI/CD solutions, points out, GitOps represents an open, vendor-neutral model developed for managed proprietary Kubernetes solutions from large cloud vendors such as Amazon, Google and Microsoft. CloudBees offers its own GitOps solution, as do some other players in this field.

Advantages of GitOps:

Observability: GitOps systems provide monitoring, logging, tracking, and visualization for complex applications, so developers can see where and where something went wrong. Version control and change management: obviously, this is a key advantage of using a version control system like Git. Defective updates can be easily rolled back.

Easy to adopt: GitOps builds on development skills that many developers have already mastered.

Increase productivity: GitOps can increase productivity like development projects and CI/CD.

Auditing: with Git, each operation can be traced to a specific submission, so that the cause of the error can be easily traced.

Even if you don't use Kubernetes,GitOps, it's likely that sooner or later it will become part of your workflow.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.