Using a variable in the resolver directive

[avsdev-cw@…]

TLDR: My request is that the resolver directive be capable of supporting variables.

Currently I am required to run services on different networks which have different subnets and may have different stand-alone DNS servers (some of which are dynamic DNS servers).

I am using nginx as a reverse proxy on a host which has multiple nics allowing it to connect to hosts of the various networks.

This main host has a common configuration file for proxying (reducing the overhead of managing multiple proxied hosts) and utilises a variable to pass into the proxy_pass directive. Currently the common configuration file has a "resolver" directive indicating the DNS server to use to resolve the proxy_pass host.

This works great when only 1 DNS server on 1 subnet is required, however some of the upstream hosts are on a different subnet with a different DNS configuration and their own DNS server.

Currently the "resolver" directive produces an [emerg] level error when attempting to use a variable as the host:

nginx: [emerg] host not found in resolver "$resolver_ip" in /etc/nginx/proxy_config:20

which leads me to believe that the directive does not support variables. In addition, it appears the resolver directive cannot be overridden and must be used once and only once in server block.

[Maxim Dounin]

The ​resolver directive indeed does not support variables. Only some directives (and some parameters of them) do support variables. As long as variables are supported in a particular directive parameter, this is explicitly documented.

However, the resolver directive can be used at location level (note "Context: http, server, location" in the documentation). This means that you can use different resolvers by configuring proxying to networks which require using different resolvers in different ​location blocks.

[houstonheat@…]

Today we need to support many different environments like static well tested production, or dynamically generated development and stage setups.

We want to use "dynamic" resolvers per environment (main http{} block, default resolver), not locations:

• resolver kube-dns.kube-system.svc.cluster.local; (default svc) in Kubernetes production environmet;
• resolver 127.0.0.11; in plain Docker environment
• resolver xx.xx.xx.xx; in another isolated environment with specific DNS server.

Today it's OK to have one single configuration file with multiple variables to fill them during build, deployment or runtime. We can workaround this problem with the evsubst utility, but this solution forces us to use third-party utilities and may lead to unwanted results during variable substitution.

It would be great to be able to use a single variable for all types of environments (e.g. env NGINX_RESOLVER; resolver $NGINX_RESOLVER;), which will be populated during the application startup process.

[Maxim Dounin]

So it looks like you are asking for macro expansion during configuration parsing, not variables support. See ​FAQ for explanation why variables shouldn't be used instead of macros.

As of now, nginx doesn't support macro expansion in configuration files, though these can be easily added via external tools. Feature request to introduce macro expansion can be found in ticket #267.