What is GitOps?
GitOps takes DevOps best practices that are used for
development like version control, collaboration, compliance,
and CI/CD tooling, and applies them to automate
infrastructure. Since the software development lifecycle has
been automated and infrastructure still requires manual
processes, infrastructure management requires specialized
teams, which is not feasible for any organization. This is the reason that rising infrastructure demand needs
infrastructure automation. Modern infrastructure needs to be
elastic so that it can effectively manage cloud resources that
are needed for continuous deployments.
Modern applications are developed with speed and scale in
mind where automation plays a crucial role, but there is the
absence of automation in infrastructure management.
That’s why GitOps comes into the picture.
GitOps automates the infrastructure provisioning process.
Like those teams that use application source code, operations
teams that adopt GitOps use configuration files stored as code
(infrastructure as code). GitOps configuration files generate
the same infrastructure environment every time it’s
deployed, just as application source code generates the same
application binaries every time it’s built.
How Does GitOps Work?
GitOps combines Git and operations, or resource management.
Git is an open-source version control system that tracks code
management changes. Like DevOps, GitOps aims to use CI/CD to
automatically deploy your resources by using code stored in
your Git repositories. With GitOps, your infrastructure
definition code, defined as JSON or YAML and stored in a .git
folder in a project, lives in a Git repository that serves as
a single source of truth.
While using Git’s features, an organization can see the
complete change history for the infrastructure code, and once
needed, teams can roll back to an earlier version. Git ensures
that bad infrastructure is not used in infrastructure
management, as bad infrastructure code can accidentally prove
expensive cloud infrastructure and cost the company thousands
of dollars per hour.
Even worse, a bad script could also take down your
application, resulting in downtime for your services. Using
Git, many people can review the code and prevent these
mistakes
Benefits of GitOps:
-
Collaboration on Infrastructure Changes: Every change, either merge request, review, or approval,
goes through the same process. Hence, senior engineers can
focus on other areas rather than critical infrastructure
management.
-
Less Risk:
All changes can be rolled back to a previous state, as
changes to infrastructure are tracked through merge
requests.
-
Faster Time to Market: Manual monitoring and correction are time-consuming. While
execution via code is faster, as test cases are automated
and repeatable. Thus, stable environments can be delivered
rapidly.
-
Simplified Auditing: Auditing across a set of multiple interfaces can be
complex if done manually because data is pulled from
multiple places and normalized in order to conduct the
audit. But GitOps stores all changes to environments in the
git log and makes auditing easy.
-
Reduced Costs and Downtime:
Once you automate infrastructure and remove manual testing
from the practice, productivity increases and downtime
reduces due to built-in revert/rollback capability. Also,
automation teams manage cloud resources better, which
improves cloud costs.
-
Less Error-Prone:
Infrastructure definition is codified and the process
becomes repeatable, which makes it less prone to human
error. With code reviews and collaboration in merge
requests, errors can be identified and corrected before they
ever make it to production.
GitOps Best Practices:
GitOps seems quite promising but you would not want to take it
as an experiment. But that doesn’t mean that you
don’t use it at all. Here are some of the best practices
that you can implement in your GitOps strategy.
-
Define All Infrastructure as Config Files: Ensure all the
infrastructure you want to manage via GitOps is described in
IaaC config files. To do that, files should be written in
declarative code. The biggest advantage of doing this is: you
describe the end state - what you want rather than
instructions of how to get there. For example, use a JSON file
with properties describing how you want to set up your
services, rather than a JavaScript file where you instruct a
provider to create services for you. For the best
results, describe all of your infrastructures, as the omission
of even one service, however it takes only a minute or two,
can sabotage your GitOps strategy.
-
Document What You Can’t Automate: Some tasks can be
automated and require manual efforts. In such a case, always
document the instances, as it will save a lot of time. Plus, a
documented process can be followed by anyone in the team. It
reduces dependency and helps you maintain agility.
-
Consider Multiple Environments: It’s good practice to
have multiple environments. One example you might follow is
the DTAP environments: Development, Test, Acceptance, and
Production. Code can be rolled out to the Development or Test
environment, after which you can test whether the services are
still available and working as expected. If they are, you can
further roll out your changes to the next environments. After
you have rolled out your code into your environments,
it’s important to keep your code in sync with your
running services. Once you know there’s a difference
between your system and your configuration, you can fix either
one. A solution to this problem is to use immutable images,
such as containers so that it’s less likely to have
differences.
-
Make CI/CD the Access Point to Resources: One practice that
encourages a GitOps workflow, and reduces manual changes to
cloud infrastructure, is to make your CI/CD tooling the access
point for cloud resources. Having this access during initial
development can really help teams write their code.
Conclusion
Before the introduction of cloud computing, setting up
servers was a tedious task. However, it changed when
organizations began to shift to cloud computing, yet something
was missing. Setting up servers or VMs on particular cloud
platforms was easy, as they introduced declarative code to
provision the entire architecture. For example, AWS used
Amazon CloudFormation and for Azure, it was Azure Resource
Manager. Now the problem with using these resources is that
you can’t use them to set up your servers and VMs on
multiple cloud platforms.
GitOps seems to end this problem and the dependency on a
specific cloud vendor. Using GitOps, you can set up your cloud
resources on multiple clouds without writing different
codes.
