Перезапуск Nginx без обрыва WebSocket соединений, реально?

Question

[Даша Циклаури]

Имеются следующие вводные:
CloudFlare
Кластер Docker Swarm
Nginx в роли reverse proxy
Go-app с веб-сокетами

В Nginx конфиге имеется несколько доменов, домены приходится добавлять. Сервис Nginx после редактирования конфигов рестартую, поскольку пересобираю образ.
После рестарта ws-соединения рвутся.

Есть ли способы решить вопрос на серверной стороне перезагрузки Nginx конфига без разрыва WebSocket соединений?
Не предлагайте способы реализовать это на клиенте

Comments

[Максим Федоров]

решение видимо будет -- разруливать не на уровне Nginx, а выше (DNS)... но подождем девопсов

[Lynn «Кофеман»]

Насколько я знаю в такой постановке (обязательный рестарт) никак.

[Даша Циклаури]

Алексей Тен, я правильно понимаю, что в данном контексте лучше все взаимодействие по ws выносить на отдельный домен? и если и приходится менять, то крайне редко?
k8s тут не поможет с ingress-nginx?

Answer 1

[Алексей Сундуков]

А почему restart nginx-а, а не reload?

Comments

[Vitaly Karasik]

насколько понимаю, reload тоже убьет websocket, так как он перезапускает nginx workers, только главный процесс продолжает бежать.

[Алексей Сундуков]

Vitaly Karasik, исходя из оф. доков старые будут продолжать работать https://nginx.org/ru/docs/control.html#reconfiguration
В любом случает стоит воспользоваться reload и посмотреть, что в итоге получиться.

[Vitaly Karasik]

Алексей Сундуков, Спасибо, вы правы! Честно говоря, я с самого начала хотел посоветовать reload (это то, что я помнил), но перед тем как ответить заглянул в доки и пропустил самую важную фразу "Старые рабочие процессы закрывают listen сокеты и продолжают обслуживать старых клиентов." И решил, что это я неправильно помнил.

[Даша Циклаури]

Алексей Сундуков, Nginx рестартуется по причине пересборки образа. В образ, который наследуется от базового nginx прокидываются конфиги и сертификаты.
- Зачем делать кастомный образ - спросите вы?
- Экземпляры работают в кластере, и изначально нет возможности на все ноды кластера ставить еще и кластеризованную ФС (какую-нибудь GlasterFS), в которой будут консистентно храниться конфиги, а далее нужно городить огород с обновлением/дожидаться пока файлы обновятся и только тогда перезапускать edge сервисы

[Алексей Сундуков]

Даша Циклаури, ну вы героически загоняете себя в угол и теперь пытаетесь перескочить забор который воздвигли. Вот прямо реально без кластера не обойтись? Сколько коннектов онлайт держиться?
Что мешает конфиги монтировать снаружи через volumes? А за их накатку и консистентность снаружи вполне себе может отвечать любая система управления конфигурациями в духе Puppet, Chef, Ansible, Saltstack.

[Даша Циклаури]

Алексей Сундуков, коннектов немного, чуть более тысячи, но заказчики разные под каждый домен и сейчас выходит, что каждый раз как я провожу манипуляции по добавлению нового или изменению конфига, то страдают все подключенные клиенты (а именно рвется сокет, и ничего более умного как рефреш страницы на такой случай пока не придумалось). Реализовать логику обрыва/ожидания/восстановления или финализацию сессии на сервере и клиенте за небольшие сроки у меня пока нет возможности.
Но спасибо - подумаю над puppet/zookeeper

[Алексей Сундуков]

Даша Циклаури, просто если времени мало, то нужно идти проверенным, а главное работающим методом. Конфиги выносим из контейнера под volumes. Потом даже без всяких puppet/zookeeper можно на коленке на bash написать примитивную обновлялку по ssh.

Answer 2

[Валентин]

Сервис Nginx после редактирования конфигов рестартую, поскольку пересобираю образ.

Получается, что решение проблемы - не пересобирать образ. В Kubernetes это всё крутится видимо? Нельзя просто для новых доменов запускать новый nginx, а старый не трогать, пусть обслуживает старых пользователей?

Comments

[Даша Циклаури]

крутится в Docker Swarm, но ситуация не меняется
для новых доменов новый nginx, - но ведь 443 порт уже занят

[Валентин]

Даша Циклаури, ну поэтому ты ставишь что-то, что на 443 порту, а оно редиректит дальше в разные nginx. В kubernetes так часто и есть - ставится ingress controller (и один из самых популярных - на базе nginx), на который приходит трафик из интернета. А тот в зависимости от домена редиректит на другой контейнер. И там дальше может быть вполне еще один nginx (если там например nginx + php приложение).

[Даша Циклаури]

Валентин, это все понятно, но как ты будешь редиректить на нужный nginx, если его еще нет в конфигурации? а если добавлять конфигурацию, то нужно сервис перезагружать

[Валентин]

Даша Циклаури, Схема такая: с интернета трафик приходит на nginx, который слушает 80 и 443 порты. У него весь конфиг по сути правила "такой домен - проксируй на такой адрес, другой домен - на другой" и т.п. Соответственно когда к нему добавляется в конфиг еще одна секция для очередного домена - ты делаешь релоад, а не рестарт ему. Т.е. ты собираешь контейнер с nginx с вебсокетами для одного домена, и запускаешь таких nginx'ов много - а перед ними ставишь nginx, который в зависимости от домена проксирует на тот или иной контейнер.

[Даша Циклаури]

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

[Валентин]

Даша Циклаури, ну я понял это все, потому и предлагаю поменять архитектуру так как выше описывал.

Answer 3

[Vitaly Karasik]

Сервис Nginx после редактирования конфигов рестартую, поскольку пересобираю образ.

Насколько понимаю, это нереально, и единственный вариант - это использовать несколько Nginx instances, и обновлять их по очереди: пометил Nginx как неактивный, дождался пока все сессии завершились, обновили. И т.д.
Насколько легко это сделать в Docker Swarm, не знаю.

Comments

[Даша Циклаури]

собственно так и происходит, в Swarm сделать очень просто через update/restart-delay и несколько реплик и restart-policy: start new then stop

[Vitaly Karasik]

Чтобы не прерывать WebSocket, нужно добавить еще ХХ минут ожидания после исключения контейнера из сервиса, перед update/restart-delay - для того чтобы дождаться чтобы все открытые на данном Nginx WebSocket завершились.

[Даша Циклаури]

Vitaly Karasik, все равно соединения рвутся же, просто будет быстрый реконнект
сессии держатся сзади на Го приложении, поэтому тут достаточно такой политики:
1) 2+ реплики
2) делаем старт новой, стоп старой
3) ждем 15-20 сек
4) повторяем для 2й и последующих

сварм сам сбалансирует если listener еще не слушает порт и не будет направлять туда трафик

короче видимо на клиенте да и сервере придется пересмотреть обрыв соединения на несколько секунд =(

[Vitaly Karasik]

В предлагаемом мной сценарии не рвутся, если мы ждем достаточно времени чтобы все клиенты которые открыли WebSocket на Nginx, закончили работу.