Перезавантаження конфігурації Nginx без простоїв

122

Я використовую nginx як зворотний проксі. Кожен раз, коли я оновлюю конфігурацію для цього, використовуючи

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

Я стикаюся з коротким простоєм. Як я можу цього уникнути?

nginx

— Саурав Шах
джерело

1

Це призначені для команд командного рядка? Я ніколи не бачив, щоб хтось загортав цілу команду sudo в такі лапки, це може не знадобитися.

— brianmearns

4

Лише загальний коментар: Я думаю, що стандартною / рекомендованою практикою є створення м'якого / символічного посилання для конфігурації вашого сайту sites-enabled, а не копіювання. Не пов’язано з вашим конкретним питанням, але ви можете розглянути це.

— brianmearns

1

Ви не повинні стикатися з простоєм. kill HUPце спосіб зробити витончене перезавантаження в nginx.

— Джонатан Ванаско

181

Виконати service nginx reloadабо/etc/init.d/nginx reload

Це зробить гаряче перезавантаження конфігурації без простоїв. Якщо у вас є запити, що очікують на розгляд, тоді будуть тривати процеси nginx, які будуть обробляти ці з'єднання, перш ніж вони вмирають, тому це надзвичайно витончений спосіб перезавантажити конфігури.

Іноді, можливо, вам захочеться поповнитися sudo

— Хенджі
джерело

10

І те й інше повинно робити саме те, що йдеться в запитанні: надіслати SIGHUPв nginx основний процес. Різниці не повинно бути. nginx.org/uk/docs/control.html

— Gnarfoz

Коли я видаю команду на CentOS, вона продовжує говорити "Використання /etc/init.d/nginx (start..stop ... restart..reload)" .. і саме так я її використав. У файлі /init.d/nginx я знайшов kill -HUP cat $PIDFILE|| echo -n "не вдається перезавантажити"

— mashup

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.

— небезпека89

1

Це кращий спосіб. Оскільки ваш сервер не виходить з ладу, якщо у ваших конфігураціях є помилки (у цьому випадку просто відображаються помилки).

— Мир-Ісмаїлі

якщо pgin nginx за замовчуванням не знаходиться у типовому місці, знадобиться '-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 гарантує, що він виконує витончений перезапуск, і, якщо файли конфігурації невірні, вся процедура припинена, і ви ' знову залишилося з nginx, як і перед відправленням HUPсигналу. Ні в якому разі не може бути можливим час простою.

Для того, щоб nginx перечитав файл конфігурації, сигнал HUP повинен бути відправлений до головного процесу. Основний процес спочатку перевіряє правильність синтаксису, потім намагається застосувати нову конфігурацію, тобто відкрити файли журналів та нові розетки прослуховування. Якщо це не вдалося, він відкидає зміни та продовжує працювати зі старою конфігурацією.

— cnst
джерело

2

Зазвичай файл завантаження конфігурації послуги не повинен впливати на працюючу службу. Однак це залежить від того, як SIGHUPобробляється сигнал.

Якщо певна служба відчуває час простою під час перезавантаження, це можна уникнути, запустивши одну і ту ж службу на декількох серверах, бажано, використовуючи балансир завантаження. У цьому випадку ви можете одночасно вийняти один сервер і перезавантажити / перезапустити його. Потім його можна буде знову додати після підтвердження, що це все в порядку.

— Халед
джерело

Хоча це не відповідає безпосередньо на запитання, це, безумовно, найкращий сценарій практики, якого ОП доцільно слідкувати, щоб уникнути простоїв взагалі.

— Ендрю М.

1

Детальніше про те, як nginx обробляє різні сигнали: nginx.org/en/docs/control.html

— Gnarfoz