compliantkubernetes-apps
compliantkubernetes-apps copied to clipboard
elastisys
Investigation: Find ways to group and manage helm charts and values
What should be investigated. Apps is compromised of multiple helm charts with even more value files. Finding things can be very difficult, especially finding things that depends on each other. Structuring and grouping charts and values files could help in this regards and this should be investigated.
One idea would be to group them based on namespaces to have things related to each other in a single place. And this could be extended to look through dependencies to capture that in groups as well.
What artifacts should this produce. Issues with preferred way to group helm charts and values.
Expanding the scope here a bit: It would be good to also think about how the different helmfiles are structured. Some guidelines on which helmfiles to put things in and what numbers the helmfiles should have would be nice.
I kind of want to expand even further and try to modularise some of our releases where possible, especially kube-prometheus-stack since it takes a really long time to apply and since it's in the first helmfile it needs to be fully ready before the apply continues.
Splitting up so that the Prometheus Operator runs separately will enable the rest to be applied afterwards.
And I want to be able to reduce these kinds of dependencies so one can deploy targeted parts for testing and QA.
Yeah I agree that there is a lot that we could refactor in different ways to make it both faster and more configurable to deploy. On the topic of prometheus I think (but not 100% sure) that we only need the CRDs (maybe only servicemonitor) from it before we can install other things.
Yeah, I was thinking in those lines as well and then those could be moved to bootstrap, but I think we will loose the validation in that case. But for component testing that would not really be an issue,... so maybe an idea? And then see if we can do some validation in unit testing to cover that.
We would also loose any automated management of the CRDs that the operator might have. So it's not 100% clear that we should go this direction, but it would be interesting to investigate.