documents VS kustomize

It's not about terraform handling it or not, it's about ensuring that drift is automatically corrected without a CI trigger. One of the core principles of GitOps is continuous reconciliation. This requires a reconciliation loop, e.g. some task that runs automatically and without user intervention. As far as I can tell from their docs Digger only runs its steps on a pull request, similar to Atlantis (but "without the backend"). This is continuous delivery, but it's not continuous reconciliation, and therefore not GitOps. GitOps would be something like combining Flux or ArgoCD with Crossplane.

think i'm going to take the feedback from this discussion to the opengitops working group tomorrow, hoping we can maybe get it defined in their vendor agnostic gitops glossary https://github.com/open-gitops/documents/blob/main/GLOSSARY.md haha, which i'm sure chatgpt will figure out about like 12 seconds later, consider correct, and then just wire the architecture together for us. but we can just start with kubefirst while chatgpt is trying to catch up haha.

The GitOps term was coined back in 2017 by Weaveworks, and paraphrasing OpenGitOps, a GitOps system is based on the following principles:

That's why there's systems for continuous reconciliation. I'ts one of the four fundamental principles of GitOps.

https://opengitops.dev/ https://github.com/open-gitops/documents

(Here is a link: https://github.com/open-gitops/documents/pull/51)

In 2021, the first OpenGitOps Standard v1 was created, to make sure we all GitOps enthusiasts speak the same language. For more information go to opengitops.dev.

The working group has been hard at work, over many meetings, github discussions, revisions, blood, sweat, and tears we've just merged the pre-release GitOps Principles and glossary. Check them out here and be sure to make issues/comments. It'd be great to hear everyone's thoughts.

kustomize: brew install kustomize

It's a built in feature of kustomize https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/helmchartargs.go

I think the combination of Kustomize and helm works in my experience. For advanced use cases, you can also see KRM functions in Kustomize.

See for instance a related issue: https://github.com/kubernetes-sigs/kustomize/issues/3866

Using a strategic merge is the safest way so you avoid the index fragility.

Rendering out the manifests is something I have been pushing for. Not having to understand how every templating tool works and what actually is being changed is key. Though, it gets complicated when you use helm (or any templating/patching tool) that produces many variants. You also lose any release/deployment time hooks that are provided (helm hooks or recently "patched" kustomize env variables).

https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md (edit: oh I see the other commenter also included this link, oops)

Kustomize is an open-source project that “lets you customize raw, template-free YAML files for multiple purposes, leaving the original YAML untouched and usable as is.” It’s now the most popular tool for customizing Kubernetes manifests reasonably, and it’s even built directly into the Kubernetes CLI since K8s v1.14.