{{announcement.body}}
{{announcement.title}}
Refcard #339

The Essentials of GitOps

GitOps is an operational framework that leverages DevOps core practices used in application development, including version control, CI/CD, and collaboration, for infrastructure automation. This Refcard introduces the fundamentals of a mature GitOps model, the key benefits of GitOps, and the elements of a GitOps workflow for new feature deployment.

Published: Nov. 06, 2020
1,535
Free PDF for easy Reference

Brought to you by

GitLab
refcard cover

Written by

author avatar William Chia Senior Product Marketing Manager, GitLab
asset cover
Refcard #339

The Essentials of GitOps

GitOps is an operational framework that leverages DevOps core practices used in application development, including version control, CI/CD, and collaboration, for infrastructure automation. This Refcard introduces the fundamentals of a mature GitOps model, the key benefits of GitOps, and the elements of a GitOps workflow for new feature deployment.

Published: Nov. 06, 2020
1,535
Free PDF for easy Reference

Written by

author avatar William Chia Senior Product Marketing Manager, GitLab

Brought to you by

GitLab
Table of Contents

The Need for a New Operational Model

Infrastructure Automation for Modern Applications

GitOps Benefits

A Common GitOps Workflow

Conclusion

Section 1

The Need for a New Operational Model

With increasing user demand for always-on applications, available on any device, the complexity and sophistication of software development and delivery amplifies. Traditional, monolithic apps are being decomposed into cloud services that are built and run by a distributed workforce, collaborating from around the globe. Operations teams need a new paradigm to support the upsurge of deployment frequency across multiplying services and in multiple regions, all while reducing risk, increasing uptime, and staying secure. 

GitOps is an operational framework that takes DevOps best practices used for application development, such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation. 

While GitOps practices work well within any software environment, Kubernetes is particularly well suited due to its use of declarative infrastructure definitions kept alongside application code in a Git repository. Keeping your system definition in Git means your engineers can use familiar, Git-based tooling and workflows to manage both application and infrastructure changes. 

With the entire state of your cluster kept under source control, you gain the ability to automate changes for less risk, recreate historical states, review a robust audit log, manage compliance, and more.


This is a preview of the Essentials of GitOps Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 2

Infrastructure Automation for Modern Applications

GitOps practices aren’t dependent on any specific technology. While logically GitOps is simply managing operations by Git, there are three core practices that make up a mature GitOps practice: Infrastructure-as-code (IaC), merge requests (MRs) as the agent of change, and continuous integration/continuous delivery (CI/CD). 

GitOps = IaC + MRs + CI/CD 

Core Practice: Infrastructure-as-Code

Infrastructure-as-Code (IaC) is the practice of keeping all infrastructure configuration stored as code. GitOps uses a Git repository as the single source of truth for the definition of your infrastructure environments. By shifting your environment definitions from manual configuration to configuration by code, you gain access to an array of benefits such as version control, code collaboration, and auditability. You also unlock Git as the user interface for your infrastructure, allowing you to leverage all of the developer tooling, training, and knowledge associated with Git for your infrastructure operations. 

Although IaC is a popular and well-known practice, GitOps isn’t relegated to simply infrastructure. Any operations that can be defined as code (e.g., network, policy, security) are also benefits of GitOps. In some cases, the term “X-as-Code” (XaC) can be used to encompass operations beyond infrastructure. This Refcard will use the more established term “IaC” with the understanding that we are including the entirety of the operational environment, and not simply the infrastructure.

Declarative vs. Imperative Environments

Many modern infrastructure tools such as Kubernetes, Terraform, and AWS Cloud Formation work off of a declarative model. An operations engineer declares the desired state as code, and the system then changes itself to conform to that state via automation. For example, a Kubernetes manifest can declare the number of pods desired for a particular service. The engineer doesn’t need to write an imperative script to bring these pods up or down until the right number is achieved because Kubernetes handles this itself. 

It’s the difference between saying, “I have three servers but want six, so I need to write a script to create three more servers,” and simply telling the system, “There should be six servers. If there comes a point when there are too few or too many, change the state of the environment until we have the correct number.” Using declarative patterns can be very powerful within a GitOps operational model, but they aren’t a strict requirement. You can still benefit from GitOps practices if your environments are imperatively defined. 

Core Practice: Merge Requests as the Agents of Change

It may be surprising to learn that the underlying Git version control system used to power tools such as GitLab, GitHub, and Bitbucket doesn’t include a way to request your branch be merged back into the branch it was created or forked from. This was a later advancement introduced by Git management tools. 

GitLab uses the term merge request (MR), while GitHub and Bitbucket use the term pull request (PR), but functionally, they perform in a similar way. The MR is the central point of developer collaboration for code review and change orchestration. Without a proper version control and branching strategy, collaboration on new changes is a frustrating endeavor. 

When anyone can modify a file without a way to track who made which change, it can be almost impossible to ensure the correct version is being used. A common application development workflow uses a main branch as a centralized collaboration point. Feature branches are created from the main branch, where new work is developed, and then merged back into the main branch via a merge request. Leveraging this best practice for all of your infrastructure code nets you the same benefits that developers enjoy. 

In an infrastructure model, the main branch represents a particular environment (e.g., dev or production), as well as the state running in that environment. Changes are proposed on a feature branch, and an MR is made to merge the changes into the main branch. This MR allows for collaboration between operations engineers for peer review, along with the development teams, security teams, and other stakeholders. This powerful model for collaboration permits anyone to propose a change, while also allowing you to maintain compliance by limiting the number of people who can merge the changes. 

Core Practice: CI/CD Automation

The final component of a robust GitOps strategy is automating all changes made to environments via CI/CD. In an ideal scenario, no manual changes are made to a GitOps-managed environment. Instead, CI/CD serves as a type of reconciliation loop. Each time a change is made, the automation tool compares the state of the environment to the source of truth defined in the Git repository. If the Git repository shows a change, the automation tool reconciles this difference by configuring the environment to match the canonical desired state. 

This type of automation serves as a powerful protection against configuration drift. There are many reasons configurations can fall out of sync. Whether due to a component failure or inadvertent manual change, each time the automation runs, it overwrites the existing state with Git source of truth. 

Agent vs. Agentless GitOps

A couple of different models for GitOps automation have emerged, namely Agent-based and Agentless, each with their own pros and cons. Agentless GitOps is a traditional model, also known as push-based GitOps, in which your CI/CD tool reads from your Git repository and pushes changes into your environment. 

  • Pro – It’s simpler and more flexible as it can be used with any type of infrastructure, from physical servers and VMs to Kubernetes clusters. 
  • Con – You must give your CI/CD tool access to make writes to your environment. Requiring your environment to be open to writes from the external internet can cause security and compliance issues.

Figure 1: Agentless GitOps model


This is a preview of the Essentials of GitOps Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 3

GitOps Benefits

GitOps best practices are far-reaching and can provide the following benefits. 

Tighter Collaboration

Using the merge requests as a central point of collaboration enables teams across the organization to work together in a fast, automated, and asynchronous way. Best practices from one team can be easily shared and consumed across the organization because they are documented as code. 

Increased Deployment Frequency

With automated application deployment and environment provisioning, you can do many small, frequent deployments rather than occasional large, risk-prone deployments. Smaller changes are easier to reason about when troubleshooting and easier to roll back. Additionally, deploying features to your users sooner leads to happier users, more actionable feedback, and ultimately improved software. 

Reduced Mean Time to Recovery

A core benefit of keeping environment state in version control is that rolling back to the last known good configuration when you experience problems is straightforward. This can dramatically reduce your mean time to recovery (MTTR) because you can fix issues quickly during an incident by rolling back, and then after your system is operating normally, you can troubleshoot.


This is a preview of the Essentials of GitOps Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 4

A Common GitOps Workflow

The power of GitOps is that the same workflows used to add features to a service or application can be used to configure and provision the environments where the software runs. This shared understanding of workflows and tooling across the organization drives many of the benefits that GitOps brings. 

Workflow for Deploying a New Feature

  1. A ticket is logged in the product issue tracker for the new feature. 
  2. A corresponding ticket is logged in the platform operations issue tracker to provision the infrastructure needed to support the new feature. 
  3. A branch is created in each respective repository to work on the feature and infrastructure changes. 
  4. Code is committed to each branch. 
  5. A merge request is created for each branch to perform code review and testing. 
  6. The CI/CD merge request pipeline runs automated tests and checks against the branch. Sophisticated tooling will display the results within the MR to aid collaboration and troubleshooting. 
  7. The MR serves as the central point of collaboration for peers and stakeholders. Reviewers comment on the general approach, as well as on specific lines of code. 
  8. The code is iterated on until it meets the standards to be merged. This typically means all automated checks have passed, all comments are resolved, and any needed approvals have been added. 
  9. The Git merge to the main branch triggers the CI/CD deployment pipeline, where an additional set of automated tests can be run. 
  10. The infrastructure pipeline configures and provisions the environment, while the product pipeline deploys the application code.

This is a preview of the Essentials of GitOps Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 5

Conclusion

GitOps is an operational model that leverages DevOps best practices used in application development for infrastructure automation. Using Infrastructure-as-Code, the environment definition is stored in a Git repository as the single source of truth. The merge request workflow is used for collaboration and compliance, while CI/CD automation not only deploys the application code, but also configures and provisions the underlying environments in which the code runs. 

Adopting GitOps best practices means that developers and operations engineers can use familiar Git tooling to manage updates to software environments. Automation, along with asynchronous collaboration at scale, speeds up the pace of innovation to decrease lead times and increase deployment frequency. This increased agility allows business to respond to customer and market demands to build and maintain a competitive advantage.

Whether teams are working side by side in the same office or distributed around the world, GitOps increases collaboration between development, operations, security, and all business stakeholders.


This is a preview of the Essentials of GitOps Refcard. To read the entire Refcard, please download the PDF from the link above.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}