On Mon, Dec 14, 2020 at 06:57:50PM +0530, Praveen Kumar K S wrote:
Hi there,
> 1. nginx fails to start when an upstream server is down or not being
> resolved.
"nginx fails to start when an upstream server is down" is not the
expected behaviour.
"nginx fails to start when an upstream server name is not being resolved"
is the expected behaviour.
If you have a reproducible case of the first without the second, that
will probably be a useful bug report.
> 2. I can't use the ipaddress because I'm running all services in docker
> swarm. So I can only resolve using the service names.
That's a valid setup for your use case.
Stock-nginx does not work in those circumstances, if the upstream service
names do not resolve when nginx starts.
(Also: I think that stock-nginx will not try to re-resolve the names
while it is running; so giving it "dummy" information at startup and
changing it later, will not work.)
> 3. Now I get your point. When nginx starts, it should resolve all upstream
> servers. Else, it will fail to start.
Correct.
> Now, let me explain my issue. Please let me know if this is possible.
> 1. Today I have 3 servers defined in upstream. Lets say app1,app2,app3
> 2. Tomorrow I might scale the app by 2 more. Lets say app4,app5
> 3. Now I want to define that [app4,app5] in my nginx configuration
> 4. But I thought of defining app1,2,3,4,5 upfront in nginx conf and scale
> my app whenever required. In this case, when nginx is unable to resolve
> app4,5, it should ignore and when I scale my app, it should load balance
> the requests to all 5.
Step 4 is not a thing that stock-nginx can do today.
You could potentially define your "upstream" to only include the servers
that resolve today; and then tomorrow change it to only include the
servers that resolve tomorrow, and invite nginx to re-read its config
file ("reload" rather than "restart").
Or you could potentially define your "upstream" with all 5 names if you
know the IP addresses that they will have when they are running, and
let nginx load-balance across whichever services are "up" at each time.
Maybe you can find or write an external module that can get nginx to do
what you want?
The documentation for "upstream" is at http://nginx.org/r/upstream
On that page, there are also mentions of some dynamic features that are
not available in stock nginx, but which are available in a commercial
subscription. Depending on your requirements, that may or may not be
a useful path to investigate. The fact that "dynamic configuration"
code exists proves that it can be written, which might be inspiration
to re-implement it, or to take advantage of what others have already done.
Good luck with it,
f
--
Francis Daly fran...@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
