Suggestion: Create a helm chart

[WhiteDiamondz]

Good afternoon !
I find your project very useful and wanted to implement it since I currently have the use case with mimir. However, I noticed that there are only the manifest files for the k8s resources and I couldn't help but think that an helm chart would allow more people to easily set up and customize your solution !
It is posible to publish one and claim ownership on Artifact Hub
If you are interested, I could create a merge request with a basic helm chart with templated manifests, let me know !

[blind-oracle]

Sure, please do, i don't use it but if it will be useful - why not

[WhiteDiamondz]

Hey again !

I've started working the helm chart implementation but I encountered a difficulty. For security reasons, I pass authentification secrets to the pod through environment variables. However, the code is not configured to replace an environment variable in the config with it's value.

To better illustrate what I mean, my config file that looks like this:

[...]
    auth:
      egress:
        username: ${MIMIR_CLIENT_ID}
        password: ${MIMIR_CLIENT_SECRET}
[...]

Any chance a new function like configEnvParse() or a new section in configParse() could be added to replace the variables with their values before loading it?

[marcinfigiel]

The configuration is loaded from a config file, right? You can add a ConfigMap to the chart templates, mount it to the pod under the config file path and fill it with values from the values.yaml file.

ConfigMap template:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cortex-tenant-config
  namespace: {{ .Release.Namespace }}
data:
  "cortex-tenant.yml": |
{{- with .Values.config -}}
  {{- toYaml . | nindent 4 }}
{{- end -}}

Deployment volumes section:

      volumes:
        {{- toYaml .Values.volumes | default "" | nindent 8 }}

Deployment spec volumeMounts section:

          volumeMounts:
            {{- toYaml .Values.volumeMounts | default "" | nindent 12 }}

Values file:

volumes:
  - name: cortex-tenant-config
    configMap:
      name: cortex-tenant-config

volumeMounts:
  - name: cortex-tenant-config
    mountPath: /data/cortex-tenant.yml
    subPath: cortex-tenant.yml

config:
    # Where to listen for incoming write requests from Prometheus
  listen: 0.0.0.0:8080
  # Log level
  log_level: error
...

The config section is the content of the configuration file.

What do you thinkg about this approach?

[WhiteDiamondz]

Yes, this is already what I am doing.

However, I wish to use a Kubernetes secret to isolate sensible info (in this case the login/password for the authentication). This implies referencing the file that contains these secrets in the configuration or to pass them through environment variables.

From what I understand, your solution would require such sensible information to be in plain text in your values.yaml file with the rest of the configuration wouldn't it?

Instead of having a commited values.yaml file that looks like:

config:
  auth:
    username: my-username
    password: p@ssword!

I want it to be like the the following with the variables correctly used once the config is mounted to the pod:

config:
  auth:
    username: "${MIMIR_CLIENT_ID}"
    password: "${MIMIR_CLIENT_SECRET}"

[WhiteDiamondz]

Another solution could be for the tool to check the existence of the environment variables that would correspond to the auth:

• CORTEX_TENANT_USERNAME
• CORTEX_TENANT_PASSWORD

If one of them (or both) are defined when the tool starts, it will use thes environment variable's value and ignore the corresponding section in the config (auth.username and / or auth.password).

It would give the liberty to the users on how they wish to set these variables: the configuration file or the run environment.

[marcinfigiel]

What about a --set parameter? It overrides the values file:
helm install ... --set config.auth.password=${PASSWORD}

Of course handling it via environment variables would be more elegant, but it also requires code changes.

[WhiteDiamondz]

What about a --set parameter? It overrides the values file: helm install ... --set config.auth.password=${PASSWORD}

Of course handling it via environment variables would be more elegant, but it also requires code changes.

I agree that there are a few ways to achieve this without any code changes. Another one would be (in my use case) to use a Secret instead of a ConfigMap (for the whole file). But it isn't the most elegant either 😅 and since this project is still maintained I thought it could be a better solution to suggest a code change.

[blind-oracle]

@WhiteDiamondz It's maintained, but more or less on a bugfix/PR-accept basis :) Because I don't work with it anymore. Some quick things I implement, but not sure that I'll have time for bigger changes. Maybe adding something like https://github.com/caarlos0/env will be easy to start supporting env vars, will take a look.

[blind-oracle]

Ok the env vars should work now, see the README for them. They override the config file values (if you use config at all)

[WhiteDiamondz]

Ok the env vars should work now, see the README for them. They override the config file values (if you use config at all)

Works great thank you so much for the new feature even if you don't use the tool anymore !