Any Helm chart designed to deploy the Kargo CRDs dynamically per-application?

[pww217]

(Saw a few discussions tangental to this but not directly about it, although this one is pretty close)

I just set up Kargo using the QuickStart example on my local machine and am very impressed. I am hoping it can help us deal with the spaghetti code we often have in GHA to bridge the gap between the CI and ArgoCD like promotions, integration testing, and more. Familiar enough use case to all here, I'm sure.

I am however having a lot of trouble figuring out how to apply Kargo to existing applications, as all examples so far basically just put a series of direct manifests and apply them, like so. as well as the QuickStart example. Notably, the linked example is likely the mechanism we'll be using (Helm + Git Repos + ECR) and I thank @krancour for the very helpful examples.

But because we have many apps and product - and I don't want to copy-paste these manifests a dozen times - I need something more scalable, and this is exactly what Helm is designed for after all right? We can template out the Warehouse, Project, and Stage resources can we not?

So the actual question is: Does such a helm chart exist to template out the CRDs per application, or what kind of pattern are y'all using in reality to reduce the toil there? Is there a solution anyone is willing to share?

The pattern I see in examples is to have all these CRDs living in a namespace on the cluster and then applying/gluing them to existing ArgoCD apps. That model should work well for me, but I am looking for a way to do it with a file of a few dozen or hundreds of lines, not thousands and thousands of lines of CRD manifests.

Please do let me know if I've got anything very wrong here. Kargo is pretty new to me but it seems very promising and I just want to understand how to scale it beyond these examples.

[krancour]

Hi @pww217 there has been discussion of eventually introducing high-level constructs like "StageSets" to manage many similar Stages. You could think of this as being similar to the way that Argo CD ApplicationSets can mangage many similar Applications.

But you are also correct to that Helm is an ideal tool for templating out your own patterns, which you probably don't need to repeat only from Stage to Stage within a Project, but probably will want to also repeat across many Projects as well.

We do know of several users who are doing exactly that, so you are on the right track with this idea.

[pww217]

Perfect, thank you. It seems any such charts are not being offered publicly, just the baseline control-plane chart (which is quite good).

I'll probably try to think of a way to do this that can be pretty easily-readable and developer-friendly and if it works well, I may open it up as a public repo for those with similar use-cases. I imagine others will do something similar if they have, like us, a spoke-and-hub ArgoCD/multi-cluster model.

[krancour]

@pww217 as I think about this more, I am less certain that I fully understood your question or the chart you are proposing to create...

Are you trying to make it easier to manage many Projects with similar pipeline composition and promotion workflows?

Or are you looking for a chart that manages Kargo controllers that aren't part of Kargo's control plane?

[pww217]

Are you trying to make it easier to manage many Projects with similar pipeline composition and promotion workflows?

I think it's this one. We have many products/apps and most run along very similar pipelines, and almost all are ArgoCD managed. They run across a few clusters. The CI/CD has up until now been done by some real spaghetti-code Github Actions and that's what I'm looking to replace with something clean, standardized (that's a big one), and easy to use like Kargo.

I want to replace everything GHA does except build/push images. So that's promotions, rollbacks, automated testing, canary rollouts, and more.

So I'm talking about a chart that would probably be structured somewhat like:

templates/
  stages.yaml
  warehouses.yaml
  analysistemplate.yaml
Chart.yaml
values.yaml

Maybe there'd be a project.yaml template too - still trying to figure out how to sort these into "buckets" in a way that both we platform engineers and our developers can understand.

The idea being that I can then deploy this chart with a short values file - probably < 20 lines for a very simple app, instead of > 100 lines of manifest for the same simple app. That values file can probably live in the app/developer's repo for them to manage, just like their app Helm values/configuration.

The name of the game here for me is scalability. So far instance, realizing that it seems each Kargo Project may require its own namespace is not ideal. It livable but we have a lot of applications and didn't necessarily want 100 namespaces in our control cluster.

Seemingly related to the above is that it seems like the Kargo CR's should be in the same namespace as the Application, at least in the quickstarts and examples this is the case. Trying to figure out if that's a requirement, but at the moment I'm getting an error related to a mutating webhook when trying to sync an app that's in another namespace.

I imagine this is for least-privileges and security reasons, but since those apps/namespaces live in other clusters I'm not too sure how to make this work. Anyway sorry, a bit off topic. Just trying to give you some idea of where I am with all this.

[pww217]

But I wouldn't think it would have to be the same namespace, since ultimately what Kargo is trying to do is to alter the ArgoCD Application resource, which is on the same control cluster living in the argocd namespace, which makes this most recent promotion error all the more confusing:

Promotion Errored
error executing Argo CD promotion mechanism: Argo CD Application "some-app-us-east-1" in namespace "argocd" does not permit mutation by Kargo Stage dev in namespace kargo-some-app-admin

I figure there must be some issue with serviceAccount, roleBinding or similar. Anyway, I am trying to write down what I learn in this process and diagram it out a little. If it's useful I may contribute those upstream too at some point as the docs could definitely use some fleshing out.

Edit: Oh I think perhaps I'm just missing a required annotation, looking back at the Quickstart

      annotations:
        kargo.akuity.io/authorized-stage: kargo-demo:{{stage}}

So I'll try that out.

Edit2: And that fixed it! First time I've had Kargo work in a production-like env! Very exciting stuff.