Provide shell environment variable to yml file

[Maissacrement]

No description provided.

[gotjosh]

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?

[roidelapluie]

Prometheus only supports environment variables in very specific areas of the configuration.

[simonpasquier]

+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.

[Maissacrement]

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 ?

[peterbourgon]

No reason for the config file to support this natively.

export FOO=bar
cat alertmanager.yaml.template | envsubst > alertmanager.yaml

[Wilderone]

@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

[roidelapluie]

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?

[Maissacrement]

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

[splitt3r]

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.

[simonpasquier]

I think that I understand what you're trying to achieve here: it's something that we've already discussed before and we've always considered that it should be the responsibility for your config management system rather than Alertmanager.
A change of direction would need to be discussed for all the Prometheus projects (e.g. Prometheus + exporters).

[SuperQ]

Hello from the Alertmanager bug scrub. This change is stale so it will be closed. If you would like to continue this work, please open a new pull request.