I'm trying to decide between two approaches for managing my GitOps setup with two monolith repositories (API/UI) that depend on each other and deploy together. Currently, we use GitLab CI for helm installs, but it can be flaky, so I'm looking to transition to GitOps with ArgoCD running in our clusters. I've experimented with ApplicationSets using PR Generator and Image Updater but faced several issues like incorrect parameter mapping and complex debugging. Now, I'm leaning toward a CI-driven GitOps approach where CI builds the image, commits it to the GitOps repository, and ArgoCD handles synchronization. My main question is about the structure of the GitOps repository: should I have CI commit full Application manifests (App of Apps pattern), commit config files for an ApplicationSet (Git File Generator) to pick up, or consider something else? Additionally, I'm curious about what patterns others use for short-lived feature environments. Thanks for your insights!
5 Answers
If your goal is to deploy the same app of apps to multiple clusters, you might want to use both options. An app set can manage that effectively.
I'm in the same boat! I read in the Argo CD Up and Running book that if a sync with ApplicationSets takes too long, it just marks it as Healthy after a couple of minutes, which seems sketchy. Can anyone clarify the rationale behind this or if I've misunderstood?
How many target clusters are you working with? If you have just a few, using App of Apps works great for us. We're managing three, and it works fine even without a ton of targets.
Just a couple. But within non-prod, I need dynamic feature environments for each MR, which could be up to 20-50 concurrent branches.
Consider using ApplicationSets for dynamic environments while sticking to regular Applications for static ones. The idea is to build a single tree in the cluster rather than creating a forest of them.
Many folks seem to lean towards the App of Apps. With that setup, you'd have an app that watches a specified path with a helm chart that renders to a template of an Argo application using another helm chart. This setup is flexible as the first helm chart can accept a values file that can be easily patched to update the image. I've had success with this for over five years, and it's simple enough to use even for just a few projects!
Thank you! That sounds like a clean setup actually. I'll give it a try!
The applications won’t actually finish syncing until everything is ready, so it keeps working under the hood.