Kargo, a multi-stage application lifecycle orchestrator

I&#x27;ve used Flux, Flux2 and Argo for GitOps, and they all had their quirks. In general it seems that most CloudNative projects were kinda set in their own vision with very opinionated devs and a lot of corner cases that are not accounted for and won&#x27;t be accounted for.<p>I have a little bit of hope that this one is going to be different with the lessons they got from Argo, but I&#x27;m not holding my breath.<p>Ps. when I first saw Argo, I thought this is it. The solution to all my problems.

I&#x27;ve only skimmed the quickstart docs <a href="https:&#x2F;&#x2F;kargo.akuity.io&#x2F;quickstart&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;kargo.akuity.io&#x2F;quickstart&#x2F;</a> but this snippet immediately clicks for me as something that I&#x27;d want to try<p><pre><code> cat &lt;&lt;EOF | kubectl apply -f - apiVersion: kargo.akuity.io&#x2F;v1alpha1 kind: Promotion metadata: name: prod-to-${FREIGHT_ID} namespace: kargo-demo spec: stage: prod freight: ${FREIGHT_ID} EOF </code></pre> Have enjoyed using argo in general in the past, its got a great model for k8s native workflows &#x2F; events but never got to using it for CD.

I can almost follow this but I am at the edge of where I see how it could sound like buzzword gibberish.<p>I dont blame the author(s) but things are getting more specialized and more terms are created. (which usually maps to an existing term which also maps to an existed term which also maps an existing term and so on.<p>I have though about trying to create a &quot;terminator&quot;(hah) where you can paste in something from a new product and it will map the terms to existing terms as a sort of translator or term machine.<p>&quot;&quot; We are thrilled to announce Kargo, a multi-stage application lifecycle orchestrator for continuously delivering and promoting changes through environments. Kargo, brought to you by the creators of the Argo Project, is a reimagining of CD pipelines for the cloud-native era, with first-class GitOps support, progressive delivery features, and is 100% open source. &quot;&quot;

Every time there&#x27;s a new tool, it&#x27;s worth considering if it locks in previous choices. E.g. ArgoCD means I can&#x27;t move off Kubernetes. Will Kargo mean I can&#x27;t move off ArgoCD or Kubernetes?

Environment promotion is an area that has been severely lacking with GitOps tools. I&#x27;ve hacked together CI pipelines to do environment promotion with Argo CD before and it was far from my preferred approach, but I could never find a good GitOps way of handling it. Might check out the webinar tomorrow to see if this is something worth trying out.

What about having a git repo that has a Kustomize base which has overlays for different environments?<p>This way each environment is in its own directory which can have its own patches such as using a private load balancer instead of public for a staging environment or setting whatever environment variables that need to be different.<p>Then at the Argo CD level, Argo CD running in prod will look for an Application in the prod&#x2F; directory and Argo CD running in staging will look for an Application in the staging&#x2F; directory.<p>All in all you end up deploying the same artifact across environments and all of this is managed and exposed by Argo CD. For example you might want AutoSync enabled for staging so developers can auto-deploy their code but prod requires a tech lead or manager to push the sync button to deploy it.<p>The above works well in practice and isn&#x27;t too complicated to pull off.

I mistakenly read that as &quot;Kargo, a multi-stage .... lifestyle orchestrator&quot; and thought, damn, that sounds interesting!

I&#x27;m not a CI&#x2F;CD specialist, so help me out. Is this something that is more suitable for large, complex setups or is it something smaller shops should be considering too? How does it compare with competitors like Spinnaker?

Is this tool similar to <a href="https:&#x2F;&#x2F;dagger.io&#x2F;">https:&#x2F;&#x2F;dagger.io&#x2F;</a>?

&gt; Unlike CI, Kargo deployment pipelines are not generic “jobs” (...). Instead, Kargo Stages are used to model your environments (...)<p>I didn&#x27;t see an explanation of how Stages are different than jobs. Every single usage of Stage could have been replaced with job and the meaning would stay the same.<p>The data and DevOps marketing people really need to drop the buzzwordism.

It sounds like the solution all of us knew Argo needed to solve but didn&#x27;t. I&#x27;m... hopeful? But besides the fact that it&#x27;s not finished yet, it also sounds like it&#x27;s going to be tightly integrated into their &quot;Akuity Platform&quot;. Tightly integrated solutions are an anti-pattern; we&#x27;ll end up with cobbled-together scripts again when something we need to do isn&#x27;t allowed by the &quot;opinionated&quot; platform.

I had the good fortune to work with Akuity last year. I haven’t looked at Kargo yet but I’m sure it’s going to be solid based on my experience with their engineering and leadership. The problem it is trying to solve for is very real and historically expensive to solve for. Most companies that operate in multiple clusters and want to do GitOps will face this issue, especially when there are gates and approvals that happen between environments.

If Kargo requires R&#x2F;W access to GitHub, and auto updates charts&#x2F;images, isn’t that asking for your production environment to be infected by a change prepared and cultured in your dev environment and then auto updating &#x2F; hiding itself into prod freight?<p>We disallow writing back to GitHub to avoid this issue, and manage stages through branches, combined with directories for overlays. Things can get out of sync, but comparing branches is easily automated.

This looks interesting, codifying and automating promotion looks cool.<p>In my experience it gets pretty hairy to build automated conditional promotion in a GitOps pipeline, especially if you don’t go all the way to continuous delivery and might have different versions at different stages between environments.

For those who are curious here is the Github repo <a href="https:&#x2F;&#x2F;github.com&#x2F;akuity&#x2F;kargo">https:&#x2F;&#x2F;github.com&#x2F;akuity&#x2F;kargo</a>

Sounds promising. Vaguely terraform like in its application to outside subscription services.<p>Can’t say I’m a fan of “we call it freight” though. Artefact is a perfectly fine word.

As of writing this, there are 5 total comments, 4 of which are by very inactive or brand new accounts with no activity, adding unhelpful&#x2F;low-effort posts like:<p>&gt; Something like this is definitely needed in the GitOps space...always felt like something was missing between promoting things and rolling them out<p>&gt; Interesting. Will share with my team and try it out.<p>&gt; There is a webinar tomorrow with Kelsey Hightower! Here is the link if you want to join https:...<p>&gt; Looks promising, I&#x27;m definitely going to take it for a spin!<p>Something tells me this isn&#x27;t organically gaining traction...

Another project announcement, another situation where I would literally pay a coffee&#x27;s worth to cut to the chase -- why is there a need for another GitOps tool when several already exist?<p>Tighter integration with other Argo products? Why is this not simple a new component of Argo CI&#x2F;CD? How much is &quot;thought-leadership&quot; a part of it, it is Kubernetes-adjacent, after all.<p>So far even the answers in this thread leaving me asking these questions even more strongly? If Argo CD is a &quot;continuous deployment&quot; tool, why isn&#x27;t the priority making staged-rollouts a first class feature in Argo CD itself?<p>This is coming from a place of curiosity, not simply being a miser, I promise.

Something like this is definitely needed in the GitOps space...always felt like something was missing between promoting things and rolling them out