We run different smart-proxies in Docker containers and configure these via file volume mounts. This works but it implies a lot of work to manage all the configuration files. We would like it to use environment variables instead but fear that this is currently not possible.
Expected outcome:
We have the following /etc/foreman-proxy/settings.d/dns_nsupdate.yml:
We would expect that dns_server expand either to the value of DNS_SERVER environment variable or to localhost if the environment variable does not exists or is empty.
No, Foreman Proxy doesnāt support environment variables. I think that it also should be the IP of your actual nameserver because it does DNS queries to verify if there are conflicts.
Why do you not have a nameserver with a static IP?
Note that if you donāt want DNS integration, you can just disable it.
Are you planning to support environment variables? Because Envs are a common way to configure containers, instead of having to edit entire configuration files.
I think @TimoGoebel has looked at it, but Iām not aware of anyone spending time on it.
However, I really question the benefit of running it in a container. The proxy is by design linked to services - the original goal was to provide a REST API for services that have no API. Nowadays there are some that make more sense, but it doesnāt feel like the smart-proxy is very container friendly. For example, it does structured data types in various places and that doesnāt translate well to env vars.
Was just an idea for so generic configurations like dns_nsupdate. And however there are use cases where you donāt have any chance to work without containers. The customer decided it in the last instance.
We run all in containers in our current project and it worked well.
In an experiment I did a while back I tried to recreate the Smart Proxy in Python. I donāt think I ever published the versions with plugin loading and configs, only the very basic protocol implementation (https://github.com/ekohl/python-smart_proxy). The main struggle I had there was that you end up with very long env vars. For example, to configure the nsupdate DNS provider dns server you would likely end up using SMART_PROXY_DNS_NSUPDATE_DNS_SERVER. This is because you want a general prefix (SMART_PROXY_), the module (DNS_), provider (NSUDPATE_) and the setting (DNS_SERVER).
When @TimoGoebel played with adding support for env vars, another problem is that there isnāt an explicit list of settings. They may have a default or some validation, but thatās it. Adding these explicitly isnāt difficult, but it is needed to enumerate. If youāre interested in implementing this, thereās a few more concrete pointers we can give you.
I understand the problem. Namespacing in ENV var names should be on the table and this makes it hard to have an easy to handle set of environment vars.
As Iām not an developer I canāt unfortunately contribute here code, Iām an architect and have sometime good and other times bad ideas and I like to discuss these.
And that feedback is very much appreciated. This is a good reference thread for anyone interested in this, but I should at least link the PR I was mentioning:
If you have more things that can use improvement, please share it. I know that at least I, as a developer, find it hard to be further removed from actual production environments. That makes it harder to which issues people experience āin the real worldā.
