Opened 4 months ago

Closed 3 weeks ago

#2128 closed enhancement (wontfix)

Using a variable in the resolver directive

Reported by: avsdev-cw@… Owned by:
Priority: minor Milestone:
Component: nginx-module Version: 1.19.x
Keywords: Cc:
uname -a: Linux web-proxy 5.8.0-0.bpo.2-amd64 #1 SMP Debian 5.8.10-1~bpo10+1 (2020-09-26) x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.14.2
built with OpenSSL 1.1.1d 10 Sep 2019
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-Cjs4TR/nginx-1.14.2=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/ --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-mail=dynamic --with-mail_ssl_module --add-dynamic-module=/build/nginx-Cjs4TR/nginx-1.14.2/debian/modules/http-auth-pam --add-dynamic-module=/build/nginx-Cjs4TR/nginx-1.14.2/debian/modules/http-dav-ext --add-dynamic-module=/build/nginx-Cjs4TR/nginx-1.14.2/debian/modules/http-echo --add-dynamic-module=/build/nginx-Cjs4TR/nginx-1.14.2/debian/modules/http-upstream-fair --add-dynamic-module=/build/nginx-Cjs4TR/nginx-1.14.2/debian/modules/http-subs-filter


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.

Change History (3)

comment:1 by Maxim Dounin, 4 months ago

Resolution: wontfix
Status: newclosed
Type: defectenhancement

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.

comment:2 by houstonheat@…, 3 weeks ago

Resolution: wontfix
Status: closedreopened

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

comment:3 by Maxim Dounin, 3 weeks ago

Resolution: wontfix
Status: reopenedclosed

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.

Note: See TracTickets for help on using tickets.