At a very high level, you can think of GitOps as an iteration of DevOps that is centered around source code management. For most developers source control means using Git, it's pretty much the de-facto standard. So, let's start with this idea that DevOps is the foundation of GitOps. It applies a Git-centric approach on top of some common DevOps principles, practices, and tools. So, we mix these principles centered around Git with our DevOps workflows to get this new way of operating and managing software.
The principles established by the GitOps community stem from the idea that all system changes are made through source control, like Git, and from there, they're automatically deployed. Developers have been doing this forever, however, GitOps shifts this practice to the operations side, where infrastructure configuration is stored as code.
GitOps is a method for using Git as a single source of truth for declaratively managing distributed systems. It involves using Git to store and version the desired state of a system, and then using automation tools to ensure that the actual state of the system matches the desired state. This approach allows for easy collaboration, versioning, rollbacks, and auditing of changes to the system. GitOps also allows for a separation of concerns between the developers and operations teams, as developers can focus on writing code and operations teams can focus on ensuring that the system is running as expected.
The benefits with GitOps
GitOps can be helpful in a variety of situations, particularly when it comes to managing distributed systems such as Kubernetes clusters or cloud infrastructure. Some of the key benefits of using GitOps include:
Productivity
-
When you adopt a GitOps workflow, deploying a change starts with Git for every change every time.
-
Git becomes the only way for to make a change to the system.
-
Once a commit is made, automation takes over to deploy the change to the running system.
Stability
-
Because the GitOps pattern uses automation to deploy changes, the workflow is repeatable and consistent.
-
This makes system operations more predictable and less prone to human error, which causes your rate of successful deployments to increase.
-
If your system does experience an issue, all it takes is another Git commit that undoes the change to roll back the system to its last working state.
-
In the event of a complete meltdown, GitOps allows you to quickly rebuild the entire system using the declarative infrastructure code that is stored in Git that describes the entire system.
Transparency
-
With GitOps, operations become transparent, because Git is the only way to make a change to the system. And it's where the entire system is described.
-
With Git, team members can review, discuss, and approve the changes to the system that are being made using a pull request.
-
Anyone or anything with access can inspect the code. This includes automated tools that enforce security practices.
Security
-
GitOps provides a balance between strong security controls and the transparency that developers need to do their job.
-
Because the work and discussion around changes is centralized in Git, the workflow naturally builds an audit log.
-
You get traceability of who made or approved each change, which can be important if you're working in a highly regulated environment.
-
Arguably, the most important security benefit of GitOps is that changes to the runtime state of the system are only applied by agents running in the system.
-
The need for external access to the system through tolls like SSH is eliminated. And it restricts how we make changes to a single method.
Principles of GitOps:
If we think of GitOps as a pattern, there are four principles that make up that pattern.
Declarative System Description
The first principle requires us to describe our system declaratively. This means, we store data that describes the desired state of the system, sort of like a blueprint.
Single Source of Truth
The second principle requires that we store that description of our system within Git. This means, we agree to keep the official blueprints, describing the desired system state version within Git. If we want to change the blueprint, it must be done via a git commit.
Automated Change Delivery
When we change the blueprint, the changes can only be applied to the running system through automation. Changed delivery is 100% automated. There are no manual changes in GitOps.
Automated State Control
The final principle ensures that our running system stays aligned to the desired state through automation, suppose if the running system drifts away from what we have described in Git, an operator within the system will heal it by returning it back to the desired state.
Summary
The growing interest in GitOps is bringing a new world of benefits to infrastructure automation. It is time-efficient, it allows you to run highly available services, operators can be much more productive when they have many small things on which they can work at the same time, and it is coordinated using the same protocol that you use to store your data (i.e., git). In this article we uncovered these benefits and some of the GitOps principles that we follow and how they are applied to our setup. Follow us on our next article: An implementation guide to GitOps and if you are interested in this topic and have deeper questions, please feel free to email me.
