Understanding GitOps
So if you are relatively new to DevOps and the technology known as Gitlab/Github, then you probably have heard of Git and the practice of GitOps. But do you really know what it all entails? In this series: Let’s Get Technical, we’ll dive into common DevOps tools & capabilities and really learn what they are all about and in turn, how to leverage them properly in a DevOps role (or any IT role for that matter!). So let’s get to it…
What Exactly is GitOps
So what is GitOps? GitOps is a term, coined by the company, Weave Works. GitOps is a set of practices that manages infrastructure and application configurations using the Git application, an open source Version Control System (VCS). GitOps works by using Git as the “source of truth” for declarative programming languages. GitOps uses Git pull requests to automatically manage infrastructure provisioning and deployments and the Git repository contains the entire state of the system so that the trail of changes to the system state are visible and auditable. GitOps is built around the developer experience and it helps teams manage Infrastructure as Code (IaC) using the same tools and processes that they use for developing software.
To get started with a GitOps managed infrastructure, it needs to be able to be managed by a declarative programming language. Now because of this, GitOps is often used as an operating model for Microservice architectures like Kubernetes, but using Kubernetes is not a requirement of GitOps. GitOps is a technique that can be applied to many other IaC and deployment pipelines.
The GitOps Workflow
Just like Kubernetes, Ansible is also a declarative state programming language that enables declarative modeling of traditional IT systems and can be used for GitOps. An Ansible user can manage applications on Kubernetes, on an existing IT infrastructure, or across both through one control plane using additional Ansible capabilities known as modules, reusable & standalone scripts that can be used by the Ansible API, or by the ansible-playbook application. They return information to ansible by printing a JSON string to stdout (screen, log file, etc…) before exiting.
GitOps is considered IaC in that uses Git as the version control system for the infrastructure configurations. IaC often follows the declarative programming language approach to infrastructure management by defining the desired state of the system and tracking the system’s actual state. With IaC, GitOps requires you to declaratively describe the desired state and by using declarative tools, all of the configuration files and source code can be version controlled in a Gitlab/Github project repository.
Now another critical component of a GitOps workflow is the idea of Continuous Integration/Continuous Delivery (CI/CD), which are generally software triggers made by an external event, like new code being pushed from development to a Git repository. In a GitOps workflow, changes are made using pull requests which modify the state in the Git repository. To roll out a new version of code using GitOps, a pull request is made in Git, which makes a change to the declared state. The GitOps operator, is triggered by the Git commit and pulls in the new state declaration from Git. Once the changes are approved and merged, they will then be applied automatically to the production system. Developers can then continue to use their CI/CD workflow until the end of the project.
Are GitOps and DevOps the Same Thing?
Not really, GitOps and DevOps share some of the same principles and goals but DevOps is focused towards a cultural change to provide a way for Dev and Ops teams to work more collaboratively together. GitOps on the other hand, provides you the tools and a framework to leverage DevOps practices (Collaboration, CI/CD & VCS), and apply them to IaC automation & deployments. Developers work on the code inside of the Git repos, and at the same time, the Ops team can put the other pieces into place.
So How Does it All Work?
GitOps relies on Three primary components: IaC, Merge Requests (MR) and CI/CD
Infrastructure as Code (IaC)
GitOps uses the Git repo as a “source of truth” for code. Git tracks code management changes, and the Git repository is a .git folder in a project that tracks all changes made to files in a project over time. IaC is the practice of keeping the infrastructure configuration stored as code.
Merge Requests (MR)
GitOps uses MRs as the change mechanism for all infrastructure updates. The MR is where teams can collaborate through peer reviews and comments and where formal approvals can take place. A merge commits to your dev or master branch and serves as an audit log for all code changes.
Continuous Integration/Continuous Delivery (CI/CD)
GitOps automates infrastructure updates using a Git CI/CD workflow. When new code is merged, the CI/CD pipeline enacts the change in the environment. If there is any configuration drift (Manual changes or Errors), they are overwritten by the GitOps automation so the environment converges on the desired state defined in Git. Git uses CI/CD pipelines to manage and implement GitOps automation.
