Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what is the working principle of GitOps". In daily operation, I believe that many people have doubts about the working principle of GitOps. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "what is the working principle of GitOps?" Next, please follow the editor to study!

working principle

GitOps adheres to the core philosophy of DevOps-"build it and deliver it (you built it you ship it)". It allows developers to make pull requests in the Git tool of their choice, triggering the deployment of Kubernetes clusters, thus making Git the only source.

Obviously, the idea is to replace push-based pipes with pull-based pipes, allowing developers to perform deployments directly based on their pull requests. Once the developer executes the merge or open request, the infrastructure triggers a series of events during deployment. As soon as the GitOps operator (operator) detects such a change, it causes a change in the declaration of another operator and deploys it to the cluster. For example, you can use the following tool stack to implement GitOps:

Use Bitbucket as your Git VCS tool.

Use Docker to store your various images.

Use Amazon S3 to store various Helm charts.

Pull the chart with AWS Lambda and submit it to the cluster repository.

Use Weaveworks Flux to detect changes in the cluster repository and adjust accordingly.

Of course, the actual infrastructure to implement such functionality may be different in your tool stack, but the mechanism is similar.

Here are the GitOps workflows that can be implemented:

Use CI (continuous integration) tools such as Bitbucket pipes to push various Docker images to hosting tools such as Quay.

Various cloud functions copy different configurations and helm diagrams to the main git repository from the main storage bucket.

GitOps operators such as Weaveworks Flux update the cluster based on various configuration diagrams and extract different helm diagrams through the Lambda function.

Of course, each of the tools described in the above technology stack has a corresponding alternative, and the development team can choose the most appropriate tool to achieve the goals of DevOps. For example, the Jira feature, which is also part of the Atlassian suite, can easily work in conjunction with Bitbucket. Therefore, if a pull request is created in Bitbucket, questions in Jira are automatically sent to a custom "deployment". This will greatly simplify the DevOps practice process from design to release.

Similarly, when considering that the continuous delivery mechanism implemented through GitOps may fail, we can add other monitoring tools to provide much-needed visibility. For example, Thundra.io can be used to monitor the AWS Lambda function triggered by S3 to ensure that no failure occurs when the changes are committed to the cluster repository.

In the same way, we can also take advantage of the integration of Thundra.io to send alerts to alarm tools such as Opsgenie, which in turn notify the right person on duty to quickly resolve any problems caused by deployments triggered by pull requests.

It can be seen that we can improve the reliability and convenience of GitOps practice by adding more functions to the GitOps engine.

Bring the convenience of Kubernetes to

In general, GitOps can provide converged, idempotent, deterministic, and automated capabilities for Kubernetes deployment. According to the powerful convergence mechanism of Kubernetes, it will constantly try to change the state of the cluster, so that all kinds of convergence applications have the same results. And these will be triggered automatically and quickly.

Kubernetes's choreographer (orchestrator) continues to apply changes to the cluster until the cluster converges to the state defined by the configuration update, that is, to meet the configuration state expected by the developer or SRE staff. This applies not only to all Kubernetes resources, but also to custom resources (Custom Resource Definitions,CRD) or extensions to Kubernetes.

The entire GitOps process begins by defining a desired state in the Git repository, and then the Git is located as the only source. In addition, we need to ensure that the committed changes match the cluster so that the mark indicates whether the cluster has converged to the desired state or deviated from that state.

When the expected state is different from the actual state, the convergence operator in Kubernetes actively tries to make up for the difference between the two states, that is, based on those commits to the Git, trigger a "difference" alert of the change to indicate that further convergence is still needed. Therefore, this means that all commits result in verifiable and idempotent changes to the cluster. Of course, Kubernetes may also generate rollbacks on demand. As far as its mechanism is concerned, rollback can be seen as further convergence to the previous state.

Finally, if there are no more "differential" alerts or only "aggregate" alerts in the system, the mechanism assumes that the actual state has reached the desired state. In fact, we can use callbacks, or write-back events, to set this aggregation state.

At this point, we can realize that GitOps depends on the concept of IAC. That is, the infrastructure is defined programmatically, and the actual state of the infrastructure changes accordingly. This is the pull-based deployment we mentioned earlier, which is different from the traditional push-based deployment.

Related tools

As you know, DevOps is a vast area that is not limited to the software industry. On the other hand, GitOps is just a new development practice in the process of software industry developing in a more agile and reliable direction. More precisely, as technology trends change, development practices must adapt to available technologies, and GitOps is an excellent example of how teams and organizations track technology developments and continue to advance development practices. It is worth mentioning that operators such as Weaveworks Flux can help you enable GitOps in your cluster very well. Of course, you can also choose other alternatives such as Spinnaker.

In addition, considering that continuous deployment may bring risks to the build environment, we can test the system with full coverage by adding tools such as Thundra.io and Opsgenie to reduce risk points and ensure some observability and event management capabilities.

At this point, the study on "how GitOps works" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.