Сформирован выпуск основной ветки nginx 1.25.1, в рамках которой продолжается развитие новых возможностей. В параллельно поддерживаемой стабильной ветке 1.24.x вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей. В дальнейшем на базе основной ветки 1.25.x будет сформирована стабильная ветка 1.26...Подробнее: https://www.opennet.me/opennews/art.shtml?num=59290
потихоньку устаревает и не _плохо_ поддкрживает для облачные среды (это где бэкенды динамически появляются и исчезают, если кто не знает)хотя, в тоже время, по-прежнему хорош для раздачи статики или боле-менее статических бэкендов
какие преимущества перед varnish?
Ssl
какие недостатки после nginx?
> потихоньку устареваетВ чем это выражается? В индустрии никто не считает nginx устаревшим, это мнение я слышу только от считанных анонимов опеннета.
И не чистый прокси, и не чистый веб-сервер, зато модном, стильно, малодежно.
За пределами опеннета вполне тоже слышны такие голоса. Динамические апстримы, авто ssl, сложные конфигурации - на это напирают в основном
а шо там по вменяемой альтернативе?
Все уже давно сидят на траефиках и хапрокси.
> а шо там по вменяемой альтернативе?божественный IIS
> божественный IISЧто, им настолько никто не хочет пользоваться уже что приходится по опеннету побираться? Не угадали с целевой аудиторией, ваш бАжественный IIS даже сам майкрософт для отгрузки апдейтов себе любимым юзать не изволит. Если оно даже самому майкрософту не надо - остальным и подавно.
Я так полагаю, то сарказм был.
IIS - это реализация Internet Daemon средствами ядра Windows. У него вообще не то применение и оно никуда не делось.Если вам нужен мощный сервер веб-приложений, который установлен на железо и который умеет запускать процессы-воркеры под ваши веб-приложения с учетом NUMA и вводя ограничения на ресурсы под каждое приложение, то вам нужен IIS.
Его архитектура больше похожа на xinetd, только с тем отличием что большая часть всего выполнена как драйверы в ядре (SSL, HTTP, Kerberos).
Его используют для:
- корпоративных веб-приложений со сквозной аутентификацией на базе фреимворка WCF
- высоконагруженных бекендов сайтов с кастомными воркерами, подключающимися через CGI
- работы в полном barebone-режиме, когда ты тюнишь веб-приложение под железо и тебе нужна поддержка автоматизации всего пайплайна включая поведение пакетов в ядре ОС.
Я специально не говорю про всякое Legacy, речь только новые решения.Как видно из списка, это всё либо очень корпоративно либо всё жутко нишевое. Причем даже в корпоративном сегменте WCF можно менять на gRPC... да и вообще удаленный вызов процедур начинается не с выбора фреимворка, а из понимания, того что есть на предприятии. Высоконагруженные бекенды тоже можно переложить на кубик а веб-приложения загнать в докеры... это тоже опция. Все можно заменить на аналоги, всё кроме железа. На практике, развернуть и сопровождать barebone Kubernetes своими силами без грамма виртуализации сложнее чем ускриптовать отказоустойчивый кластер IIS.
Альтернативе - ЧЕМУ? Если "nginx'у как nginx'у" - то считай нет - так ведь и apache'у nginx не альтернатива, куды ни глянь - ничего не умеет.
Раздача статики - пожалуй безальтернативно, но скорее по тому, что никто в эту нишу особенно не лезет.
"Веб сервер общего назначения" - современный apache не сильно хуже по производительности в околореальных кейсах а местами сильно удобней за счет большей универсальности, IIS в ряде случаев просто безальтернативен, в ряде инфраструктур просто удобен.
Реверс-прокси для куба и не только? Ну, там haproxy\traefic\envoy пожалуй что и получше будут.
Встраиваемые\легковесные решения, вендорский high-load - опять таки, nginx прям не лучший выбор.
Что такое "веб-сервер общего назначения"? Если 20 лет назад на этот вопрос ещё можно было ответить (статика, скрипты, проксирование с кэшированием), то сейчас - чего общего между шаред хостингом с PHP и ingress-контроллером?
Да вот что-нибудь позволяющее удобно развернуть какой-нибудь среднесдельный wordpress\django для не особо нагруженных применений на VPS'ке буде вдруг возникнет у вас зачем-то подобное желание.
> Раздача статики - пожалуй безальтернативно, но скорее по тому, что никто в эту нишу особенно не лезет.Безальтернативно на S3-совместимых хранилищах. Содержать отдельный веб-сервер для статики — это какой-то вид спецолимпиады.
Ну, в этой парадигме тебе вообще "веб-сервер" не нужен - что у облачного провайдера торчит, то в веб-интерфейсе и тыкай, "держать отдельный веб-сервер" - это какой-то вид спецолимпиады )
Да по сути уже ответили, примерно что я и имелл виду - для кубера - Traefik/Istio.Для статики - можно нодой (Node.js) отдавать. Особенно фронтендерам понравится - всё в пределах одного стека =)
Просто не мог не удержаться не написать что нгинкс "застыл" и по сути "проспал" появляение облачных инфраструктур.
Хотя я сам с него статику раздаю.
На ум приходит аналогия:
Как раньше Apache называли - могильником опенсорса,
так теперь, F5 стал могильником для Nginx'а =)Если вдруг это кто читает из Angie (https://www.opennet.me/opennews/art.shtml?num=59231) - добавляйте туда нормальную поддержку облачных сред, докера, кубера. Это will make Angie great again!
На подмёрдживании апстрим ветки далеко не уедете =)
> F5 стал могильником для Nginx'а =)Ваши наколенные хипстерские штцки и закапывать не надо - одноразовая байда, само сдохнет через несколько лет, как только хайп сойдет немного.
> Это will make Angie great again!
...на пару лет, а потом фатально помрет как хипстеры потеряют интерес.
>Ваши наколенные хипстерские штцкис добрым утром)
никуда они не уйдут)
знаете альтернативу куберу ?)
для масшатбов предприятия, а не наколенного проектика
В принципе, когда новые штуки делают, мнения админонимусов не спрашиваютим всегда всё не слава б-гу
просто делают новые штуки
они выстреливают, либо нет
> а шо там по вменяемой альтернативе?кто ж знает - вменяемость у всех разная. Вот разработчика не устраивает что https://blog.kronis.dev/everything%20is%20broken/n... , что если значит апстрим не найдет, веб сервер не стартует
> nginx: [emerg] host not found in upstream "my-app"
а хотя мог бы игнорировать ошибку и пробовать снова и снова потом. Вменяемо ли так делать - ну открытый вопрос для меня.
или дальше ( https://blog.cubieserver.de/2022/switching-from-nginx-to-cad.../ )
> Caddy boasts with its easy configuration (many people have been bitten by some footguns in Nginx’ configuration file), included configuration API, automatic HTTPS, high performance, and extensibility (thanks to its modules). Especially the easy configuration is often cited on Hacker News et al. as one of the major advantages of Caddy.
Footguns нашли в конфигах, апи не нашли - можно ли считать таких людей вменяемыми и решения за которые они топят, тоже вопрос открытый.
А кому это надо?
Полтора человеку?
Нджинкс простой и быстрый, решает задачу хорошо для большинства народа.
При этом, твои примеры решаются с пол тычка, с учетом что это нужно не многим, то такие решения лучший вариант, чем учить новый продукт, который не понятно с какой эффективностью будет работать.
> Полтора человеку?Почитайте интернеты, бложики разрабов уровня "CTO в компании из меня и моего кота" или даже на 5 человек!
> чем учить новый продукт, который не понятно с какой эффективностью будет работать.
забываете что не все застали IRC, этим людям что Nginx учить что не Nginx с нуля. А им не ахота, плюсов не видят - чем дальше тем больше таких новичков.
У жинкса даже балансировщик нормальный в платной Плюс версии. Ну о чем ты вообще говоришь. О чём тут вообще говорить. Любой хапрокси делает хелсчек из коробки и есть не просит.
Хрен с тем что в платной, позволить то его себе можно
Проблема в том, что исходники этих платных частей недоступны, в т.ч и само ядро, а потому в случае если какие-то вещи нельзя провернуть через модули nginx, остаётся только страдать и вставлять хуки.
Ну во время продажи все понимали что так будет. И так есть и это принесет свои плоды. Не очень хорошие конечно.
Смысл в раздаче статитки самому? Как бы быстро ты её на раздавал если от пользователя до тебя 300 мс тебе тут никакой nginx не поможет. Лучше CDN ты все равно быть не сможешь. А раздавать тяжелый контент так там вообще показатели от вебсервера не зависят.
А потом CDN банит страны по IP.
И что он делает не так?
Бан по диапазону адресов уже достаточно для того, чтобы задуматься об использовании сервисов доставки контента.Сегодня тебя блокируют одно, а завтра за другое: твоего цвета кожи, взглядов, страны, расы и так далее.
Выбери другой cdn, а если все cdn забанили то так тебе и надо. Все равно свой cdn ты сделать не в состоянии.
> Все равно свой cdn ты сделать не в состоянии.Поставить несколько серваков или даже, простите, впсок в нескольких датацентрах в разных странах - не больно какая ракетная наука. Если вы не в состоснии даже это - окей, вам только и остается что корпоративные ботинки лизать.
Лучше расскажи почему ты этого не сделал?
Вас, батенька заморский господин, кто управляет популярными CDN, обложит санкциями - и ваш сайтик закончится.Примерно поэтому.
А ещё потому что CDN не нужен для маленьких проектов, на-попробовать.
Ну всё раздавай свои никому ненужные картинки с пингом 500. Тебе за это никто спасибо не скажет.
за остановку сайта из-за того что ты завязался на решение из недружественных стран и попял под санкции
тебя тоже не поблагодарят)
Не надо просто никуда попадать. Это кстати несложно.
А это вас не спрашивают, вас просто отрубают и всё.
Это вас не спрашивают.
А у нас никто никого не отрубает :)
Варианты, выбирайте любой
а) вы - не системно значимая организация (читай, вы никому не интересны)
б) вы из недружественной страны, следовательно вы - шпион-провокатор
в) вас это не коснулось, т. к. вы не работаете в IT, просто приходите потроллить время от времени
г) пользуетесь российскими CDNхорошего дня!)
д) я работаю не здесь, и мне как-то фиолетовы местные проблемы
Опять же о недостатках нжинкса говорят даже не мнения экспертов, а падающая доля нжинкса.
А эта падающая доля - она сейчас с нами в одной комнате?
У тебя мания преследования? Кто там у тебя стоит за спиной в твоей комнате?
Минутка интересных фактов доля нжинкса с июля 2021 года по март 2023 упала с 37% до 26% и никакой коррекции там не наблюдается.
А кто набирает обороты? где глянуть?
> где глянуть?глядеть строкой выше, в статистике от анонима. Он сам проводил исследование.
> А кто набирает обороты?
Набирает обороты аноним, свидетель уходящего нгинкса.
Исследования проводила компания с хорошей репутацией. А фанатики нжинкса не могут поверить что веб-серверок, скоро исчезнет.
а эта компания с хорошей репутацией - она сейчас с нами в одной комнате? покажи на этой кукле, в каком месте они трогали тебя за веб-сервер
Я тебя сейчас удивлю, но даже мы с тобой не в одной комнате. Ты почему таблетки не пьёшь?
Есть такой секретный ресурc, про него никто не знает, называется неткрафт. Дальше сам.
xА кто набирает обороты?
Others
Нашёл кое что интересное: https://www.techempower.com/benchmarks/#hw=ph&test=plaintext...
Там % проектов на сервере или % обслуживаемых пользователей?
Зайди на сайт и посмотри, лол.
Каменты выше почитал
Точно лол
nginx уже не торт, давно не развивается, всякая ерунда типа как в текущей новости, это не развитие, так, поддержание штанов.
Зато хайпожорства было.
И тут выяснилось, что для жизни в опенсорсе кишка тонка и слишком много костылей, а для жизни в неопенсорсе жизнь в опенсорсе так-то и не нужна.
Если проще - чел запилил пет прожект и срубил на его продаже до фига бабла - тут респект и уважуха.
Но вот тем, кто на хайпожорство повёлся и усиленно внедрял в свои смузиделки - теперь светят эцихи разных калибров. Как обычно и бывает.
Эм. А в чем проблема? Откуда "эциха" ждать, если не секрет?
Если посмотреть на график роста нжинкса, то Сысоев продал ровно на начале большого пика (т.е. вовремя в лучшее время). Потом большой прыжок после покупки и потом очень быстро большое плато и падение. Всё как по учебнику надо быть в нужном месте в нужное время.
когда уже http3 из коробки то будет чтобы компилить не нужно было?
Что значит из коробки? Ты паразит?
Это недоразумение нжинкс не умеет делать реверс прокси на http/2, о чём уж тут говорить. Тот же хапрокси делает на изи.
Эм. Да как бы с 1.13 умеет, в тут уж 1.25 обсуждается. В криокамере свет вырубили или кто-то с debian 9-затт-без-системд! Не слез?
Не знаю чего он у тебя умеет выдает HTTP 1.1 даже сейчас
Ну, grpc != http2, но работает поверх http2 и работает вполне себе хорошо. grpc_pass с обычным http2 бэкендом тоже работает, правда хз насколько хорошо\корректно - на простой запрос данные отдал, а так хз, не тестил.
Сорри, если не прав - у меня в бэке только grpc поверх h2, а с ним проблем уж лет много как нет.
grpc в целом работает только через http2 бай дизайн. Тем не менее в модуле прокси ngx_http_proxy_module на уровне настроек если смотреть в исходники нет такой опции чтобы задать что дальше соединение должно идти по 2.0. На входе в сам нжинкс можно сказать что он http2, но дальше можно понизить до 1.0 или выставить 1.1. Я там всё излазил перед тем как плюнуть на весь нжинкс сразу.
И в частности тоже через него. "Чистого" http2 backend'а у меня нет, а grpc'шных - в количестве, и взаимодействие с ними nginx уже года четыре вполне успешно решает https://www.nginx.com/blog/nginx-1-13-10-grpc/
А знаешь что лучше всем покажи. Вот тебе первая ссылка из гугла. Расскажи им там как надо https://serverfault.com/questions/765258/use-http-2-0-betwee...>> No. As of v1.22 (currently, the latest stable release), proxy_http_version still doesn't include http/2 . See detail
Ой да ладно даже давай исходники нжинкса смотреть где там поддержка версии 2.0? Только 1.0 и 1.1 https://github.com/nginx/nginx/blob/branches/stable-1.24/src...Я даже точную ссылку даю на исходники. Тут 1.24 чисто чтобы версия была в ссылке написана.
Значит нжинкс отсталый http-сервер?
Не раньше, чем в OpenSSL появятся необходимые изменения.
Возможно очень долго. Возможно никогда.
Сысоев сейчас чем занимается?
> Параметр "http2" в директиве "listen" объявлен устаревшим.
> Прекращена поддержка директивы "ssl", ранее объявленной устаревшей
server
{
listen 443 http2 ssl;
server_name ........;
ssl_certificate ....;
ssl_certificate_key ;
root ...............;
....................;
}
А как нужно правильно тогда?
Удалена поддержка `ssl on;`, которую депрекейтнули в 1.10
Добавлена `http2 on;` вместо `listen ... http2`То есть верной версией будет
```
listen 443 ssl;
http2 on;
```Но учитывая сколько версий прожила `ssl on;` после депрекейта можешь не торопиться
Благодарю!Понял.
Cмысл в том что теперь http2 on; 1 раз можно указать в блоке http и не указывать в каждом server.https://nginx.org/en/docs/http/ngx_http_v2_module.html
Syntax: http2 on | off;
Default:http2 off;
Context: http, server
This directive appeared in version 1.25.1.
> Благодарю!Да не за что
Я сначала прочитав в новости про директиву ssl сам не понял что имеется в виду, так как давно уже забыл о ssl on, не мог понять что убрали и главное зачем
Когда полез смотреть в код понял и что убрали ssl on, и что ввели http2 on отдельной, а в listen депрекейтнулиВ принципе я бы сказал, что нужно новые конфиги делать уже с http2 on, но нет нужды исправлять все старые прям сегодня, еще несколько лет оно явно будет работать, можно постепенно уходить от депрекейтеда, как уходили от ssl on
> Благодарю!
> Понял, смысл в том что теперь http2 on; 1 раз можно указать
> в блоке http и не указывать больше в каждом server.Более ценно, что теперь оно может включаться пер сервер
Раньше объявление у одного из виртуальных серверов в листене вело к тому, что включалось для всех виртуальных серверов
А у меня есть в хозяйстве ребята которые умудрились написать тг-бота у которого веб-часть не работает при обращении по http/2(не спрашивай как они это сделали, руки у них не оттуда растут)
Мне приходилось их держать просто отдельно от всего остального проекта к которому они относятся, в отдельном тазу, со своим nginx'ом, что бы они не мешали со своим http/1.1 нормальным людям
Теперь можно будет со временем их мигрировать ко всему проекту, просто для них сделав старую версию протокола
> Благодарю!
> Понял.
> Cмысл в том что теперь http2 on; 1 раз можно указать в
> блоке http и не указывать в каждом server.Технически, если http2 был указан в каком-либо vhost для пары ip:port (ip может быть опущен и тогда это неявный 0.0.0.0), оно включалось для всех соседних вхостов с таким же набором ip:port. Что на практике при превалирующем варианте
server { server_name vhost0; listen 443 http2 ssl; ...}
server { server_name vhost1; listen 443 ssl; ...}
server { server_name vhost2; listen 443 ssl; ...}
server { server_name vhostXXX; listen 443 ssl; ...}означало что у всех vhost0-vhostXXX поддержка http2 будет включена.
Как я понимаю в 1.25.1, это теперь не так.