у @zzz_sochi где-то был...

gunicorn не умеет в chain-reload, пусть и грейсфульно но грохает всех воркеров одновременно. а воркеры по пол секунды вармятся. Кто-нибуть подскажет, какую магию накастовать что бы код по воркерам поочереди расползался в конце ci/cd?

можно пнуть несколько gunicorn мастеров и по очереди тушить, но это надо nginx+

воткнуть балансер между nginx и юникорнами?

Мы сразу выкинули gunicorn, делали воркеры под supervisord, а сейчас и его выкинули в пользу системных сервисов (у нас фря и rc, но модный systemd тоже годится). Перед всем этим стоит nginx, который балансит апстримы. Грейсфул происходит так: выставляется в health check ендпонит, который обслуживается исключительно nginx-ом, флаг да/нет. Если нет, то отдается 503 ответ вместо 200, что выбрасывает тачку из пула внешнего балансера. Дальше можно идти и спокойно всех ребутать в любом порядке. По окончанию флип флага обратно, чтобы балансер вернул тачку в апстрим.  И процесс тот же CI/CD - такие действия происходят сначала с канарейкой, а потом с каждой парой тачек (специфика).

Я в этой схеме недопонимаю как nginx делает health check. Вот я поставил флажок False у половины воркеров. Дальше надо ждать пока придет nginx и дернет за флажок, только после этого можно помирать?

Грамотно. gunicorn вижу только на небольших инсталяциях, а supervisord да, многие используют, это сравнительно простой и быстрый варик.

Но вообще я уже нашел в исходниках (а затем и глубоко в доке) сигнал USR2 у гуникорна

а чем gunicorn не угодил? а то мы сидим с ним много лет и непонимаем что он какашка

Да, там будет время ожидания пока балансер среагирует. Это секунд 5-10 в реале. Как делать - для того же nginx есть разные модули проверки доступности апстримов.

https://github.com/yaoweibin/nginx_upstream_check_module/ - например.

кажется, у нас такой используется.

Нам он не угодил, что там нельзя конкретный воркер опросить на тему что с тобой не так или какие твои метрики. На этом всё.

да номральный он, просто от потребностей приложения зависит, у него один мастер процесс управляет воркерами жеж (pre-fork) как и сборка великого apache mpm perfork. Это типа достаточно секьюрный подход, но он жрёт больше ресурсов.

Сейчас ресурсов вроде у всех хватает, по этому уже по сути пофиг. Имеют значения только отдельные особенности, к примеру, о которых написал Александр.

ребят, на Вездекод есть желание у кого-то поучаствовать?

собираешь тусу покататься по тундре?

:)