Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kargo, a multi-stage application lifecycle orchestrator

akuity.io

Post reply on HN
Print view View original

61–70 of 83 posts

Re: Kargo, a multi-stage application lifecycle orchestrator

#61

Post by avianlyric »

wg0 wrote: post #51
rjzzleep wrote: post #18

I'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't be accounted for. I have a little bit of hope that this one is going to be different with the lessons they got from Argo, but I'm not holding my breath. Ps. when I first…

I don't understand one thing about GitOps. Imagine 10 apps deployed. All are actively deployed let's say few times a day. You want to go back 10 days for App A. But in doing so you would have reverted whole state and all apps as they were 10 days ago. Only way is to cherry pick particular commit and revert it. No? I mean how git can be useful in rolling back singel components back and forth?

Personally I like to treat the Git in GitOps as an implementation detail. The underlying principle of GitOps is that your entire environments setup and config is written in code, and version controlled. So you can in theory pick any version of your entire env, throw it at blank slate, and reliably get the environment specified by that git hash.

Then there’s the whole constant reconciliation of your version controlled env specification, and the actual env, and how you automatically resolve differences. With the most important principle being that the version controlled code/config is absolute truth and something needs to figure out how to bend the world to match.

But importantly in all of this, Git isn’t that important. Version control is important, infrastructure as code is important, but Git isn’t. Arguably Git isn’t a great tool for GitOps due to issues like the ones you mention. But the huge ecosystem around Git makes the pain worth it.

I would argue the “correct” solution to your problem is a tool that automatically creates the correct cherrypicks and reverts for you based on a request to rollback application X.

Treat git as a dumb version control system, and broadly ignore “good practice”, because at lot of those good practices are designed for software development, not infrastructure development. We need to develop new working practices, built on top of Git fundamental components, rather than trying to rationalise existing working practices against the new problems that appear in GitOps.

Re: Kargo, a multi-stage application lifecycle orchestrator

#62

Post by mplewis »

wg0 wrote: post #51
rjzzleep wrote: post #18

I'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't be accounted for. I have a little bit of hope that this one is going to be different with the lessons they got from Argo, but I'm not holding my breath. Ps. when I first…

I don't understand one thing about GitOps. Imagine 10 apps deployed. All are actively deployed let's say few times a day. You want to go back 10 days for App A. But in doing so you would have reverted whole state and all apps as they were 10 days ago. Only way is to cherry pick particular commit and revert it. No? I mean how git can be useful in rolling back singel components back and forth?

To restore app A to a given state, you add git commits that specify the desired state of app A.

Re: Kargo, a multi-stage application lifecycle orchestrator

#63

Post by nickstinemates »

KenCochrane wrote: post #9
bingemaker wrote: post #8

Is this tool similar to https://dagger.io/ ?

I think they are similar but a little different. From Dagger's website "Dagger is a programmable CI/CD engine that runs your pipelines in containers" Kargo is a tool that works with your existing CI and CD (Argo CD) to help promote your code from one stage (Dev, UAT, QA, Prod, etc) to the next. Kargo has native support for Argo CD today, but one of it's goals is to be agnostic and could probably work with Dagger or o…

Cool to see you around :)

Re: Kargo, a multi-stage application lifecycle orchestrator

#64

Post by KenCochrane »

nickstinemates wrote: post #63
KenCochrane wrote: post #9

Earlier quoted context omitted.

I think they are similar but a little different. From Dagger's website "Dagger is a programmable CI/CD engine that runs your pipelines in containers" Kargo is a tool that works with your existing CI and CD (Argo CD) to help promote your code from one stage (Dev, UAT, QA, Prod, etc) to the next. Kargo has native support for Argo CD today, but one of it's goals is to be agnostic and could probably work with Dagger or o…

Cool to see you around :)

Hey Nick, it has been to long, I hope you are doing well. :)

Re: Kargo, a multi-stage application lifecycle orchestrator

#65

Post by hdjjhhvvhga »

avianlyric wrote: post #61
wg0 wrote: post #51

Earlier quoted context omitted.

I don't understand one thing about GitOps. Imagine 10 apps deployed. All are actively deployed let's say few times a day. You want to go back 10 days for App A. But in doing so you would have reverted whole state and all apps as they were 10 days ago. Only way is to cherry pick particular commit and revert it. No? I mean how git can be useful in rolling back singel components back and forth?

Personally I like to treat the Git in GitOps as an implementation detail. The underlying principle of GitOps is that your entire environments setup and config is written in code, and version controlled. So you can in theory pick any version of your entire env, throw it at blank slate, and reliably get the environment specified by that git hash. Then there’s the whole constant reconciliation of your version controlled…

> So you can in theory pick any version of your entire env, throw it at blank slate, and reliably get the environment specified by that git hash.

The trap here is this only works for stateless infrastructure. If you do it with stateful resources, you'll lose all data. Your gitops tool will happily recreate EC2 instances, S3 buckets and RDS instances, all empty/initialized to whatever you defined.

Re: Kargo, a multi-stage application lifecycle orchestrator

#66

Post by hdjjhhvvhga »

pm90 wrote: post #41
AaronM wrote: post #39

Earlier quoted context omitted.

Using Kubernetes locks you into kubernetes. ArgoCD doesn't lock you into Kubernetes because its just a wrapper around managing kubernetes manifests Its like arguing that cloudformation locks you into aws

I feel like Im missing something obvious but… cloudformation does lock you into aws, doesn’t it?

That's the point. In other words, ArgoCD is a tool for Kubernetes, just like CF is a tool for AWS.

Re: Kargo, a multi-stage application lifecycle orchestrator

#67

Post by tonnydourado »

> Unlike CI, Kargo deployment pipelines are not generic “jobs” (...). Instead, Kargo Stages are used to model your environments (...)

I didn'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.

The data and DevOps marketing people really need to drop the buzzwordism.

Re: Kargo, a multi-stage application lifecycle orchestrator

#68

Post by anomaloustho »

hdjjhhvvhga wrote: post #65
avianlyric wrote: post #61

Earlier quoted context omitted.

Personally I like to treat the Git in GitOps as an implementation detail. The underlying principle of GitOps is that your entire environments setup and config is written in code, and version controlled. So you can in theory pick any version of your entire env, throw it at blank slate, and reliably get the environment specified by that git hash. Then there’s the whole constant reconciliation of your version controlled…

> So you can in theory pick any version of your entire env, throw it at blank slate, and reliably get the environment specified by that git hash. The trap here is this only works for stateless infrastructure. If you do it with stateful resources, you'll lose all data. Your gitops tool will happily recreate EC2 instances, S3 buckets and RDS instances, all empty/initialized to whatever you defined.

There are 2 different thoughts here I think. If using GitOps in Kubernetes, then application and set up (Pods) aren’t associated with Nodes (EC2). And both can be torn down and rebuilt without state issues. When state is required, then PVCs and Stateful Sets come into play.

For managed services like S3 and RDS, there are other GitOps tools like Crossplane.io which you can use for similar GitOps management. But the paradigm shift might also be that you add GitOps config to perform regular backups, and also add config to ensure that if it is being recreated, it restores from a backup.

Re: Kargo, a multi-stage application lifecycle orchestrator

#70

Post by drewda »

bingemaker wrote: post #8

Is this tool similar to https://dagger.io/ ?

Dagger looks more comparable to Argo Workflows: https://argoproj.github.io/argo-workflows/ That's the first of the Argo projects, which can run multi-step workflows within containers on Kubernetes.

For what it's worth, my colleagues and I have had great luck with Argo Workflows and wrote up a blog post about some of its advantages a few years ago: https://www.interline.io/blog/scaling-openstreetmap-data-wor...

Post reply on HN