Hello,

Thanks for the explanation. I will look into the options what we have at
this point.

On Tue, Dec 15, 2020 at 3:27 AM Francis Daly <francis@daoine.org> wrote:

> 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 francis@daoine.org
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>


--


*Regards,*


*K S Praveen Kumar*
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx