Mechanism to avoid restarting nginx upon every change

[Ajay Garg]

On Mon, Apr 10, 2017 at 1:04 PM, B.R. via nginx <nginx at nginx.org> wrote:

> 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/​
>

Thanks B.R., I surely will !!


> ---
> *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
>>
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>



-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170412/f522e2f6/attachment-0001.html>