Discuss continuous delivery of infrastructure
GitOps… I’m still struggling to find any real reason to move from change-driven CI/CD with helmfile to something like ArgoCD or Flux.
With the CI/CD “push” approach, I can see deployment issues in a familiar interface, and a single pipeline view through to deployment. I can deploy through environments with visible e2e or smoke tests.
In the GitOps “pull” model I have yet another interface and bunch of logs to sift through. I have to workaround some things like CRDs.
IMO, most GitOps repos end up a bit of a mess over time
If you can’t see a reason to move to gitops, don’t.
I’d consider a gitops if I were starting from scratch, but I’d have a hard time justifying a move from something else to gitops unless there were clear benefits and improvements over my current approach. (I’m also using an helmfile CI/CD approach.)
IMO, the biggest advantage with ArgoCD is that it provides an “immutability firewall”
https://www.weave.works/blog/what-is-gitops-really (note, these are the flux docs)
What is Gitops? If you’ve ever what GitOps actually is, this article is for you. Get a concise definition of GitOps with comparisons and examples.
With the immutability firewall, you ensure your CI systems don’t have direct access to the clusters which forces every change to go through the VCS.
It’s a bit convoluted, but at Cloud Posse we still use helmfile, but we use the
template functionality to render the manifests to our deployment VCS.
Deploy on Kubernetes with ArgoCD
@Tim Birkett Disclaimer, I am contributing to the Argo project, and work for a company that has an enterprise GitOps product.
Biggest advantage is solving configuration drift once and for all https://www.cncf.io/blog/2020/12/17/solving-configuration-drift-using-gitops-with-argo-cd/
Second advantage is the live view. With a traditional pipeline, you deploy something, it finishes ok. 5 minutes later the app crashes for some reason and the pipeline still shows up as “green”. With ArgoCD/Flux you get a live view of what is actually deployed or not.
Third advantage is that diffing between environments is as easy as diffing between git repos/branches/folders (because point 1 stands)
That being said GitOps is not perfect. https://codefresh.io/blog/pains-gitops-1-0/
GitOps as a practice for releasing software has several advantages, but like all other solutions before it, has also several shortcomings. It seems that the honeymoon period is now over, and we can finally talk about the issues of GitOps (and the current generation of GitOps tools) In the article we will see the following […]
For GitOps of Helm, what’s your preference between:
• :a: CI tool renders to k8s manifests (
helm/helmfile template) -> writes to git/s3/… -> CD tool (flux/argo/…) pickups rendered manifests and applies them to cluster.
• :b: CD tool (flux/argo/…) uses it’s own
helm functionality to render on the fly and apply to cluster.
And for both, what’s your take on compatibility with Helm hooks?
We’re using option A
One thing that is unfortunate about ArgoCD and plugins, is to upgarade/update a plugin, you need to redeploy ArgoCD, which is a disruptive action. Reminds of Jenkins.
cc @Matt Calhoun