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

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

Kubernetes allows us to simply use declarative configuration files to manage our application deployment and other infrastructure components (for example, we are all YAML developers now). This allows us to put all these files in the Git repository and then hang it on the pipeline (Jenkins, GitLab, etc.), which applies these changes to the cluster, and then there is GitOps.

In order for the work to work properly, we must ensure that the only way to change the cluster is to submit it on the Git repository. GitOps is not specific to Kubernetes, and the same principle can be applied to any other declarative configuration management environment.

It can be said that many enterprises have begun to adopt GitOps, but now is the time for the industry to fully realize its potential.

1. Storage environment change history

Only by updating the configuration in the corresponding Git repository can the application environment be changed. This will create a complete history of state changes, including records of who made the changes and why. You can read the history through the Git user interface you are using.

2. Easily roll back to the previous state

Once all our changes are stored as Git history, we can easily roll back an environment to any previous state. By restoring some commit, we can go back to our previous working state.

3. Ensure the security of deployment

Once all changes to the cluster go through GitOps repo, users and continuous integration (CI) processes no longer need to access the cluster. This greatly reduces the attack surface, especially the network access to Kubernetes API.

No matter how the deployment process is implemented, it can run within the cluster and pull the configuration from the Git. Its access to API is restricted using role-based access control (RBAC). This greatly improves the security of the cluster and prevents any malicious remote changes on the API server.

4. lightweight examination and approval procedure

Developers are always untrusted when modifying a production environment. As a result, a four-eye approval process (four-eyes approval processes) has been established in many companies, and GitOps provides an easy way to implement them, regardless of the reason for establishing the approval process.

The implementation depends on the Git server you use, but the focus is on giving developers the right to create pull requests on Git repo, while giving another group the right to review and merge. Most Git servers have a good UI to check for changes and approve pull requests-so this solution is not only cheap but also user-friendly.

5. Modular architecture

GitOps has three parts: Git repo, the deployment process, and a process to automatically update the version in Git repo. These three can evolve or replace each other independently.

On one side is a component writing in Git repo, and on the other side is a component reading. The structure of Git repo serves as a bridge between these components. Because this is a fairly loose coupling, the two sides can be implemented in different ways or even different technology stacks.

6. Tool-independent architecture

The modularity mentioned in point 5 shows that the GitOps architecture is an architecture that can flexibly assemble the best tools. Of course, any popular Git server can do the Git part of the work, and FluxCD or ArgoCD can be responsible for synchronizing the repo to the cluster. JenkinsX is a tool that handles all parts of the process, including creating Git repos and updating them with a new version when building new Docker images.

7. Reuse existing knowledge

By placing Git at the heart of the deployment process, you can take full advantage of the Git knowledge that most developers and operators already have. No new tools are required to browse the deployment history or implement the approval process. All processes are done with tools that everyone is familiar with.

8. Compare different environments

When you have a chain of environments from development to user acceptance testing (UAT) to production, tracking the differences between these environments is troublesome. Thanks to the declarative configuration stored in Git repos, it makes handling differences between environments as simple as comparing a set of YAML files.

We have great tools to do this, so it will no longer be a problem. More importantly, creating a new environment from scratch is as simple as copying and pasting these files into a new repo.

9. Backup out of the box

Since the state of your environment is stored in Git, if something happens to etcd on Kubernetes, you will never lose data. Because it is a natural backup of your cluster status.

10. Test your changes like application code

You can test the application code for possible destructive changes in the environment. Place the changes on a branch and run the CI pipeline on it. Your CI tool will be able to run tests and set the pull-request status in Git to green or red based on the test results. Once everything has been tested and reviewed, you can merge it into master.

This sounds very simple, but automated testing is an often overlooked task in infrastructure management. Although GitOps doesn't make it any easier, at least it provides you with the same familiar workflow you use elsewhere.

11. Highly available deployment infrastructure

It is important to keep the deployment infrastructure consistent. Git repo servers are usually set up in a replicated, highly available manner. Source code is something that all developers need to access most of the time, so using Git as the source code for deployment does not put an additional burden on Git itself.

At this point, the study of "what are the reasons for adopting GitOps" 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.