Обновить

Комментарии 14

Главное не забывать первопричину популярности nginx - скорость и легкость. Меня всегда настораживает разбухание чего-либо от мало кому нужных фич.

Так всё модульное. Если какие-то модули не требуются, то можно их не собирать, но смысла в этом большого нет, т.к. влияние на производительность от наличия модуля в сборке - чаще всего неизмеримо мало. Мы динамически собираем в основном те модули, которые устанавливают дополнительные зависимости.

Но вообще на разработку "мало кому нужных фич" нет времени. Количество запросов от сообщества сильно больше, чем ресурсов. Плюс технологии развиваются и конкуренты тоже. Если ничего не делать, то какое-то время можно за счет запаса инерции оставаться в тренде, но рано или поздно уйдешь на задворки истории. Естественно никто не будет делать ту или иную фичу по одному-двум запросам - разработка вообще дорогая, поэтому это возможно только на коммерческой основе.

Тут в оценках главное не впадать в субъективизм. Когда работаешь в одной/нескольких компаниях, то имеешь определенное представление о том, что нужно и что не нужно в рамках кейсов, с которыми сам сталкивался. А когда работаешь в вендоре ПО, будь то NGINX, Inc. ранее и теперь Angie Software - то имеешь дело с тысячами компаний и их кейсами, которые зачастую богаче всех твоих фантазий.

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

P.S. Но вообще, если хочется ставший в какой-то степени каноничным nginx, который существовал с 2011 по 2022 год, то порекомендую freenginx, который разрабатывается Максимом Дуниным. Долгие годы без его одобрения в nginx не попадало ничего, а когда в F5 на его мнение решили наплевать, то ему пришлось сделать свой форк. У нас с ним разные взгляды на развитие, но желаю Максиму успехов. Какие-то полезные изменения мы в том числе портируем из freenginx и за это ему большое спасибо, что неустанно продолжает своё дело.

Так, подождите, про письмо от ПОДДЕРЖКИ ХАБРА - это вы серьезно? ЧИВО БЛИН?!

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

P.S. Как по мне, то просто даже сама формулировка про "ошибочное представление, что продукты кому-то интересны" и "кружок с предвзятыми оценками" - это откровенное хамство.

@Boomburum жесть конечно ваши коллеги ущербно себя ведут.

Так, ну тут однозначно придётся провести воспитательную беседу, такого общения быть не должно ( Даже если кто-то из пользователей вёл себя недобросовестно и вывел на эмоции (как иногда бывает). Спасибо, что подсветили этот момент!

BTW адрес получателя какой-то странный

А в чем вообще смысл пользоваться nginx-подобными продуктами в 2k25, кроме как "наши сисадмины отстали от жизни и не могут настроить envoy или хотя бы traefik"?

Оно когда-то было хорошо, конечно, во времена Апача и cgi на перле, но в чём смысл держаться за это сейчас?

Или весь вопрос в наличии справки о разрешённости разрешения?

Например потому, что nginx-подобные продукты во многом лучше. И уж точно производительнее и устойчивее к пиковым нагрузкам, чем тот же Traefik. Не стоит так оголтело записывать админов большей части интернета и крупнейших компаний мира в "отставшие от жизни".

Разумеется у Traefik и Envoy есть свои плюсы. Все разработчики друг на друга смотрят и многие полезные фичи перенимают. Тут нет никакого однозначного лидера, но есть разные подходы и предпочтения в цвете фломастера.

Что полезного есть в envoy или хотя бы traefik, чего нет в nginx?

Мммм, даже не знаю.

Может быть нормальная динамическая конфигурация, а не reload&pray с "сейчас я буду рвать все вебсокеты"?
Может быть нормальные политики управления трафиком на L7, с ретраями, circuit breaker'ами, и прочей прелестью, которые можно просто сконфигурить и оно будет работать?
Или это отсутствие странных сюрпризов, вроде того, что при любом матче локации nginx ходит в файловую систему, даже если в локации нет ничего кроме proxy_pass?
Может быть автодискавери сервисов? Система плагинов и фильтров без "а давайте мы просто всунем код на луа вот прямо сюда"?

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

Может быть нормальная динамическая конфигурация, а не reload&pray с "сейчас я буду рвать все вебсокеты"?

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

Может быть нормальные политики управления трафиком на L7, с ретраями, circuit breaker'ами, и прочей прелестью, которые можно просто сконфигурить и оно будет работать?

В свое время пришлось повозиться с Envoy и у меня создалось впечатление, что его конфигурация вообще не для человека сделана, а для машин и кишки торчат наружу. Что само по себе конечно имеет свои плюсы, но и имеет и минусы. Для кого-то они существенны, для кого-то нет. Чтобы удостовериться, что это не одному мне так показалась - спрашивал ещё независимых мнений и получил подтверждение своему впечатлению.

И не даром же, даже при наличии Envoy, ингресс-контроллер на базе nginx набрал большую популярность. И коммерческая версия такого ингресс-контроллера пользуется спросом.

Или это отсутствие странных сюрпризов, вроде того, что при любом матче локации nginx ходит в файловую систему, даже если в локации нет ничего кроме proxy_pass?

Это не так. И никогда такого не было ни в одной версии. `proxy_pass` однозначно устанавливает обработчик на location, который вызывается в content-фазе. А матчинг - это просто префиксное дерево и списки с регулярками. Там вообще нет сисколов. То, что вы описали, больше похоже на некоторые моменты в Apache.

Ну, а если указали try_files - назначение которого буквально кричит из названия директивы, то тут странно удивляться.

Может быть автодискавери сервисов? Система плагинов и фильтров без "а давайте мы просто всунем код на луа вот прямо сюда"?

Экосистема модулей для nginx одна из самых больших. Луа - тут лишь один из сторонних модулей и не надо вставлять код на луа, это скорее про OpenResty, что суть отдельный проект со своей идеологией ближе к серверам приложений.

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

Абсолютно нормально если вы лучше познакомились с одним проектом и плохо знаете другой. Плюс у всех разные подходы и взгляды на то, а как должна выглядеть конфигурация. Выше я писал про свое впечатление от того же Envoy. А кто-то вообще хочет, чтобы всё мышкой тыкалось и таких очень много. Прекрасно, что на любой запрос есть свое решение.

P.S. У меня есть понимание как сделать конфигурацию более гибкой, простой и интуитивно понятной. Но для этого нужно время и по опыту NGINX Unit, где подход к конфигурированию был принципиально другим - понятно, что какие-то радикальные идеи и изменения тоже не находят отклика в массах, т.к. есть большая инерция мышления и есть в этом также существенный момент субъективизма.

Это не так. И никогда такого не было ни в одной версии.

Этого не может быть, потому что этого не может быть никогда, да.

И это не лично я на эту мерзость убил неделю своего рабочего времени, чтобы выяснить, что она каким-то хитрым образом делает, емнип, stat на путь $dockroot/location всегда, если root в конфиге определён.

Ах да, у нас же есть ещё смешное наследование root, которое добавило перчинки в инвестигейт.

ингресс-контроллер на базе nginx набрал большую популярность.

Как же хорошо, что это решето наконец закопали. Что до коммерческого контроллера, у меня от чтения доков на него осталось стойкое ощущение продукта для матёрых nginx'еров, чтобы им было удобнее тащить свои привычки и подходы в k8s. Возможно для компаний в которых есть любители nginx, такой подход рационален или оправдан сентиментальными соображениями.

Абсолютно нормально если вы лучше познакомились с одним проектом и плохо знаете другой.

Я начинал своё знакомство с миром web-серверов именно с nginx. И именно слишком близкое знакомство с его ограничениями и особенностями и заставило меня перейти на более современные альтернативы.

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

И это не лично я на эту мерзость убил неделю своего рабочего времени, чтобы выяснить, что она каким-то хитрым образом делает, емнип, stat на путь $dockroot/location всегда, если root в конфиге определён.


`root` в конфиге всегда определен. У него есть значение по умолчанию, но stat() при этом не делается (и зачем?). Игорь всегда очень трепетно относился к сисколам и минимизировал их количество.

Я понимаю, что наверное вы что-то наблюдали. Такое запросто может делать какой-нибудь сторонний модуль, этого исключать нельзя. Ванильный nginx так не делает. В любом случае - правильным действием было бы не тратить время на поиски, а пойти и задать вопрос разработчикам, благо я, Максим и многие другие коллеги регулярно в списках рассылки отвечали пользователям.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации