Add to helm chart template envFrom

[eyesoftsys]

Feature Request

At this time only this option is supported in the helm chart https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/#define-a-container-environment-variable-with-data-from-a-single-secret

from your code we have this : https://github.com/suitenumerique/docs/blob/main/src/helm/impress/templates/backend_deployment.yaml#L49

Considering the fact that many environment variables are used, this solution is not feasible and is difficult to maintain in this form.

My proposal is to add the possibility of using this solution to the helm chart: envFrom

• https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/#configure-all-key-value-pairs-in-a-secret-as-container-environment-variables

example

kind: Pod
metadata:
  name: envfrom-secret
spec:
  containers:
  - name: envars-test-container
    image: nginx
    envFrom:
    - secretRef:
        name: test-secret

• https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#configure-all-key-value-pairs-in-a-configmap-as-container-environment-variables

example

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox:1.27.2
      command: [ "/bin/sh", "-c", "env" ]
      envFrom:
      - configMapRef:
          name: special-config
  restartPolicy: Never

although for the deployment part there is the possibility of using kubectl patch as an example:

kubectl patch deployments.apps docs-backend -p '{"spec": {"template": {"spec": {"containers": [{"name":"docs", "envFrom": [{"secretRef":{"name":"docs-backend-seccrets"}}] }] }}}}' -n NAMESPACE

this solution is not feasible due to existing jobs in the helm chart :

• https://github.com/suitenumerique/docs/blob/main/src/helm/impress/templates/backend_job_createsuperuser.yaml
• https://github.com/suitenumerique/docs/blob/main/src/helm/impress/templates/backend_job_migrate.yaml

also these options can coexist, env can remain as an alternative for granularity, a simple solution could be like this

now in values.yaml

  envVars:
    <<: *commonEnvVars

becoms in values.yaml

  envVars:
    <<: *commonEnvVars
  envVarsFrom: []

now in backend_deployment.yaml

          env:
            {{- if $envVars}}
            {{- $envVars | indent 12 }}
            {{- end }}

becoms in backend_deployment.yaml

          env:
            {{- if $envVars}}
            {{- $envVars | indent 12 }}
            {{- end }}
          envFrom:
            {{- toYaml .Values.backend.envVarsFrom | nindent 12 }}

of course, the jobs part of the helm files must also be taken into account : backend_job_createsuperuser.yaml and backend_job_migrate.yaml