Configuration templating using environment variables

[jfroy]

I'm deploying glance to my homelab kubernetes cluster, which I manage with fluxcd and a public GitHub repo. Some of my RSS feeds are private URLs from subscriptions, which means I cannot add them verbatim to the config file, and I'd rather not encrypt the entire config file.

What many other projects with complex config files do is process them through some sort of template engine and import environment variables as template/context variables. Kubernetes secrets can be used as a source of environment variables for pods/containers.

text/template would be more than enough.

[svilenmarkov]

Hey, thanks for bringing this up. Glance already does have the ability to insert environment variables into the config, though the implementation is on a per-field basis and I haven't added it for the RSS feed URLs yet. It does not rely on text/template but you would be able to do this:

- type: rss
  feeds:
    - url: ${MY_FEED_URL}
    - url: ${MY_OTHER_FEED_URL}

Would that suffice?

[jfroy]

Hey, thanks for bringing this up. Glance already does have the ability to insert environment variables into the config, though the implementation is on a per-field basis and I haven't added it for the RSS feed URLs yet. It does not rely on text/template but you would be able to do this:

- type: rss
  feeds:
    - url: ${MY_FEED_URL}
    - url: ${MY_OTHER_FEED_URL}

Would that suffice?

It would suffice for my immediate need, but I wonder if people are going to continue coming up with other fields. A practical answer of course is to just keep adding support as demand is expressed, but it feels adding a quick Go template render to the config code would solve it once and for all.

[svilenmarkov]

Edit: Ignore the below, I've changed it so you can insert them anywhere in the config with the ${} syntax, no need for me to implement them on individual fields anymore. Thanks for idea.

it feels adding a quick Go template render to the config code would solve it once and for all.

I entirely agree that it would be a more future-proof approach, though I plan on using html/template for a new custom API widget where the user can provide the template in their glance.yml, so a simple pre-parse of the entire config would clash with it.

Admittedly, I underestimated the number of places people would like to be able to use environment variables in, which is why I was adding that ability sparingly. For the time being I'll be more mindful about this and try to add it to more fields, though if it does become a pain point in the future I'll think of something to make it globally available by default.

PS: note to self: I guess I could just change the default template delimiters to something other than {{ }}.