3 ms·
I have yet to find a good solution that accomplishes both these goals. 1. Have a central location for our helm charts so that we have one copy of our charts
by hitpointdrew 3y ago
I have yet to find a good solution that accomplishes both these goals.
1. Have a central location for our helm charts so that we have one copy of our charts with separate values for our various environments.
2. Have tight controls around who is allowed push what where (allow devs to push to the dev environment, allow team leads push to QA, etc.)
Separately each goal is easy to accomplish, but if you want both, it seems to break the GitOps paradigm. Multiple branches or repos means you now have helm templates all over the place and quickly you get drift. Having one branch and repo consolidates your templates, but now you need to either allow any dev to change any value for any environment, or you have to slowdown your devs and gatekeep the repo and only those who are allowed to make prod changes are responsible for merging in ALL changes to every environment.
Ultimately it seems like the best compromise is you end up with multiple deployments of Argo/Rancher (whatever CD tool you have), which monitor your helm charts pointing at least two separate repos, one that is for non-prod, and another that is prod.
- tecleandor 3y agoTo avoid drift, I would keep the charts in one repo, but separate the values files in different repos per environment. IIRC, Argo CD now allows to get your values.yaml from a different repo than the one you're using for the chart. So you create a very restricted repo for the charts, and then one repo por every environment that only (or mostly) contains a values.yaml. You deploy then X applications or application sets, all pointing to the same chart, but pulling the values from different repos.