ダウンタイムなしのNginx構成の再読み込み

123

私はnginxをリバースプロキシとして使用しています。を使用して構成を更新するたびに

sudo "cp -r #{nginx_config_path}* /etc/nginx/sites-enabled/"
sudo "kill -s HUP `cat /var/run/nginx.pid`"

短いダウンタイムに直面しています。どうすればそれを回避できますか？

nginx

— サウラヴ・シャー
ソース

1

それらはコマンドラインコマンドを意図していますか？そのような引用符でsudoコマンド全体をラップする人は誰もいません。それは必要ではないかもしれません。

— ブライアンマーンズ

4

単なる一般的なコメント：標準/推奨されるプラクティスはsites-enabled、コピーではなく、サイト構成のソフト/シンボリックリンクを作成することだと思います。特定の問題とは関係ありませんが、調査することをお勧めします。

— ブライアンマーンズ

1

ダウンタイムに直面してはいけません。kill HUPnginxでグレースフルリロードを行う方法です。

— ジョナサンヴァナスコ

180

実行service nginx reloadまたは/etc/init.d/nginx reload

ダウンタイムなしで構成のホットリロードを実行します。保留中のリクエストがある場合、それらの接続が終了する前に処理するnginxプロセスが残っているため、設定をリロードする非常に優雅な方法です。

時には、 sudo

— ヘンジー
ソース

10

両方とも、質問の状態を正確に実行する必要がありますSIGHUP。nginxマスタープロセスに送信します。違いはないはずです。nginx.org/en/docs/control.html

— Gnarfoz

CentOSでコマンドを発行すると、「Usage /etc/init.d/nginx（start..stop ... restart..reload）」と表示され続けます。これがまさに使用方法です。/init.d/nginxファイル内で、kill -HUP cat $PIDFILE||が見つかりました。echo -n "リロードできません"

— マッシュアップ

1

あなたは違いが間にあるものを知っているかservice nginx reloadとnginx -s reload？前者を実行すると、次の出力Reloading nginx configuration: nginx.が表示されます：が、変更は更新されません。後者を実行した場合、出力は得られませんが、変更は反映されます。

— ライアンクイン

log_not_foundディレクティブを追加してからこれを試しましたが、実際に再起動して動作させる必要があることがわかりました。再ロードはすべてのディレクティブで機能しないと思いますか？

— mydoghasworms

81

走る /usr/sbin/nginx -s reload

コマンドラインオプションの詳細については、http：//wiki.nginx.org/CommandLineを参照してください。

— シヴ・クマール・サー
ソース

最後に、Debian Jessieで機能するコマンド。

— danger89

1

これはより良い方法です。構成にエラーがある場合にサーバーがダウンしないため（この場合はエラーを表示するだけです）。

— ミールイ

nginxのデフォルトpidがデフォルトの場所にない場合、「-p」が必要です。例： `/ opt / gitlab / embedded / sbin / nginx -s reload -p / var / opt / gitlab / nginx`

— qxo

9

いいえ、あなたは間違っています。説明する手順でダウンタイムに直面することはないはずです。（Nginxは、ダウンタイムなしで実行中に構成を再読み込みできるだけでなく、ダウンタイムなしで実行可能ファイルのアップグレードも実行できます。）

あたりとしてhttp://nginx.org/docs/control.html#reconfiguration、送信HUP「nginxのに信号することは、グレースフルリスタートを実行することを確認します、そして、コンフィギュレーションファイルが正しくない場合、手順全体が放棄され、そしてあなたHUP信号を送信する前と同じように、nginxを再度使用します。いかなるダウンタイムも可能であってはなりません。

nginxが構成ファイルを再度読み取るには、HUPシグナルをマスタープロセスに送信する必要があります。マスタープロセスは、最初に構文の妥当性をチェックしてから、新しい構成を適用しようとします。つまり、ログファイルと新しい待機ソケットを開きます。これが失敗した場合、変更をロールバックし、古い構成で引き続き動作します。

— cnst
ソース

2

通常、サービスの構成ファイルを再ロードしても、実行中のサービスに影響はありません。ただし、これはSIGHUP信号の処理方法によって異なります。

特定のサービスがリロード中にダウンタイムを経験している場合、できればロードバランサーを使用して、複数のサーバーで同じサービスを実行することでこれを回避できます。この場合、一度に1台のサーバーを取り出して、リロード/再起動できます。その後、問題がないことを確認してから、再度追加できます。

— カレド
ソース

これは質問に直接答えませんが、これは間違いなくベストプラクティスのシナリオであり、一般にダウンタイムを回避するためにOPが従うのが賢明です。

— アンドリューM.

1

：nginxのは、異なる信号を処理する方法の詳細nginx.org/en/docs/control.html

— Gnarfoz