K
Q

Question

Recommended way to add features to a 3rd party helm chart?

9/10/2019

currently we're adding features to 3rd party helm charts we're deploying (for example - in prometheus we're adding an authentication support as we use nginx ingress controller).

Obviously, this will cause us headaches when we want to upgrade those helm charts, we will need to perform "diffs" with our changes.

What's the recommended way to add functionality to existing 3rd party helm charts? Should i use umbrella charts and use prometheus as a dependency? then import value from the chart? (https://github.com/helm/helm/blob/master/docs/charts.md#importing-child-values-via-requirementsyaml)

Or any other recommended way?

-- EDIT --

Example - as you can see, i've added 3 nginx.ingress.* annotations to support basic auth on prometheus ingress resource - of course if i'll upgrade, i'll need to manually add them again, which will cause problems

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
{{- if .Values.prometheus.ingress.annotations }}
  annotations:
{{ toYaml .Values.prometheus.ingress.annotations | indent 4 }}
{{- end }}
{{- if .Values.alertmanager.ingress.nginxBasicAuthEnabled }}
    nginx.ingress.kubernetes.io/auth-realm: "Authentication Required - ok"
    nginx.ingress.kubernetes.io/auth-secret: {{ template "prometheus-operator.fullname" . }}-prometheus-basicauth
    nginx.ingress.kubernetes.io/auth-type: "basic"
{{- end }}
  name: {{ $serviceName }}
  labels:
    app: {{ template "prometheus-operator.name" . }}-prometheus
{{ include "prometheus-operator.labels" . | indent 4 }}
{{- if .Values.prometheus.ingress.labels }}
{{ toYaml .Values.prometheus.ingress.labels | indent 4 }}
{{- end }}
spec:
  rules:
    {{- range $host := .Values.prometheus.ingress.hosts }}
    - host: {{ . }}
      http:
        paths:
          - path: "{{ $routePrefix }}"
            backend:
              serviceName: {{ $serviceName }}
              servicePort: 9090
    {{- end }}
{{- if .Values.prometheus.ingress.tls }}
  tls:
{{ toYaml .Values.prometheus.ingress.tls | indent 4 }}
{{- end }}
{{- end }}

-- ArielB

kubernetes

kubernetes-helm

2 Answers

9/10/2019

I would either fork and handle integrating the changes when you upgrade/rebase, or if possible disable the ingress elements for those you want to customise via the values.yaml file. Then create your own ingress instances manually with the customisations you need in another custom chart, and provide it the references it needs from the prometheus chart as normal values.yaml inputs.

Obviously this approach has it's limitations, if the customisations are too tightly coupled to the chart it might not be possible to split them out.

Hope this helps.

-- cewood

Source: StackOverflow

9/12/2019

I think that might answer your question.

This led me to find the specific part I was looking for, where the parent chart can override sub-charts by specifying the chart name as a key in the parent values.yaml.

In the application chart's requirements.yaml:

dependencies:
- name: jenkins
  # Can be found with "helm search jenkins"
  version: '0.18.0'
  # This is the binaries repository, as documented in the GitHub repo
  repository: 'https://kubernetes-charts.storage.googleapis.com/'

Run:

helm dependency update

In the application chart's values.yaml:

# ...other normal config values

# Name matches the sub-chart
jenkins: 
  # This will be override "someJenkinsConfig" in the "jenkins" sub-chart
  someJenkinsConfig: value

-- jt97

Source: StackOverflow

KQ

Recommended way to add features to a 3rd party helm chart?

Similar Questions

2 Answers

K
Q