Skip to content

Conversation

@inoa-jboliveira
Copy link

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.

proxy_read_timeout 30s;
proxy_send_timeout 5s;

resolver 127.0.0.11 valid=30s;
Copy link
Collaborator

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.

Copy link
Author

@inoa-jboliveira inoa-jboliveira Dec 22, 2025

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

@doc-sheet
Copy link
Contributor

Just a reminder that nginx resolves things at startup. You need to reload it on IP change or use variables.
I don't know if it works with upstream block but for a simple proxy_pass you have to use tricks like

set $domain web;
proxy_pass http://$domain;

@doc-sheet
Copy link
Contributor

Oh, I didn't see 1.27.3 change. Nice.

@inoa-jboliveira
Copy link
Author

@doc-sheet
The resolver change require an explicit DNS host which for docker is what I implemented.

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

@aminvakil
Copy link
Collaborator

I still do not find this useful, nginx container shall be restarted in case relay or web gets restarted after #3914 got merged and it will use new IP address (if it has been changed) anyway.

@aminvakil
Copy link
Collaborator

This change is very useful for me as it won't need a full restart when the web crashes

With this change, nginx gets restarted anyway.

@inoa-jboliveira
Copy link
Author

With this change, nginx gets restarted anyway.

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)

@inoa-jboliveira
Copy link
Author

I still do not find this useful, nginx container shall be restarted in case relay or web gets restarted after #3914 got merged and it will use new IP address (if it has been changed) anyway.

@aminvakil I haven't seen this. It is not good practice to restart nginx, but I guess it might solve the issue sometimes...

@inoa-jboliveira
Copy link
Author

inoa-jboliveira commented Dec 31, 2025

@aminvakil
Yeah, looking at it you may create way more problems restarting nginx if relay or web die. Because it may drop healthy connections.

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

@inoa-jboliveira
Copy link
Author

I still do not find this useful, nginx container shall be restarted in case relay or web gets restarted after #3914 got merged and it will use new IP address (if it has been changed) anyway.

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

@inoa-jboliveira
Copy link
Author

Well. Anyway. I will leave you guys to it.
I fixed on my local install and I'm happy.

Please feel free to close this if you don't intend to pursue this route.

Happy new year guys! Thank you for sentry!

@aminvakil
Copy link
Collaborator

With this change, nginx gets restarted anyway.

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)

https://docs.docker.com/compose/how-tos/startup-order/
#3914 (comment)

I still do not find this useful, nginx container shall be restarted in case relay or web gets restarted after #3914 got merged and it will use new IP address (if it has been changed) anyway.

@aminvakil I haven't seen this. It is not good practice to restart nginx, but I guess it might solve the issue sometimes...

@aminvakil Yeah, looking at it you may create way more problems restarting nginx if relay or web die. Because it may drop healthy connections.

I don't thing yours is a good fix for #3894

You're correct, Quoting myself from #3894 (comment):

#3914 ensures nginx gets restarted in case relay and / or web get restarted.

It's an improvement IMO, but it does not fix the real problem.

When relay or web container is down, self-hosted does not work anyway, so there is no healthy connection, but it should not happen at all, if it does there is another critical problem which should not be fixed with nginx getting restarted or adding resolver to its config, and so on.

@jerbob92 Was #3914 helpful in your self-hosted instance?

@aminvakil
Copy link
Collaborator

Oops! You had two other comments while I was writing mine :)

We had this discussion before and decided not to go with resolver, as OP's local installation is working and happy with it, I'm going to close this.

@aminvakil aminvakil closed this Dec 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

3 participants