Mechanism to avoid restarting nginx upon every change

B.R. reallfqq-nginx at yahoo.fr
Mon Apr 10 07:34:13 UTC 2017


You could have got your answer yourself by Reading The... Fine? Manual:
https://nginx.org/en/docs/control.html

There are tons of interesting pieces of informations there, by the nature
of said docs...
​I suggest you take a look at everything: https://nginx.org/en/docs/​
---
*B. R.*

On Sun, Apr 9, 2017 at 4:25 PM, Ajay Garg <ajaygargnsit at gmail.com> wrote:

> Thanks a ton Lucas.
>
> Just checked reloading, and the previous proxy-session was intact !!
> Thanks a ton again.
>
> And sorry I missed your name in the credits, you too had helped a greate
> deal yesterday, and today too !!
> Thanks a ton again !!!
>
>
> Thanks and Regards,
> Ajay
>
> On Sun, Apr 9, 2017 at 7:29 PM, Lucas Rolff <lucas at lucasrolff.com> wrote:
>
>> Hi Ajay,
>>
>> If you generate the configuration, and issue a nginx reload – it won't
>> cause any downtime. The master process will reread the configuration, start
>> new workers, and gracefully shut down the old ones.
>> There's absolutely no downtime involved in this process.
>>
>>
>> From: nginx <nginx-bounces at nginx.org> on behalf of Ajay Garg <
>> ajaygargnsit at gmail.com>
>> Reply-To: "nginx at nginx.org" <nginx at nginx.org>
>> Date: Sunday, 9 April 2017 at 15.55
>> To: "nginx at nginx.org" <nginx at nginx.org>
>> Subject: Mechanism to avoid restarting nginx upon every change
>>
>> Hi All.
>>
>> We are wanting to implement a solution, wherein the user gets proxied to
>> the appropriate local-url, depending upon the credentials.
>> Following architecture works like a charm (thanks a ton to
>> francis at daoine.org, without whom I would not have been able to reach
>> here) ::
>>
>> ####################################################
>> server {
>>                 listen 2000 ssl;
>>
>>                 ssl_certificate /etc/nginx/ssl/nginx.crt;
>>                 ssl_certificate_key /etc/nginx/ssl/nginx.key;
>>
>>                 location / {
>>                                         auth_basic 'Restricted';
>>                                         auth_basic_user_file
>> /etc/nginx/ssl/.htpasswd;
>>
>>                                         if ($remote_user =  "user1") {
>>                                                 proxy_pass
>> https://127.0.0.1:2001 <https://127.0.0.1:2000>;
>>                                         }
>>
>>                                         if ($remote_user =  "user2") {
>>                                                 proxy_pass
>> https://127.0.0.1:2002 <https://127.0.0.1:2000>;
>>                                         }
>>
>>                                        # and so on ....
>>
>>                 }
>>          }
>> ####################################################
>>
>>
>> Things are good, except that adding any new user information requires
>> reloading/restarting the nginx server, causing (however small) downtime.
>>
>> Can this be avoided?
>> Can the above be implemented using some sort of database, so that the
>> nginx itself does not have to be down, and the "remote_user <=> proxy_pass"
>> mapping can be retrieved from a database instead?
>>
>> Will be grateful for pointers.
>>
>>
>> Thanks and Regards,
>> Ajay
>>
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>
>
> --
> Regards,
> Ajay
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170410/d5d36ba9/attachment.html>


More information about the nginx mailing list