-
Notifications
You must be signed in to change notification settings - Fork 1.8k
[Feature Request] Consider adding a script to import local resolver from /etc/resolv.conf #673
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I assume it would be enough to take the nameserver from Regardless what approach will be used, I'd love to see the feature implemented. |
Hi @thresheek Just to make sure I understand correctly the feature in #687 , If yes, then I guess it's really helpful for this feature request. But I'd like to make the case why this Why? Because doing an apparently simple thing, like a proxy_pass to a hostname instead of IP address, suddenly becomes really complicated. This is because nginx, by default, resolves the hostname only once - when the config is (re)loaded. Any IP changes for that hostname will cause connection errors until nginx is reloaded. And there are plenty of people trying to solve this issue:
Even in this repo in the past: #600 #127 A lot of the proposed fixes online are doubtful, like hardcoding a public DNS IP, or hardcoding the default docker DNS IP - 127.0.0.11. This reduces the portability of the docker image, because in some docker environments, those values are be incorrect. But there is a really good solution: extract the nameserver IPs from /etc/resolv.conf at container start, and use these in the nginx |
Hi @dsech! Your understanding is correct, take a look at the following snippet for illustrations on how it works:
Note that it does not propagate an environment variable into the image, just makes it available during the preconfiguration run. I don't really see the point of including such a script that will automatically make it available for any and all entrypoints. The reasoning is that since if you're writing your own (admittedly somewhat complex) configuration for a proxy, it's not a lot harder to include a simple shell script to figure out what resolvers need to be configured in your own environment. That's exactly what the docker-entrypoint.d construct is supposed to do: easily extend configuration for more complex scenarios. Hope this makes sense, |
Hey @thresheek In that case #687 is really helpful for me, thank you!
I understand, I only suggested it because it feels like a common pattern. Well, common at least for someone who needs to configure a resolver/proxy. And it is true, if someone needs a custom nameserver then it is really easy to include it in the configuration, hardcoded or as a user-defined env variable. But, at least personally - the complicated part was when I wanted to use the nameserver already configured in the container - in which case I had to figure out I needed exactly this specific script placed in this specific directory. And I respect your decision that it doesn't make sense to include the entire script and exposing this predefined env variable by default, but I had to make the suggestion :) |
Thanks for the explanation. I believe we can try to tackle this complexity by documenting it in the image docs. |
Sorry I missed this earlier! Not quite - I was suggesting a built-in entrypoint script that would specifically set the resolver to the nameserver in /etc/resolv.conf I think the cause of the issue is mentioned here: https://www.nginx.com/blog/dns-service-discovery-nginx-plus/
But, I want it to refer to /etc/resolv.conf! Now, it seems like OpenResty does provide this functionality
My suggestion was to add a built-in script that approximates this OpenResty functionality, and could be enabled (kind of like the auto-tune worker processes one can be enabled) by setting an environment variable, eg. NGINX_USE_LOCAL_RESOLVER=1. It seems like wanting to do this is a common enough use case. Until then, I've been using this suggestion:
from https://serverfault.com/questions/638822/nginx-resolver-address-from-etc-resolv-conf It sounds like with the changes mentioned above, I could instead export a variable instead of using echo, but still need to add a custom script. It would be great if this could instead be a builtin entrypoint script. |
If enabled via NGINX_ENTRYPOINT_LOCAL_RESOLVERS variable, this script will populate NGINX_LOCAL_RESOLVERS variable that can be used in the envsubst-base templating to populate the configuration files. Fixes nginx#673
Thank you for such a great feedback @ikreymer and @dsech ! The linked PR implements the following logic:
My thinking is that it would be enough for the image users to be able to use it for templating - e.g. creating a resolver.template is fairly straightforward, and I don't think it makes much sense to edit the nginx.conf like we do for worker processes auto-tune. Please let me know what you think, |
I found this feature while I was exploring the image. Can this be added to dockerhub's nginx image documentation? Thank you all for this issue and PR, it's just what I needed to make my image compatible both with docker daemon and kubernetes. |
Thank you for implementing this, it perfectly solves my use case. I also found this feature after exhausting other routes and digging through the source code. I second the request to add this to the dockerhub and github documentation to save others some time. |
I’ve implemented a better idea that could be useful for others. I have a If For more information, please check the source code: https://github.com/Alwatr/nginx/blob/next/nginx/etc/nginx/entrypoint.d/10-local-resolvers.envsh |
Since this image does not support the
resolver local=on;
that is only available in OpenResty, it may be useful to add an init script that optionally parses the nameserver from/etc/resolv.conf
and sets it as the resolver, as suggested in:https://serverfault.com/questions/638822/nginx-resolver-address-from-etc-resolv-conf
Seems like this may be a common enough use case and could be enabled with a
NGINX_USE_LOCAL_RESOLVER
The text was updated successfully, but these errors were encountered: