[EN] update GitOps #1334
[EN] update GitOps #1334
Conversation
Co-authored-by: Christian Hernandez <christian@chernand.io> Signed-off-by: Scott Rigby <scott@r6by.com>
- Clarify this is not another what it is, but a statement about the paradigm. - Pluralize applications Co-authored-by: Christian Hernandez <christian@chernand.io> Signed-off-by: Scott Rigby <scott@r6by.com>
- Note faster mean time to recovery - Differentiate GitOps from traditional CI/CD - Note value of a closed loop - Note security benefits Co-authored-by: Christian Hernandez <christian@chernand.io> Signed-off-by: Scott Rigby <scott@r6by.com>
Signed-off-by: Scott Rigby <scott@r6by.com>
scottrigby
requested review from
caniszczyk,
CathPag,
JasonMorgan,
seokho-son,
iamNoah1 and
jihoon-seo
as code owners
✅ Deploy Preview for cncfglossary ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
Signed-off-by: Scott Rigby <scott@r6by.com>
Signed-off-by: Scott Rigby <scott@r6by.com>
jihoon-seo
added
lang/en
|
I really like how this came out. I don't know if the glossary is the perfect place for my idea but what if we add some |
Signed-off-by: Catherine Paganini <74001907+CathPag@users.noreply.github.com>
There was a problem hiding this comment.
Thanks, @scottrigby. I'm afraid this still requires a lot of previous knowledge. There are lots of industry terms that make it hard to grasp for non-technical people. Can we try to simplify? I tried suggestions where I could, but don't really know enough about most other sections.
I know it's hard, especially when you are really deep in the weeds. You don't really know how little other people not in the field know.
Didn't get to the last section yet.
| 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. |
There was a problem hiding this comment.
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.
| 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.
There was a problem hiding this comment.
Still, we need to add that the desired state is reflected in a git repository (hence "git"ops), so perhaps
| 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). |
There was a problem hiding this comment.
The fact that the desired state is reflected in a git repo belongs more to the How it help section IMHO
| 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. | ||
| These software agents and practices are used to execute a cohesive workflow and extends this practice to applications, infrastructure, and operational procedures. |
There was a problem hiding this comment.
What does a "cohesive workflow" and "extending it to..." mean? Also, maybe this should go in the "how" section?
There was a problem hiding this comment.
+1 that this belongs more the how section
| 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. |
There was a problem hiding this comment.
| 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?
There was a problem hiding this comment.
Please not introduce 'configuration drift ' as a new term.
| 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. |
| 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. | ||
| Event driven CD does not address drift that may happen independently of CI. |
| 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. | ||
| Event driven CD does not address drift that may happen independently of CI. | ||
| Giving external automation tools credentials to your production systems widens the attack footprint. |
There was a problem hiding this comment.
When and why would you give credentials your automation tools? Seems like context is missing here.
| 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. |
There was a problem hiding this comment.
This doesn't answer the question 'How it helps' - it only says it can be applied.
There was a problem hiding this comment.
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]"
| 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. | ||
| It enables organizations several advantages such as better coordination, transparency, stability, and reliability of a system, and faster mean time to recovery. |
There was a problem hiding this comment.
| 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. |
| The GitOps paradigm can be applied to a workflow to help manage applications and cloud system infrastructure. | ||
| It enables organizations several advantages such as better coordination, transparency, stability, and reliability of a system, and faster mean time to recovery. | ||
| 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. | ||
| Using GitOps for CD improves security by separation of duty between CI and CD, where CI no longer needs credentials to your live system. |
There was a problem hiding this comment.
I think you meant CD tools?
| 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. |
| 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. |
There was a problem hiding this comment.
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]"
| 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. | ||
| It enables organizations several advantages such as better coordination, transparency, stability, and reliability of a system, and faster mean time to recovery. | ||
| 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. |
There was a problem hiding this comment.
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.
| 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. |
There was a problem hiding this comment.
The fact that the desired state is reflected in a git repo belongs more to the How it help section IMHO
| 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. | ||
| These software agents and practices are used to execute a cohesive workflow and extends this practice to applications, infrastructure, and operational procedures. |
There was a problem hiding this comment.
+1 that this belongs more the how section
| 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. | ||
| It enables organizations several advantages such as better coordination, transparency, stability, and reliability of a system, and faster mean time to recovery. |
There was a problem hiding this comment.
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.
|
friendly reminder @scottrigby |
|
Closing as stale and in favour of #2121. Thanks for your effort everyone, I hope some of these changes may get reflected in the other PR. |
Describe your changes
Updates to the GitOps entry in CNCF Glossary.
This draws from a work-in-progress Google doc co-edited by @CathPag, @hseligson1, @christianh814, and me.
Christian and I only realized today that there was already an existing entry for GitOps, just not linked in the sidebar.
In the spirit of keeping this a minimum viable definition – as Catherine suggested – Christian and I added smallest changes to this file as possible for helping readers understand what GitOps is, the problems it solves and how.
PTAL and see if you think this is still too technical or if it's more clear now. We can link to additional definitions if that would help. For example, there is no glossary entry for "reconciliation", a pretty important concept for k8s and many adjacent cloud-native applications.
@CathPag Also, after looking through the code a bit, it's not clear to us how to add an entry to the sidebar menu. We'd like to do that as part of this PR unless it's governed by some other system?Never mind, looks like this is connected tostatus. Moved toCompletedin this PR.Related issue number or link (ex:
resolves #issue-number)resolves #372
Checklist before opening this PR (put
xin the checkboxes)git commit -s) is to affirm that commits comply DCO.