Lets suppose I wish to write a nginx module that blocks clients by IP. In order to do so, on initialization stage i read a file with IP addresses that I have to block (black list) and store it in module's context.
Now I wish to update the black list without restarting nginx. One of the possible solutions, is to add a handler on specific location. e.g. if uri "/block/1.2.3.4" requested, my handler adds ip address 1.2.3.4 to the black list.
However, nginx runs several workers as separated processes, so only one particular worker will updated.
What is a common pattern to cope such problems?
1 Answers
Answers 1
But nginx does not require a restart (nor any downtime) in order to change the configuration!
See:
In order for nginx to re-read the configuration file, a HUP signal should be sent to the master process. The master process first checks the syntax validity, then tries to apply new configuration, that is, to open log files and new listen sockets. If this fails, it rolls back changes and continues to work with old configuration. If this succeeds, it starts new worker processes, and sends messages to old worker processes requesting them to shut down gracefully. Old worker processes close listen sockets and continue to service old clients. After all clients are serviced, old worker processes are shut down.
As an administrator, it would be my expectation that all modules would, in fact, be controlled in this way, too.
(Of course, if you require a lot of changes to the configuration very often, a different solution might be more appropriate.)
You give an explicit example of blocking access by IP. Are you sure you require a new module in order to accomplish the task? It would seem that a combination of the following standard directives might suffice already:
- http://nginx.org/r/deny && http://nginx.org/r/allow
- http://nginx.org/r/geo
- http://nginx.org/r/map
- http://nginx.org/r/if && http://nginx.org/r/return
0 comments:
Post a Comment