Hacker News new | ask | show | jobs
by therealkrancour 1001 days ago
I am a lead on Kargo. That's a great approach you've described and Kargo helps you make that approach work even better. It's not trying to re-solve problems that are already solved well by config management tools or by Argo CD. It provides a higher layer that integrates with those to orchestrate the progression of changes from one environment to another...

So in your example, suppose you changed something in your Kustomize `base/` directory. With _just_ Kustomize and Argo CD, those changes roll out to all environments all at once. With Kargo, you can progress the change and (re-)validate it environment-by-environment.
2 comments
nickjj 1001 days ago
> With _just_ Kustomize and Argo CD, those changes roll out to all environments all at once. With Kargo, you can progress the change and (re-)validate it environment-by-environment.

In prod it wouldn't get rolled out until someone manually clicks the sync button for each app in that environment. But yes, in staging it would get AutoSync'd to all of the apps. I get what you're saying though.

It will be curious to see how Kargo works across multiple clusters in the staging vs prod example where both clusters each have their own Argo CD instance running but you want to view and promote an artifact across N clusters.

In any case, I'll give it a look when it's available to see how it can improve my current workflows. Overall I'm really happy I started using Argo CD ~2 years ago.

link
therealkrancour 1001 days ago
> In prod it wouldn't get rolled out until someone manually clicks the sync button

That's a great point and if that works for you, awesome! Note though that relies on the state of the prod Application to temporarily contradict the source of truth that is your repo. If you lose that prod Application and re-create it, prod will be in a state you hadn't yet blessed.

link
nickjj 1001 days ago
Indeed. That use case hasn't been something I encountered yet since we generally operate at a scale where our apps at the Argo CD level rarely change once they've been created.

But thanks for pointing out the mismatch on the source of truth. Definitely something to consider.

link
denysvitali 1001 days ago
We faced that (and are facing it today) with Helm chart updates.

In our current setup it's not possible to rollout a new version of an Helm chart in dev, then in staging and finally in prod (without causing an out of sync state.

The rest is managed via values-$env.yaml, which works perfectly fine

link