In recent years, GitOps has been catching on among businesses seeking new ways to streamline deployment and delivery processes for modern applications.
The fundamental idea behind GitOps is that application and infrastructure code and state are defined and stored centrally in git repositories for processing and version control. Then those changes are applied to infrastructure through automation.
However, not everyone has experience with this new operational framework – or even understands how it works.
This blog will discuss how you can put GitOps into practice and the fundamentals of GitOps workflows, including the key components, to help you get started in this new direction for better outcomes and more effective collaboration.
How does GitOps work?
GitOps uses Git wherever possible, from development to deployment, with the aim of generating a "single source of truth" related to infrastructure and applications.
Git is used as a change management system for not only application code but also infrastructure code. So the entire set of declaration files is stored in a central place, allowing you to collaborate more effectively on infrastructure changes and vet configuration files with the same rigour you apply to code.
Because of GitOps' declarative processes, it lends itself well as an operating model for Kubernetes since Kubernetes clusters are also managed in a declarative way.
A key idea behind the GitOps concept is the use of pull requests (PRs, also called merge requests or MRs) for operational changes. Whenever a new change is required, a pull request is initialised in a designated Git repository to modify the target cluster's declared state.
Creating a pull request allows you to see an overview of changes in each branch. You can then review changes, add proposed changes, and mention other contributors. Once the changes are approved and merged, they will be applied automatically to the underlying infrastructure.
The best part is that infrastructure changes can be applied through the same pipeline used for software development as an integrated step in the delivery process. The collaborative nature provides unparalleled transparency and improves code quality as errors are caught earlier in the life cycle.
GitOps with GitLab: The bigger picture
Explore the benefits of utilising GitOps through GitLab to truly do everything as code, with more automated interactions and increased clarity of process.
What does a GitOps workflow look like?
GitOps is essentially the application of the Git pull-request workflow in an infrastructure change context. The application source code and declarative environment configuration are stored in a Git repo with workflow support. So here's what a basic GitOps workflow looks like:
- The main branch can represent an environment (dev, test, production).
- You can implement changes in the feature branch.
- Then, you submit a petition to change the main branch (also referred to as a pull request or merge request).
- Infrastructure owners can then collaborate, review, and give feedback on the pull request to approve or reject the change.
- If the pull request/change is approved, the GitOps operator will notice the change in state. The GitOps operator then compares the desired state with the state of the existing infrastructure. Wherever there's a mismatch, the system automatically reconciles the difference by overwriting the existing state with what is described in the Git repository.
Key components of a GitOps workflow
Effective use of GitOps happens when you rely on IaC (infrastructure-as-code), PRs as the request for change and system of record, and CI/CD (Continuous Integration/ Continuous Delivery) automation as core elements in your workflow.
IaC (infrastructure-as-code)
GitOps is a natural progression of the infrastructure-as-code (IaC) concept, which involves the practice of keeping all infrastructure configurations stored as code in a Git repository.
As with IaC, GitOps follows a declarative approach to infrastructure management – meaning you only state what you need deployed, not how.
Pull Requests/Merge Requests
In a GitOps world, pull/merge requests sit at the heart of how infrastructure updates are deployed.
Investing in the process and culture of pull requests enables the code to undergo scrutiny and verification by other team members before any change is approved.
With formal code reviews in place, there are up-to-date audit trails to identify what and when infrastructure changes were made. Plus, it helps everyone improve as a team and build a story around the why behind a change, with historical comments and discussions.
Moreover, troubleshooting tends to be easier since users can quickly resolve any issues that appear with a pull request rather than in the underlying system.
There may also be a collective decision to close a merge request due to the scrutiny it is put through — which is okay, too — since the discussion has been captured and can be referenced for future updates.
CI/CD automation
Another key component of a comprehensive GitOps strategy is automating all infrastructure updates via CI/CD.
Each time a merge hits the trunk branch, automated delivery pipelines deploy the change in the designated environment by comparing the existing infrastructure state to what is described in the Git repository.
Suppose any configuration drift is due to a component failure or an inadvertent manual change. In that case, the system reconciles this difference by configuring the environment to match the exact state defined in the Git source of truth.
Summary
GitOps is on its way to becoming a must-have for efficient infrastructure management in modern software development environments. It's an incredibly powerful workflow pattern that provides a framework to leverage DevOps best practices in application development (version control, CI/CD, and collaboration) for infrastructure automation.
Adopting GitOps best practices allows infrastructure management to become a core part of the development pipeline. This means any application change that requires infrastructure modification can be bundled together.
Version control via Git ensures every change throughout the application lifecycle is traceable and auditable. With a proper audit trail, you can significantly reduce the risk of unwanted changes (drift) and have the flexibility to fix them before they go into production. The result is a process with vastly improved consistency, safety, stability, and transparency.
Automation, alongside collaboration at scale, increases deployment frequency and reduces lead times. This increased agility allows businesses to respond to better market demands to build and maintain a competitive advantage.
Contact us to learn how to manage infrastructure easily while increasing your system's visibility, reliability, and stability.
