The term "GitOps" first emerged in the Kubernetes community as a way for organizations to enable Ops teams to move at the pace of application development.
With improved automation and less risk, GitOps is quickly becoming the workflow of choice for infrastructure automation.
According to GitLab Senior Product Marketing Manager Saumya Upadhyaya, the approach to GitOps goes well beyond Kubernetes.
“Before the buzz around GitOps picked up in the DevOps community, GitLab users and customers were applying GitOps principles to all types of infrastructure, including physical servers, virtual machines, containers, and Kubernetes clusters, both of the multi-cloud flavor and on-premise kind,” Upadhyaya said.
But before we go too far, let’s get an understanding of GitOps.
What is GitOps?
GitOps is an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation.
It's centered around the Git repository as the single source of truth and uses already established Git workflows like merge/pull requests in order to make changes to infrastructure.
The three core components of GitOps, according to GitLab, are:
- Infrastructure-as-Code: GitOps uses a Git repository as the single source of truth for infrastructure definitions.
- Merge Requests: GitOps uses merge requests as the change mechanism for all infrastructure updates.
- Continuous Integration and Continuous Delivery: GitOps automates infrastructure updates using a Git workflow with continuous integration and continuous delivery (CI/CD).
Let’s take a look at the two main approaches to GitOps.
Push-Based Approach
In the push-based approach, a CI/CD tool moves the changes to the environment. Applying GitOps via push is consistent with the approach used for application deployment. In this case, deployment targets for a push-based approach are not limited to Kubernetes.
Pull-Based Approach
An agent installed in a cluster pulls changes whenever there is a deviation from the desired configuration.
In the pull-based approach, deployment targets are limited to Kubernetes and an agent must be installed in each Kubernetes cluster.
Why is GitOps a Good Option?
GitOps Brings Dev and Ops Even Closer Together
The promise of DevOps is to bring development and operations teams together with tools and best practices -- including defined processes -- to help improve the development, testing, and delivery of software.
GitOps inches that idea ever closer, involving operations in workflows and utilizing tools that are in the developers wheelhouse, making communication vital by practice and easier through progression.
Git is Familiar and Accepted
Nearly all developers know Git and are familiar with using its workflows and automated processes for testing and development.
Git is a given in modern software development and natural part of any serious endeavor. It’s open source, requires less overhead in terms of resources, and is available on many platforms and setups.
Git, By Design, Improves Development
Git is a collaborative software tool that lets developers work together to make changes, improvements, and fix problems. Developers can create separate instances of work called branches and build out pieces of a project individually without bumping into their coworkers spaces. Branches can be uploaded to the central repository and merged into the project after review. If there’s a problem with the code down the line, the changes can be rolled back with major problems.
There’s an audit trail of every single update to the software, so managers can roll back to any point in the project. Projects can be moved from place to place easily. Nearly anyone can jump in and start building out features or fixes.
Having this repository as a central part of your software development creates a solid foundation for everything that comes after it.
3 Methods to Employ GitOps Principles Using GitLab
GitLab supports both of the approaches mentioned above, which can be used with and without a Kubernetes agent. Along with the recently introduced Kubernetes agent, GitLab supports GitOps principles by supporting three types of deployment targets and environments:
- The single application for infrastructure code;
- Configurations using CI/CD for automation, and
- Merge requests for collaboration and controls.
Below we unpack three methods for applying GitOps principles using GitLab technology:
1. Push using manually configured CI/CD release targets
The infrastructure configurations are stored in git. The user sets up the supported deployment targets and uses the standard CI/CD workflow to push infrastructure changes.
To ensure the desired state in the repository is consistent with the environment, CI/CD will need to run on a regular schedule to identify drift and reconcile as required. Manual intervention may be required at times to cater to failed pipelines. Many GitLab users have been using this approach to push infrastructure changes to their test, staging, and production environments.
The manual push approach is ideal for both Kubernetes and supported non-Kubernetes environments, such as embedded systems, on-premise servers, mainframes, virtual machines, or FaaS offerings.
2. Push using Terraform
In this approach, an out-of-the box integration with Terraform helps Terraform users seamlessly implement GitOps workflows using GitLab. Terraform manifests are stored in the Git repository where users can collaborate on changes within the merge requests.
The Terraform plan reports can be displayed within the merge requests and the Terraform state can be stored using the GitLab-managed Terraform state backend.
Everything is integrated into GitLab, which spares users from performing these tasks via third-party tools or integrations. The push approach is ideal for both Kubernetes and non-Kubernetes deployment targets that are supported by Terraform.
3. Pull using a Kubernetes agent
In fall 2020, GitLab introduced a Kubernetes agent that initiates a secure web-socket connection from a Kubernetes cluster to a GitLab instance. There is a GitLab server component that polls for any repository changes on the server and informs the agent when there is a deviation between the desired state and the cluster environment.
This process helps minimize the load on the cluster and network.
Whenever a drift is detected the agent pulls the latest configurations from the git repository and updates the environment accordingly. This GitOps approach requires the Kubernetes agent to be installed on every Kubernetes cluster, which can be done with ease as the GitLab Kubernetes agent uses GitOps principles to install and update the agent as required.
This GitOps method is ideal for Kubernetes environments only.
Up next: Push using a Kubernetes agent
GitLab also aims to support GitOps by using a push approach with a Kubernetes agent. The push based approach using manually configured Kubernetes target attaches a Kubernetes cluster to GitLab through a certificate exchange.
This approach leverages the CI/CD workflow for infrastructure automation and is fairly straightforward, but it also introduces risk by opening up a firewall and using cluster admin rights for cluster integration.
To overcome these challenges while leveraging the CI/CD workflow—the push-based approach using the Kubernetes agent aims to reuse the web-socket interface to establish a secure connection between GitLab and the Kubernetes cluster and allows GitLab CI/CD to securely push changes using this interface. When available, this approach would also provide a migration path for users who are currently setting up the Kubernetes integration using a certificate exchange.
The third approach is ideal for Kubernetes environments only. When available, it can be used in conjunction with the pull-based approach to optimize the GitOps workflow.
Accelerate the SDLC with GitOps principles
Whether you are using physical, virtual, containers, Kubernetes—on-prem or cloud-based infrastructures—GitLab uses GitOps principles in a variety of ways to meet your team wherever they’re at.
GitLab supports many different options because we understand the typical organization has a mixed IT landscape, with various heterogeneous technologies in a number of different environments.
Getting started with GitOps can be a challenge. Contact us if you have any questions about DevOps consulting services, GitLab Professional Services, or getting started with your project.