alertmanager
alertmanager copied to clipboard
prometheus
Provide shell environment variable to yml file
Sorry for coming across as a bit abrasive here, but what exactly is the goal of this PR?
From a quick look at other repositories (Prometheus, Cortex) I don't think this is something that we do so precedent is not there. Furthermore, you can always generate your configuration first and then pass it onto us directly - so I don't really follow the conversation on #2846.
Am I missing something @simonpasquier @roidelapluie?
Prometheus only supports environment variables in very specific areas of the configuration.
+100 to what @roidelapluie said. It would an org-wide decision to support expansion of environment variables in configuration file and it isn't something that we've agreed on so far.
I encountered some issue with alertmanager who is already provide by prometheus. I talking about smtp authentication where i need to rewrite alertmanager yml configuration to add secrets, urls and more in my git repository for production.
I thinks we can also challenged data with curly brace bracket to distinguish data as SHELL environment ?
No reason for the config file to support this natively.
export FOO=bar
cat alertmanager.yaml.template | envsubst > alertmanager.yaml
@peterbourgon this is not so simple then you deploy alertmanager within kubernetes through helm chart. Yes, it is still possible, but with huge overhead just for simple substitution
The way to deal with this is to put env variables into files and read from files. A lot of useful fields already support that. What is your use case?
pragmatically in devops we are confronted with problems which require to quickly operate solutions for our customers in a non-binding way. So I worked on this POC in order to inject secrets into a container at a moment in order to provide the configuration files as data and to automatically deploy to a target container https://github.com/Maissacrement/secret-manager
The way to deal with this is to put env variables into files and read from files. A lot of useful fields already support that. What is your use case?
What about a cmd flag like https://grafana.com/docs/mimir/latest/operators-guide/configuring/reference-configuration-parameters/#use-environment-variables-in-the-configuration e.g. I think it would be great to have env var substitution here as it is supported by a lot of other components used around Prometheus. It seems to be supported by Grafana, Mimir, Cortex, Thanos and Jiralert. This way the configuration of all components would work alike.
