Добрый день,
> Подводные камни очень простые: сокет один, поэтому его настройки
> обязаны совпадать в разных виртуальных серверах. Соответственно
> нужно либо разрешать указывать опции сокета только в одном месте,
> либо проверять, что они таки совпадают. Если же просто давать
> пользователям указывать что попало - они начинают указывать разные
> настройки в разных блоках server{} и удивляться, почему они таки
> не оказываются разными.
Ну в нашем случае нам как раз подходит указать везде reuseport явно,
чтобы он работал всегда. Указывать только в одном месте очень неудобно
для автоматического конфигурирования.

> помечайте одну пару IP:PORT как default и на нее вешайте подобные опции.
> таким же свойством обладает еще accept_filter
Это не очень как раз удобно, потому что проще накатывать конфиг по
шаблону, с включенными опциями сразу(как в случае с ssl/http2), чем
перед этим парсить все конфиги и проверять есть ли уже такой IP адрес и
есть ли там опции(тоже вариант решения проблемы, но мне он нравится пока
меньше).


Спасибо, Максим, попробую тогда поковыряться в исходниках, задача
выглядит не супер сложной. Как что-то получится, отпишусь.

On 05.04.2016 22:12, Илья Шипицин wrote:
> помечайте одну пару IP:PORT как default и на нее вешайте подобные опции.
> таким же свойством обладает еще accept_filter
>
> с другой стороны, http2, например, можно навешать на произвольное
> количество пар IP:PORT
>
> 5 апреля 2016 г., 14:14 пользователь navern <livingdeadzerg@yandex.ru
> <mailto:livingdeadzerg@yandex.ru>> написал:
>
> Добрый день,
>
> Недавно появилась возможно указывать reuseport и это очень удобная
> штука, которой мы уже пользуемся.
>
> Правда есть проблема:
> Для одной пары IP:PORT можно указывать эту опцию только один раз,
> что очень сильно усложняет конфигурацию, особенно автоматическую.
> Для ssl и прочих опций такой проблемы нет.
>
> В общем это не очень удобно.
>
> Из того, что пришло в голову: убрать проверку в конфиге на
> несколько reuseport для одной пары IP:PORT.
>
> Кто-то уже подобное что-то делал? Порекомендует куда посмотреть и
> какие подводные камни могут быть? Пока еще проблема на стадии
> осмысления и возможно здравые идеи помогут избежать долгого
> втыкания в исходники:) Заранее спасибо.
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru