قالب وردپرس درنا توس
Home / Tips and Tricks / What is “GitOps” and why is it important? – CloudSavvy IT

What is “GitOps” and why is it important? – CloudSavvy IT



git logo in the background
Shutterstock/postmodern studio

GitOps is an infrastructure approach that leverages and applies software development best practices to IT systems. GitOps builds on the Infrastructure as Code model to create an automated infrastructure model that works together and is versioned like your code.

A modern operations team will routinely set up new services for each deployment. Container instances, databases, and network equipment must be available for deployments to succeed.

GitOps defines the resources to be provisioned as files that exist in a Git repository. This allows everyone on the team to inspect and contribute to the infrastructure. You can use CI pipelines to verify your configuration and eventually push it to your cloud platform.

An infrastructure repository is ultimately very similar to a software repository. You create a branch for each change, update your configuration files, complete an assessment, and merge with your master branch. An automated tool, such as Ansible or Terraform, then applies the changes to your environment. The workflow is the same version branching model developers use.

What is Git?

The Git in GitOps refers to the Git version control system. Git has become the resource management tool of choice for most developers. It has a decentralized storage model and emphasizes using local branches to drive change.

Version control systems make it easy to iterate on your work. You can tackle standalone components in parallel, using branches, before merging them into a master 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

The greatest strength of GitOps lies in its role as a source of truth. Anyone can learn what your infrastructure looks like by referencing the files in your Git repository. You 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 are “declaring” that there must be five servers in your architecture, rather than issuing a list of commands that immediately start five servers. Your provisioning tool converts your instructions into a series of commands that bring your infrastructure into the desired state.

This is where continuous integration (CI) comes in. A software developer runs automated pipelines to perform unit testing, perform static analysis, and finally go into production. A typical infrastructure team pipeline checks your configuration files for syntax errors before sending them to an agent that applies the changes to your systems.

Ability to verify

If you can use CI pipelines to push infrastructure changes, you can verify that those changes are actually working as intended. GitOps also offers continuous verification where agents in your infrastructure constantly check for discrepancies.

The repository is the only source of truth. It follows that any difference observed in the real system is an error that must be corrected. An agent with access to the repository and provisioned resources can take action to correct the current state if it no longer matches your declarations.

GitOps helps you monitor your infrastructure. Declarative configuration files explain how your systems reached their current state. You can inspect the repository’s Git commits to understand how the infrastructure has evolved over time.

GitOps can also provide a way to undo changes to infrastructure. At its simplest, reverting to a previous commit restores an earlier version of your configuration files. However, actually applying them can be a challenge. While code can be rolled back by simply overwriting the current implementation, “reversing” creating – or removing – infrastructure is much less straightforward.

You should evaluate the rollout agent you are using to determine if rollback is a realistic option. If an in-place rollout isn’t possible, you can at least roll back the commits in your repository and redeploy them in a clean slate environment. You would then use your recovery procedures to recover your data.

Challenges with GitOps

Lack of maturity is the biggest obstacle to GitOps adoption. The term remains opaque to operational teams who may be relatively inexperienced with version-driven workflows.

Many infrastructure teams will be accustomed to practices that they have honed over the decades. They SSH to servers, make their changes, and document them in a centrally maintained wiki. It’s unchecked, but it’s simple and it works.

GitOps addresses the lack of control and can improve visibility into the health of systems. At the same time, there is 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 problem when introducing GitOps to a new organization. Be prepared for decision makers to misunderstand where the value lies or not to recognize it at all. Some will get frustrated with having to commit, merge, and request approval for changes that they could accomplish manually using a quick SSH command. GitOps remains where DevOps was a few years ago, waiting for widespread adoption beyond the technical literature.

Aside from organizational pushback, GitOps also has practical shortcomings. A 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 inconvenient if you have a lot of environments. An alternative approach could be based on multiple repositories, perhaps using Git submodules, but this just moves the redundancy elsewhere.

GitOps is still a young concept and there are no fixed patterns for its implementation. Without reference architecture you have to experiment independently. This adds to the list of unknowns for organizations assessing the suitability of the model.

RELATED: Automate continuous delivery in containers with CodeBuild, ECR and CodeDeploy

Resume

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 provision. 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 closes the gap between dev and ops teams by unifying the workflow. You gain more insight into your infrastructure and the ability to implement changes in versions and audits.

Yet in many cases GitOps remains a challenge to implement. It takes organizational buy-in, acceptance of some inherent inefficiencies, and a dedication to solving technical problems that you may not necessarily have foreseen. Organizations going all-in on GitOps can expect stronger consistency and standardization. But for many others, the benefits offered aren’t enough incentive to ditch the CLI commands in a sysadmin’s terminal.


Source link