Hey folks! I'm working with two monolith repositories (API/UI) that are tightly integrated and deploy together. Each GitLab merge request creates its own feature environment. Currently, we're using GitLab CI to handle helm installs directly, but it's been a bit unreliable for us. We're eager to transition to GitOps, and we already have ArgoCD set up in our clusters.
I had a go at using ApplicationSets along with the PR Generator and Image Updater, but I ran into some issues:
- The Image Updater doesn't manage multi-source Applications properly, leading to incorrect parameter placements.
- Figuring out why an image didn't update is quite a headache.
- The overall setup feels overly complex for what we need.
I'm starting to sway towards a CI-driven GitOps approach where CI builds the image, commits it to the GitOps repository, and then ArgoCD syncs from there.
So here's my question: For setting up the structure of the GitOps repository, should I:
1. Have CI commit full Application manifests (using the App of Apps pattern)?
2. Have CI commit config files that are picked up by an ApplicationSet (via Git File Generator)?
3. Or is there something else I should consider?
Also, what patterns are others using for managing short-lived feature environments? Thanks for your help!
6 Answers
I'm fully on board with ApplicationSets! They can be super flexible, even if their syntax can feel a bit tricky at times.
Utilizing ApplicationSets for dynamic environments while keeping traditional Applications for static ones might be the best combo. Just make sure to keep it structured as one main tree in the cluster instead of a messy forest! That way, everything stays organized.
I’d recommend sticking with the App of Apps pattern. It’s pretty cool because one app can oversee the others, and you can set it up so it watches a specific path with a helm chart. This way, it renders to an Argo application template using another helm chart for the workloads. I've managed this for years on a larger scale, and it's simple enough for smaller projects as well. Definitely worth trying out!
Definitely use both methods. ApplicationSets can be great for deploying the same App of Apps across multiple clusters, which is super convenient. It’ll help keep everything organized, especially if you've got several targets.
I've been grappling with similar questions. I came across something in the Argo CD Up and Running book about ApplicationSets. It mentioned that if a sync takes too long (like over 2 minutes), it auto-switches to a Healthy state, which seems kind of off. Does anyone know the reasoning behind that, or am I misunderstanding it?
The applications will keep progressing until they’re ready, so it’s not as bad as it sounds; it just marks them healthy even if they’re still in the process.
The way we handle it is by using App of Apps for a limited number of clusters. It works well for us because we don't manage a lot of targets—just a few, really.
Thanks for the insight! This sounds like a straightforward approach. I'll be sure to test this out!