-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Add resolver and zone configuration to nginx.conf #4079
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
Conversation
| proxy_read_timeout 30s; | ||
| proxy_send_timeout 5s; | ||
|
|
||
| resolver 127.0.0.11 valid=30s; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is podman DNS daemon 127.0.0.11 as well?
This may also break users who have changed their docker daemon IP address to become something else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not familiar with podman, but I understand 127.11 is not a standard, just something docker chose.
The solution would be to read /etc/resolv.conf and inject resolver into nginx.conf via a template.
There is a similar solution here using a custom entrypoint for nginx
penpot/penpot#5861
https://github.com/penpot/penpot/pull/5967/changes
|
Just a reminder that nginx resolves things at startup. You need to reload it on IP change or use variables. |
|
Oh, I didn't see 1.27.3 change. Nice. |
|
@doc-sheet It does not automatically get the system one (/etc/resolve.conf) but you could parse that as suggested above. The name must be able to resolve post load of nginx. This change is very useful for me as it won't need a full restart when the web crashes |
|
I still do not find this useful, |
With this change, |
No, it doesn't. This will happen in next install which must restart nginx. Then it can be on forever while the other containers can crash or be restarted if problematic (trust me, I have to do it from time to time) |
@aminvakil I haven't seen this. It is not good practice to restart nginx, but I guess it might solve the issue sometimes... |
|
@aminvakil I don't thing yours is a good fix for #3894 Reading the last comment there you even acknowledge that your fix isn't really going to work (my guess is the restart mechanism of docker don't work well based on healthy status). I continue getting the error months after the "fix". Plus you may cause the connection drop |
But that is not really even working. I don't trust the restart mechanism of docker. If it did work, I wouldn't open this PR months later |
|
Well. Anyway. I will leave you guys to it. Please feel free to close this if you don't intend to pursue this route. Happy new year guys! Thank you for sentry! |
https://docs.docker.com/compose/how-tos/startup-order/
You're correct, Quoting myself from #3894 (comment):
When |
|
Oops! You had two other comments while I was writing mine :) We had this discussion before and decided not to go with |
This adds a DNS resolver for the web and relay container names so that Nginx can find them if they are restarted. This solves issues when these containers start before nginx eventually too.
The resolver uses the IP of the DNS of the docker daemon to be able to locate the hostnames.
Requires Nginx 1.27.3 or later. Currently this project runs 1.29, so we are fine.
Legal Boilerplate
Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.