Hey everyone! I'm working on organizing my projects and I could use some advice. Imagine you have a Kubernetes cluster running in the cloud with over 20 microservices. You're using ArgoCD to manage your deployments along with Helm and a CI/CD pipeline for your Docker containers. I've been thinking about the structure and here's what I've come up with:
- Keep Terraform code in a separate repository that manages the whole cloud infrastructure.
- Use Terraform to also deploy ArgoCD and other operators, either from the same or a different repo.
- Have a dedicated repo for ArgoCD where each service exists in its own subfolder.
- Store Helm charts inside each microservice's Git repository.
Does this sound like a clean way to organize everything? Or do you prefer to keep all ArgoCD and Helm-related files together in the microservice's Git repo? Would love to hear your thoughts!
4 Answers
The key is to keep things organized and scalable. Like if you need to expand from 20 to 200 services, your structure shouldn’t hinder that. We use helmfiles and other tools for managing secrets but I think every setup is subjective based on team preference.
We use a single GitOps repository for all our services along with cluster bootstrap services like Prometheus and others. This way, everything is in one place, and we have a separate repo for Terraform to handle the cluster setup and ArgoCD. I find this approach simpler and easier to manage.
I think it's best to have application-related code in a single repository for efficiency. For example, in a Java project, I include the **pom.xml** for dependencies, a **Dockerfile** for the container, a Helm chart, and a CI pipeline all in one repo. I treat my Helm chart as source code, which means I create both a versioned container image and a Helm chart during the CI pipeline. This allows easy rollbacks and deployments for different environments. Also, I keep ArgoCD decoupled from the application release process, managing versions with a dedicated GitOps repository using an umbrella Helm chart. By doing it this way, I can easily deploy different versions across environments without complications.
That's impressive! I like the push deployment method more than Argo's pull, but I can see the value in Argo's monitoring capabilities.
Our setup is similar to yours, but we have ArgoCD deployed as one of its own applications initially, and then it manages itself afterward. For secrets, we rely on Vault for added security.
Wow, thanks for the detailed response!