Как обновить внутреннее состояние исполняемого модуля модуля nginx?

Предположим, я хочу написать модуль nginx, который блокирует клиентов по IP. Для этого на этапе инициализации я прочитал файл с IP-адресами , который должен заблокировать (черный список) и сохранить его в контексте модуля.Как обновить внутреннее состояние исполняемого модуля модуля nginx?

Теперь я хочу обновить черный список без перезапуска nginx. Одним из возможных решений является добавление обработчика в определенное место. , например. если запрашивается uri "/block/1.2.3.4", мой обработчик добавляет ip адрес 1.2.3.4 в черный список.

Однако nginx запускает несколько рабочих как разделенные процессы, поэтому обновляется только один конкретный работник.

Что такое общий шаблон для решения таких проблем?

источник

2017-02-03 Boris T

Можете ли вы переместить черный список за пределы контекста модуля? Возможно, к системному файлу, магазину KV или SHM? Это позволит каждому процессу разговаривать с черным списком центрального источника. – avip

Но тогда мне нужен механизм синхронизации, чтобы получить доступ к этой общей памяти. Это может замедлить работу всей системы. –

Да, но я верю, что 'shmat()' и futex выполнит эту работу, и накладные расходы будут незначительными. – avip

Если вы можете переместить черный список вне контекста модуля, возможно, в системный файл, хранилище KV или SHM, что позволит каждому процессу разговаривать с центральным исходным черным списком. Я считаю, что shmat() и futex будут выполнять эту работу, и накладные расходы будут незначительными.

источник

2017-02-13 03:41:17 avip

Но nginx не требует перезагрузки (или бездействия), чтобы изменить конфигурацию!

См:

http://nginx.org/en/docs/control.html#reconfiguration

Для того, чтобы Nginx повторно прочитать файл конфигурации, сигнал HUP должен быть направлен в основном процессе. Мастер-процесс сначала проверяет достоверность синтаксиса, затем пытается применить новую конфигурацию, то есть открыть файлы журналов и новые сокеты для прослушивания. Если это не удается, оно отменяет изменения и продолжает работать со старой конфигурацией. Если это удается, оно запускает новые рабочие процессы и отправляет сообщения старым рабочим процессам с просьбой закрыть их изящно. Старые рабочие процессы закрывают сокеты и продолжают обслуживать старых клиентов. После обслуживания всех клиентов старые рабочие процессы завершаются.

Как администратор, я ожидал, что все модули будут, таким образом, контролироваться таким же образом.

(Конечно, если вам требуется много изменений в конфигурации очень часто, другое решение может быть более подходящим.)

Вы даете явный пример блокировки доступа по IP. Вы уверены, что для выполнения задачи требуется новый модуль? Казалось бы, что сочетание следующих стандартных директив может быть достаточно уже:

источник

2017-02-11 19:58:52 cnst

Как обновить внутреннее состояние исполняемого модуля модуля nginx?

ответ

Смежные вопросы