A modern operations team will routinely spin up new services for each deploy. Container instances, databases, and networking equipment need to be available for deployments to succeed.
GitOps defines the resources to provision as files that exist in a Git repository. This lets everyone on the team inspect and contribute to the infrastructure that will be provisioned. You can use CI pipelines to verify your configuration and ultimately push it out to your cloud platform.
An infrastructure repository ends up looking very much like a software repository. You create a branch for each change, update your configuration files, complete a review, and merge into your main branch. An automated tool, such as Ansible or Terraform, then applies the changes to your environment. The workflow is the same versioned branching model that developers use.
What Is Git?
The Git in GitOps refers to the Git version control system. Git has become the source control tool of choice for most developers. It has a decentralized storage model and emphasizes the use of local branches to evolve changes.
Version control systems make it easy to iterate on your work. You can tackle self-contained components in parallel, using branches, before merging into a main branch that represents the “released” version of your project. You push your code to a shared repository, often on a service like GitHub or GitLab, to share it with others.
Declarative Infrastructure
GitOps’ biggest strength lies in its role as the source of truth. Anyone can learn what your infrastructure looks like by referring to the files in your Git repository. You’ll have a set of configuration files that define the characteristics of your system.
Configuration files are usually declarative in nature—they describe the system in the present tense. You “declare” that there should be five servers in your architecture, instead of providing a list of commands that directly start five servers. Your provisioning tool converts your statements into a sequence of commands that move your infrastructure toward the desired state.
This is where continuous integration (CI) comes in. A software developer will run automated pipelines to execute unit tests, perform static analysis, and eventually, deploy to production. A typical infrastructure team pipeline will check your config files for syntax errors before pushing them to an agent that applies the changes to your systems.
Ability to Verify
Being able to use CI pipelines to enact infrastructure changes lets you verify that those changes will actually work as intended. GitOps also provides the ability of ongoing verification where agents in your infrastructure constantly monitor for discrepancies.
The repository is the single source of truth. It follows that any difference observed in the real system is an error that should be corrected. An agent with access to the repository and the provisioned resources can take action to correct the current state if it no longer matches your declarations.
GitOps aids you in observing your infrastructure. Declarative configuration files provide an explanation of how your systems entered their current state. You can inspect the repository’s Git commits to understand how the infrastructure evolved over time.
GitOps can also offer a way to rollback infrastructure changes. At its simplest, reverting to a previous commit restores a previous version of your configuration files. Actually applying them can be challenging, though. Whereas code can be reverted by simply overwriting the current deployment, “reversing” the creation—or deletion—of infrastructure is much less straightforward.
You’ll need to evaluate the rollout agent that you’re using to determine whether rollbacks are a realistic possibility. If an in-place rollout isn’t possible, you can at least revert the commits in your repository and re-deploy them into a clean slate environment. You’d then use your restoration procedures to reinstate your data.
Challenges with GitOps
Lack of maturity is the biggest obstacle to GitOps adoption. The term remains opaque to operations teams that could be relatively inexperienced with version-controlled workflows.
Many infrastructure teams will be used to working practices they’ve honed over the past couple of decades. They SSH into servers, make their changes, and document them in a centrally maintained wiki. It’s uncontrolled, but it’s simple, and it works.
GitOps addresses the lack of control and can improve visbility into the state of systems. At the same time, there’s a learning curve that involves a structured workflow and a very different set of tools. Direct SSH access is no longer appropriate. Instead, you make changes by editing files and waiting for a CI pipeline to apply them.
Getting buy-in from relevant teams can be the biggest issue when introducing GitOps to a new organization. Be prepared for decision-makers to misunderstand where the value lies or fail to recognize it altogether. Some will be frustrated by having to commit, merge, and seek approval for changes that they could achieve manually by using a quick SSH command. GitOps remains where DevOps was a few years ago, waiting to see widespread adoption outside of technical literature.
Aside from organizational pushback, GitOps has practical weaknesses, too. One common challenge is rolling out to multiple different environments. A common approach is to assign each environment its own branch in the repository. This quickly becomes clunky if you have a lot of environments. An alternative approach could be based around multiple repositories, perhaps using Git submodules, but this just moves the redundancy elsewhere.
GitOps is still a young concept, and there aren’t established patterns for its implementation. Without a reference architecture, you’ll need to experiment independently. This adds further to the list of unknowns for organizations assessing the model’s suitability.
RELATED: Automating Continuous Delivery in Containers with CodeBuild, ECR, and CodeDeploy
Summary
GitOps is an approach to managing IT infrastructure that uses a Git repository as the source of truth. You write declarative configuration files that describe the resources that you want to be provisioned. An automated system takes those files and uses them to evolve the state of your infrastructure.
As a concept, GitOps makes a lot of sense. It reduces the gap between dev and ops teams by unifying the workflow. You get greater visibility into your infrastructure and the ability to version and audit changes.
Yet GitOps remains challenging to implement in many cases. It requires organizational buy-in, acceptance of some inherent inefficiencies, and a commitment to resolve technical issues that you might not necessarily foresee. Organizations that go all-in on GitOps can expect to see stronger consistency and standardization. But for many others, the benefits provided aren’t yet a sufficient incentive to throw away the CLI commands in a sysadmin’s terminal.
