2017-02-03 7 views
5

クライアントをIPでブロックするnginxモジュールを作成したいとします。 これを行うには、初期化段階で私はIPアドレスが (ブラックリスト)をブロックしてモジュールのコンテキストに格納するファイルを読み込みます。nginxのモジュールランタイムの内部状態を更新するには?

これで、nginxを再起動せずにブラックリストを更新したいと考えています。 可能な解決策の1つは、特定の場所にハンドラを追加することです。例: uri "/block/1.2.3.4"が要求された場合、私のハンドラはIPアドレス1.2.3.4をブラックリストに追加します。

しかし、nginxは複数のワーカーを分離したプロセスとして実行するため、特定のワーカーのみが更新されます。

このような問題に対処する共通のパターンは何ですか?

+1

ブラックリストをモジュールのコンテキスト外に移動できますか?おそらく、システムファイル、KVストア、またはSHMに?これにより、各プロセスが中央のソースブラックリストと対話できるようになります。 – avip

+0

しかし、私はこの共有メモリにもアクセスするための同期メカニズムが必要です。これにより、すべてのシステムが遅くなる可能性があります。 –

+0

はい、私は 'shmat()'と信じていますが、futexはその仕事を行い、オーバーヘッドは無視できます。 – avip

答えて

0

ブラックリストをモジュールのコンテキストの外に、おそらくシステムファイル、KVストア、またはSHMに移動することができれば、各プロセスが中央のソースブラックリストと対話できるようになります。私はshmat()とfutexが仕事をし、オーバーヘッドは無視できると信じています。

3

しかし、nginxは設定を変更するために再起動(または停止時間も)を必要としません!

参照:

nginxの設定ファイルを再読み込みするためには、HUP信号がマスター・プロセスに送信されるべきです。マスタープロセスはまず、構文の妥当性をチェックし、新しい設定を適用しようとします。つまり、ログファイルと新しい聴取ソケットを開きます。これに失敗した場合は、変更をロールバックして古い構成で作業を続けます。これが成功すると、新しいワーカープロセスが開始され、正常にシャットダウンするように要求する古いワーカープロセスにメッセージが送信されます。古い作業者はソケットを閉じて古いクライアントにサービスを提供し続けます。すべてのクライアントがサービスされた後、古いワーカープロセスはシャットダウンされます。

管理者として、実際にはすべてのモジュールがこのように制御されると私は期待しています。

(あなたは非常に頻繁に構成の変更の多くを必要とする場合もちろん、別の解決策がより適切かもしれません。)


あなたはIPによるアクセスをブロックする明示的な例を与えます。あなたは、タスクを達成するために新しいモジュールが必要ですか?次の標準ディレクティブの組み合わせが既に十分かもしれないと思われる:


関連する問題