Understand How GitOps Goes Beyond Kubernetes

Saumya Upadhyaya

Sr. Product Marketing Manager, GitLab

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.

At GitLab, the approach to GitOps goes 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 (multi-cloud and on-premise).

What is GitOps?

There are two main approaches to GitOps, a push-based approach and a pull-based approach.

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
Merge requests for collaboration and controls

Below we unpack three methods for applying GitOps principles using GitLab technology:

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.

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.

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.

Achieve powerful results. Contact us to learn more about how GitOps can work in your environment.

GET STARTED

Try GitLab Free for 30 Days

Test GitLab’s seamless DevOps experience with a single, scalable interface for development, operations, and security teams. See why over 100,000 organizations trust GitLab with their DevOps workflow.

DevOps-as-a-Service (DaaS)

Designed to be an on-demand and easily consumable offering, our DevOps-as-a-Service (DaaS) provides clients with access to highly skilled DevOps engineers. We work as an extension of your team to build, maintain, troubleshoot and automate so that you don’t have to.

Services

Technology moves quickly, and often times teams are not able to keep up with what’s new. HighVail helps to bridge gaps through our training and enablement solutions.