GitOps is arguably one of the biggest buzzwords in 2022 thus far, yet there’s a good reason for it - because it actually works.

One question that’s probably Googled the most for GitOps is; is it just for Kubernetes? The answer is sort of yes, but also sort of no.

In this blog post, I answer the question around what GitOps is actually used for and why it’s important for not just Kubernetes, but configurations as a whole.

What is GitOps?

Way back in the early days (which in tech is about 3 minutes ago), Configuration Management was huge. A lot of organizations were, and still are, focusing on Configuration Management. If you have a server that needs some application installed or a piece of the software running on it, Configuration Management is a pretty good way to go. It makes your life as an engineer easier because of automation and repeatable processes.

In large organizations that have been around for a while, Configuration Management is still very much in-demand and isn’t going away. However, in smaller organizations, Configuration Management isn’t used as much. The reason why is because of different technologies being brought in which include:

• Serverless
• Containers
• Kubernetes

As a smaller organization or a startup, it’s much easier to go with the “latest and greatest” because you have no tech debt that needs to be cleaned up.

However, with the “latest and greatest” comes new challenges, for example, how does the organization know what’s the “right” configuration or the configuration that should stay as is? Essentially, the source of truth they have (source control) may or may not be what’s out in the wild.

With GitOps, that changes.

GitOps looks at your source control repository, like GitHub, and scans it to confirm that what’s out in production, or even in a development environment, is the version of the software that’s supposed to be deployed. If something is manually changed in that environment, GitOps says hold on a second, this doesn’t look right! Let’s get the right configuration to that environment via what’s in source control.

How It’s Used in Kubernetes

Now that you know what GitOps is and why an organization may want to utilize it, let’s talk about how it’s used today.

Say you have an application that’s running in a container and is orchestrated with Kubernetes. To keep things simple, say it’s a frontend app running in Nginx. For Nginx to run properly, you have an nginx.conf file that has all of the website and frontend configurations, and it can also include load balancing configurations.

What if someone went into the nginx.conf file to try to troubleshoot a frontend issue and they accidentally changed the load balancing configuration? That would be an issue if, say, user load started ramping up on your website and the single Nginx Kubernetes deployment started to get bogged down.

If the nginx.conf file is in source control, like GitHub, GitOps will look at it and say wait a minute.. the configuration in production for this nginx.conf file and what’s in source control doesn’t match up. Let’s re-deploy the nginx.conf file.

The idea of GitOps is that it’s your communicator between a Kubernetes environment and wherever you’re storing code, like in GitHub.

How It’s Used Elsewhere

The truth is; you’ll most likely use some sort of Kubernetes cluster available for GitOps. Whether that cluster is on-prem, in the cloud, or some type of “serverless” Kubernetes service, like Google Kubernetes Engine (GKE) AutoPilot. However, GitOps isn’t just managing the Kubernetes cluster. It’s managing a lot more from a declarative perspective:

• Applications
• Interfaces
• Each environment
• Data
• Monitoring

Realistically, whatever is in source control, GitOps would manage. The ultimate goal with GitOps is that the entire system is managed declaratively, not just the apps.

GitOps is pretty much a cleaner version of Configuration Management.