Спасибо всем, но в целом системного уровня решения понятны. Проблема в том,
что redeploy может произойти и бесконтрольно - после ребута сервера
приложения, например, или в случае крэша приложения.
Есть ли решение на уровне nginx? Может, какая-ть волшебная директива
proxy_first_byte_read_timeout?
Привет всем,
Каким образом можно корректно работать с tomcat-upstream, который
используется для java-приложения, deploy которого занимает несколько минут?
Среда:
На входе стоит nginx proxy, в котором настроено n апстримов в режиме
round-robin с max_fail=1. За ним - n серверов приложений, на
On Tuesday, October 28, 2014 10:31:11 PM Никита Кардашин wrote:
Привет всем,
Каким образом можно корректно работать с tomcat-upstream, который
используется для java-приложения, deploy которого занимает несколько минут?
Среда:
На входе стоит nginx proxy, в котором настроено n апстримов в
Hello!
On Tue, Oct 28, 2014 at 10:31:11PM +0500, Никита Кардашин wrote:
Привет всем,
Каким образом можно корректно работать с tomcat-upstream, который
используется для java-приложения, deploy которого занимает несколько минут?
Среда:
На входе стоит nginx proxy, в котором настроено n
28 октября 2014 г., 20:31 пользователь Никита Кардашин megal...@gmail.com
написал:
Привет всем,
Каким образом можно корректно работать с tomcat-upstream, который
используется для java-приложения, deploy которого занимает несколько минут?
Среда:
На входе стоит nginx proxy, в котором
Помечать неработающие бекенды как down - nginx reload - deploy -
убираем down - nginx reload
И так на всех фронтах...
Решение с добавлением блокировки через файрвол в процедуру деплоя выглядит
несколько более простым.
только надо проследить, чтобы блокировка не DROP, а REJECT (в терминах
28 октября 2014 г., 22:17 пользователь Daniel Podolsky onoko...@gmail.com
написал:
Помечать неработающие бекенды как down - nginx reload - deploy -
убираем down - nginx reload
И так на всех фронтах...
Решение с добавлением блокировки через файрвол в процедуру деплоя выглядит
несколько