You’ve probably heard of DevOps, SecOps, maybe even FinOps. But have you heard of GitOps? Especially if you’re trying to do continuous deployment with Kubernetes, I bet you have run across this term. So, is this a new buzzword or something we need to know?
What is GitOps?
If you’re wondering what GitOps is, you’re not alone. The search term has been climbing in popularity since around 2019.
Weaveworks (a vendor with a deployment management service for containers and microservices) is credited with starting the term in 2017. GitOps is their way of managing Kubernetes clusters and application delivery.
First: let’s define terms
If you’re a traditional sysadmin, you may not be familiar with terms that are fundamental to understanding GitOps. Because of this, let’s define some terms.
A free, open-source distributed version control tool that can manage a development project’s source history code. GitHub is a SaaS version of Git that was acquired by Microsoft (very good Git – GitHub comparison here. GitLab is an open core company that provides software for the software development lifecycle.
Infrastructure as Code (IaC)
An IT practice that codifies and manages the underlying IT infrastructure as software (via TechTarget). Perhaps you built jumpstart or kickstart scripts, but IaC is an evolutionary jump. IaC treats the code needed to configure and provision infrastructure the same way developers treat application code.
IaC does more than provision a server. It also installs the right application including the OS and any dependency. Then it sets the networking configuration and anything else required. This is what makes GitOps so developer friendly! With GitOps, developers can just call a database server, it appears, and everything works. We can finally make it simple for them to do the right thing!
Continuous Integration/Continuous Deployment (CI/CD)
The term Continuous Integration (CI) describes a coding philosophy and set of practices that drive development teams to implement small changes and check in code to version control repositories frequently. Equally important, Continuous Deployment (CD) automates the delivery of applications to selected infrastructure environments. (definition via InfoWorld).
Merge Request (MR)
A git command. Specifically, this is how source code changes into a branch [GitLab docs].
This term describes defining an infrastructure’s desired end state., including the required resources and configuration, so an IaC tool to get it built.
Imperatively-defined infrastructure is built by commands run in a specific order. This is how kickstart scripts work. This article does a great job of describing the differences between declarative and imperative IaC.
Something that is done according to the rules [TechTarget]. In other words, the standard state of a thing [Techopedia].
Now that we have a common language, let’s dive into GitOps. As you may have guessed GitOps is related to Git. Here is the GitLab definition of GitOps:
GitOps is an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD tooling, and applies them to infrastructure automation.
GitLab even has a formula for GitOps:
GitOps = IaC + MRs + CI/CD
I really like Bunnyshell’s (a vendor that runs Kubernetes environments as a service) GitOps definition:
GitOps is the practice of using Git pull requests to verify and automatically deploy system infrastructure changes.
Ultimately GitOps is a methodology for automating the process of managing infrastructure as code. Infrastructure must scale as quickly and agilely as the applications they’re built to host.
Now we have a good understanding of the goals of GitOps. But should you adopt this infrastructure management?
Weaveworks created GitOps as an operating model for building cloud native applications. These are their principles for managing Kubernetes clusters [via w6d.io blog]:
Describe the entire system declaratively.
“The entire system” means all the infrastructure required to run an application or a service. Sysadmins have done things like this for a long time: creating a set of servers set aside for dev, test, and production for a specific purpose for a group of engineers. You could have a set of servers specifically for one application, or maybe servers that were your database pool, but databases were configured specifically for one set of engineers.
But do you remember what a pain it was to move from dev to test? Heck lots of times the dev environment was a developer’s laptop. Sometimes moving an application to the test environment would break half of the code. Your goal may have been to build a test environment that mimicked production, but without budget you ended up making due with hand-me-down servers. That meant more unexpected glitches when you went from test to production.
Can you imagine if your entire system was declared, and built in an IaC methodology? What if a developer could issue an MR to move their code from a standard development IaC environment to the test IaC environment? And from there, what if all the testing units could be run on it automatically?
GitOps practitioners say it’s possible now. If was still doing this work, this is something I’d want to learn about ASAP.
The canonical desired system state versioned in Git.
This means the single source of truth for how an infrastructure is to be managed is versioned in Git. Not a spreadsheet. Everyone accepts Git to be the source of truth, so this should cut down on special snowflake machines.
Approved changes that can be automatically applied to the system.
Sysadmins know how quickly infrastructure changes. No matter if you’re working with bare metal or inside a cloud, things change. Things need to be patched. When I was a sysadmin, this meant shutting down and staying overnight or over a weekend if you got a malware alert.
But what if you could spin up a lab consisting of impacted servers, test the malware patch, and then do a MR to push the patch out to your impacted environments? You would have tested the patch on the exact environment by just spinning up servers. The MR would update the canonical desired state in Git, and the environment would be protected against the malware.
Y’all really have it easy these days.
Software agents to ensure correctness and alert on divergence
Much like DevOps, GitOps is a methodology that depends on cultural acceptance. Can your devs (and ops teams) accept not tinkering with config files? If they can’t, then there needs to be a way to detect the drift, and to reconcile the differences.
Is GitOps just a buzzword?
I think GitOps is just one way to solve how operations needs to evolve. I say this is because GitOps is focused on the developer experience. gitops.tech even says:
one of the core ideas of GitOps is letting developers use the tools they are familiar with to operate your infrastructure.
I think those of us who come from traditional operations background understand that developers are never going to have the bandwidth to care for ops like we do. They need their bandwidth to concentrate on making killer apps! But if they can just call the infrastructure they need, and not worry about the time consuming management bits, wouldn’t everyone be a lot happier?
A sysadmin’s expertise is needed to run IaC, even if a methodology like GitOps is implemented. However, it wouldn’t hurt to sharpen our skills by applying them to IaC so infrastructure is embedded into developers’ CI/CD processes.
Additionally, GitOps seems to be a marketing description relevant to Kubernetes clusters only. What about other ways to manage declarative systems? What about bare metal environments?
GitOps is way to make the operational environment of an application part of the CI/CD process. GitOps is for Kubernetes clusters. However, using the information that’s out there about GitOps could be a good way to learn the concepts of IaC management. You’ll need to add in your experience and then focus in on the environments you’re managing.
And maybe blog about what you find, help the rest of us out!