Kustomize structure not flexible enough for customer to use without forking bigbang repo
My organization have bigbang fully running on our own automated built k8s cluster on top of many AWS EC2.
We 'try' to not fork the repo https://repo1.dso.mil/platform-one/big-bang/bigbang but it's hard because the structure or framework 'kustomize' is just not giving us enough control to be able to do our work/configuration.
First, issues started with BigBang rewriting helm chart to become less flexible than the original, and adding wrong validation like:
- https://repo1.dso.mil/platform-one/big-bang/apps/core/istio-controlplane/-/issues/10#note_229922
- https://repo1.dso.mil/platform-one/big-bang/apps/core/istio-controlplane/-/issues/11#note_229208
So we had to introduce a more flexible open source framework than Kustomize -> https://github.com/kubemod/kubemod
Now, we just added ourselves Keycloak, in the 'dev' folder of the BigBang file structure, using own Helm chart, own config, since BigBang is super late on providing this important piece of the solution. But, we try to reuse the logic for private-registry secret, the mechanism to allow to pull from private docker repo, but it seems to not be possible. As a side note, there is so much copy/paste of logic to handle the registry secret and inject them for each pod, it's just looks very bad. You should probably use Kubemod for that. Anyway, assuming I don't fork BigBang repo, and put my new logic in 'dev' BigBang Config folder to introduce Keycloak, I don't see how I can reuse this construct:
dev/keycloak.yaml
apiVersion: v1 kind: Secret metadata: name: private-registry namespace: keycloak type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: {{ template "imagePullSecret" . }}