Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[EN] update GitOps #1334

Closed
wants to merge 7 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 11 additions & 17 deletions content/en/gitops.md
Original file line number Diff line number Diff line change
@@ -1,31 +1,25 @@
---
title: GitOps
status: Feedback Appreciated
status: Completed
category: Concept
tags: ["", "", ""]
tags: ["methodology"]
---

## What it is

GitOps is a set of best practices based on [shared principles](https://opengitops.dev/),
applied to a workflow that depends on software agents that
enable automation to reconcile a declared system state or configuration in a git repository.
These software agents and practices are used to execute a cohesive workflow that
leverages a source control system like Git as the “single source of truth” and
extends this practice to applications, infrastructure, and operational procedures.
GitOps is a set of best practices based on [shared principles](https://github.com/open-gitops/documents/blob/release-v1.0.0/PRINCIPLES.md), applied to a workflow that depends on software agents to continuously and automatically reconcile an actual running system with its desired state declared in an immutably versioned state store like Git.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm afraid this is really hard to understand for non-technical people. What are workflows and agents? The concept of reconciling a system is also new. Combined with the other two terms makes it really challenging for people not familiar with these concepts to understand what we are talking about. That's why I tried to simplify it in the Google doc to something more like this.

Suggested change
GitOps is a set of best practices based on [shared principles](https://github.com/open-gitops/documents/blob/release-v1.0.0/PRINCIPLES.md), applied to a workflow that depends on software agents to continuously and automatically reconcile an actual running system with its desired state declared in an immutably versioned state store like Git.
GitOps is a set of best practices based on [shared principles](https://github.com/open-gitops/documents/blob/release-v1.0.0/PRINCIPLES.md) that ensure the application and system infrastructure always reflect the desired state

Isn't that the essence of what that means but without all these industry terms? Let's keep it really simple and avoid introducing other technical terms if we don't have to.

This was new in the Google doc, but it feels like it really helps understand what we are talking about. Can we add it?

While DevOps focuses on a cultural shift, GitOps is a concrete set of deployment practices that allow adopters to realize the DevOps promise.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still, we need to add that the desired state is reflected in a git repository (hence "git"ops), so perhaps

Suggested change
GitOps is a set of best practices based on [shared principles](https://github.com/open-gitops/documents/blob/release-v1.0.0/PRINCIPLES.md), applied to a workflow that depends on software agents to continuously and automatically reconcile an actual running system with its desired state declared in an immutably versioned state store like Git.
GitOps is a set of best practices based on [shared principles](https://github.com/open-gitops/documents/blob/release-v1.0.0/PRINCIPLES.md) that ensure the application and system infrastructure always reflect their desired state declared beforehand in a single point of truth (usually a Git repository).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fact that the desired state is reflected in a git repo belongs more to the How it help section IMHO

These software agents and practices are used to execute a cohesive workflow and extends this practice to applications, infrastructure, and operational procedures.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does a "cohesive workflow" and "extending it to..." mean? Also, maybe this should go in the "how" section?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 that this belongs more the how section


## Problem it addresses

Existing processes for infrastructure configuration management can face challenges
such as configuration drift, failed deployments, relying on a system's previous state for success,
missing documentation, or unknown development history.
Existing processes for infrastructure configuration management – including scripting and tightly coupled CI/CD – are often error prone and can face challenges such as configuration drift, failed deployments, relying on a system's previous state for success, missing documentation, or unknown development history.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Existing processes for infrastructure configuration management including scripting and tightly coupled CI/CD – are often error prone and can face challenges such as configuration drift, failed deployments, relying on a system's previous state for success, missing documentation, or unknown development history.
Existing processes for infrastructure configuration management including scripting and tightly coupled [CI](https://glossary.cncf.io/continuous-integration/)/[CD](https://glossary.cncf.io/continuous-delivery/) are often error-prone and face many challenges.
They often lead to configuration drift, failed deployments, relying on a system's previous state for success, missing documentation, or unknown development history.

Broke sentence down for better readability. We have an entry for continuous deployment and delivery. Is linking to one better than to another?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please not introduce 'configuration drift ' as a new term.

Suggested change
Existing processes for infrastructure configuration management including scripting and tightly coupled CI/CD – are often error prone and can face challenges such as configuration drift, failed deployments, relying on a system's previous state for success, missing documentation, or unknown development history.
Existing processes for infrastructure configuration management including scripting and tightly coupled [CI](https://glossary.cncf.io/continuous-integration/)/[CD](https://glossary.cncf.io/continuous-delivery/) are often error-prone and face many challenges.
They often lead to failed deployments, relying on a system's previous state for success, missing documentation, or unknown development history.

Event driven CD does not address drift that may happen independently of CI.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this mean?

Giving external automation tools credentials to your production systems widens the attack footprint.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When and why would you give credentials your automation tools? Seems like context is missing here.

Adopting a GitOps workflow can help alleviate these issues, among several others.

## How it helps

GitOps is a paradigm that can be applied to a workflow
to help manage an application and cloud system infrastructure.
It enables organizations several advantages
such as better coordination, transparency, stability, and reliability of a system.
Operating in a close loop ensures the current live state of a system matches
against the desired target state, specified in the git repository.
The GitOps paradigm can be applied to a workflow to help manage applications and cloud system infrastructure.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't answer the question 'How it helps' - it only says it can be applied.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we say methodology instead of paradigm? That way, we keep it simple. Paradigm is a little more abstract and confusing.

What does applying workflows to apps and infrastructure mean? We probably need to define workflow above (or use another term) to use it here. And to @wojtekidd's point, we'd need to add: "...help manage apps and cloud system infrastructure by...[the how it helps is missing]"

It enables organizations several advantages such as better coordination, transparency, stability, and reliability of a system, and faster mean time to recovery.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
It enables organizations several advantages such as better coordination, transparency, stability, and reliability of a system, and faster mean time to recovery.
It gives organizations several advantages such as better coordination of application deployment, transparency, stability, system reliability, and faster mean time to recovery.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Advantages im comparison to what? I think there are many things that create the mentioned advantages. "Simple" CICD does that as well. IMHO the specific advantage of GitOps in comparison to "simple" CICD should be in focus.

Direct access to desired state store and continuous reconciliation allows GitOps agents to ensure the current live state of a system matches the desired target state, regardless of when or how any system failure or drift between the two may occur.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of what is here, is captured in the Google doc but in simpler language. Can repurpose some of this?

Traditionally seen as a single process, GitOps decouples CI/CD (principles 3 and 4). While CI is focused on building applications iteratively, CD focuses on seeing that change in the target system. GitOps concentrates on the CD aspect — both delivery and deployment. That allows developers to focus on CI without worrying about how the change ends up on the target system — they just need to know that it does.
Configuration files, stored as code in a repository (infrastructure as code), generate the same infrastructure environment each time it is deployed, creating consistency. And to ensure what's running on the cluster doesn't diverge from the desired state (codified in Git), software agents continuously monitor the live environment. The agent will attempt to roll back or match the desired state if divergence is detected, avoiding configuration drift.

Using GitOps for CD improves security by separation of duty between CI and CD, where CI no longer needs credentials to your live system.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you meant CD tools?

Suggested change
Using GitOps for CD improves security by separation of duty between CI and CD, where CI no longer needs credentials to your live system.
Using GitOps for CD improves security by separation of duty between CI and CD, where CD tooling no longer needs credentials to your live system.