Includes dynamic proxy_pass definition to make NGINX refresh the DNS lookup #723
Conversation
pedrovivaldi
added
the
team - TR
✅ Deploy Preview for support-docs ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
| Note: we need to set the `proxy_pass` directive with a variable so the ip address of the domain will be looked up | ||
| dynamically and result will be cached for 5 minutes. Otherwise, it would be only looked up at server startup |
There was a problem hiding this comment.
Can you please reword this to:
Note: you must store spgo.io in a variable so that nginx re-resolves the domain when its TTL expires.
I believe that you also need to include the resolver directive when using this method [1]. Please check me on that.
[1] https://www.nginx.com/blog/dns-service-discovery-nginx-plus/
There was a problem hiding this comment.
"Parameter value can contain variables. In this case, if an address is specified as a domain name, the name is searched among the described server groups, and, if not found, is determined using a resolver" [1]
Without the resolver, we get no resolver defined error during tests
[1] https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass
Some other articles:
There was a problem hiding this comment.
There's another NGINX config snippet later in this document that we need to update, too.
| Note: you must store `spgo.io` in a variable so that nginx re-resolves the domain when its TTL expires. You also have to include the `resolver` directive to explicitly specify a DNS server to resolve the hostname. By including the `valid` parameter to the directive, you can tell nginx to ignore the TTL and to re‑resolve names at a specified frequency. In the sample below, nginx re‑resolves names every 10 seconds. | ||
|
|
||
| ```apacheconf | ||
| resolver 10.0.0.2 valid=10s |
There was a problem hiding this comment.
We're missing a semicolon here
approved
What Changed
How To Test or Verify
PR Checklist
Below are some checklists to follow for the correct procedure in different circumstance. The first list ("All PRs Checklist") should be followed for ALL PRs. The next 2 are additive to this list depending on what type of PR you are using.
For example: If you are submitting a content change to one of the support documents, your checklist would include the:
If you are submitting a feature addition, enhancement, or bug fix, your checklist would include the:
All PRs Checklist
team-FEorteam-SAZ)Content Changes Checklist
examples/article.mdin the root of the project directory and on the momentum doc's preface articleDevelopment Changes Checklist (some checks are automatic github actions and will not be listed here. ie. "all tests pass")
cypress/directory in the root of the project