Опубликован выпуск основной ветки nginx 1.29.1, в которой продолжается развитие новых возможностей. В параллельно поддерживаемую стабильную ветку 1.28.x вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей. В дальнейшем на базе основной ветки 1.29.x будет сформирована стабильная ветка 1.30. Код проекта написан на языке Си и распространяется под лицензией BSD...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63725
> автоматизации запроса, получения и обновления сертификатовУже слишком поздно. В современных серверах такой функционал был годами, и вряд ли щас все кинутся обратно в нгинкс, лишь потому что он наконец проявил какие-то редкие признаки современности. Нгинкс всё.
А какие есть плюсы у nginx в настоящее время? Раньше-то понятно, если сравнивать с апачем
Плюсы у nginx сейчас такие же, как и раньше: тянет тысячи и тысячи запросов в секунду, при этом PHP не падает, а вот на apache очень даже падает. Делал высоканагруженные приложения на PHP и мне еще ни разу удалось нормально завести свою разработку на apche, а вот на nginx все без проблем работает, т. е. это все личный опыт.P. S. И вот не надо мне тут, что я не умею настраивать apche, все я умею, в свое время все конфиги и все нюансы изучил пытаясь подкрутить его.
У нгинха внезапно нет php, есть только интерфейс к fpm. На апаче тоже можно mpm_event завести и дальше mod_proxy к fpm, в итоге будет не сильно нагруженнее нгинха.И да, ты действительно не умеешь крутить апач.
Почему, есть, называется nginx unit, только это совсем другой продукт. Кстати довольно неплохой.
Диалог "байки из склепа" какой-то. Там уже каждый язык напилил себе миллион http серверов и прокладок. Запускать что-то на nginx и апаче это моветон какой-то из начала 2000-х.
Ngxin все еще используется как l7 балансер, но кажется конкурентов у него уже много. Особенно в свете любителей облаков, докеров и всяких k8s.
Каждый язык напилил, а юзают всё равно нормальные вёбсерверы.
Потому что всё это напиленное не выдерживает сколь-либо серьёзной нагрузки и не конфигурируется в должной мере.
> Потому что всё это напиленное не выдерживает сколь-либо серьёзной нагрузки и не конфигурируется в должной мере.Ты сейчас на полном серьёзе рассказываешь, что тьюринг-полный ЯП обшего назначения не конфигурируется в должной мере, в отличие от формата конфига апача? Ой-вей. Тут медицина бессильна.
> У нгинха внезапно нет php, есть только интерфейс к fpm. На апаче
> тоже можно mpm_event завести и дальше mod_proxy к fpm, в итоге
> будет не сильно нагруженнее нгинха.
> И да, ты действительно не умеешь крутить апач.Потому что чем проще и логичнее решается задача - тем лучше. То что из д@рьма можно путем долгих преобразований сделать отдаленное подобие конфетки - не делает его другой субстанцией.
А нжинкс сразу работает как надо и не делает мозг. За что его и любят.
Там не надо никаких долгих преобразований. Повторюсь: ты просто не умеешь его готовить.
А вот заставить nginx в .htaccess, чтобы по каждому чиху конфиг не править и демон не дёргать - это уже отдельная тема.
> А вот заставить nginx в .htaccess, чтобы по каждому чиху конфиг не править и демон не дёргать - это уже отдельная тема.Я бы ещё понял, если бы тебе какая-то уникальная функциональность нужна была. Но если проблема реально уровня «конфиг не править и демон не дёргать» — это какой-то лол. В чём проблема отредактировать конфиг и где принципиальная разница с редактированием .htaccess? Про такую простую вещь как атомарная перезагрузка конфига по сигналу или обновлению файла даже упоминать грешно, это релизовано сто лет назад для любой комбинации ОС/ЯП где это в принципе возможно. Ты либо что-то не договариваешь, либо у тебя там цирк с ручным управлением серверами в духе старой школы девяностых, логин юзером через судо в рута, и забытые в 99м Сан Санычем сессии screen с vi.
> это релизовано сто лет назад для любой комбинации ОС/ЯП где этоВ нгинхе реализовано? Или надо поверх монитор колхозить?
«Нгинх» — это язык программирования или ОС?
Чисто прокси-специфичный конфиг на FPM для примера к базовой конфигурации:
И ффсё. Сложнее по вкусу.---
DirectoryIndex index.php
<Proxy "unix:/opt/app/run/fpm.sock|fcgi://php-fpm-app/" connectiontimeout=10 max=100 retry=1 timeout=900>
</Proxy>ProxyTimeout 900
<FilesMatch \.php$>
SetHandler "proxy:fcgi://php-fpm-app/"
</FilesMatch>
Нафига тебе тысячи и тысячи запросов index.html с диска? Или ты про robots.txt?
https://www.netcraft.com/blog/july-2025-web-server-survey
Судя по тому, как там отхер растёт, статистика уже не отражает действительности, те же апачи и т.п. просто не афишируют себя или находятся за балансерами, скрывающими инфру.
> Судя по тому, как там отхер растёт, статистика уже не отражает действительности,
> те же апачи и т.п. просто не афишируют себя или находятся
> за балансерами, скрывающими инфру.это ты щас про к@лофайр или кого импортозамещенного?
А то балансеры в виде модных молодежных аплайансов обычно хороши корпоративную хрень какую прятать. А под нагрузкой их самих прятать приходится, а то вот... лопнуло и забрызгало меня и товарищей прессу.
Ну и зачем нам кузнец в таком раскладе - тоже не очень понятно. Нода жеес сама себе хетететепе 2.0 модный сервер. Ну с некоторыми недостатками, но за тремя слоями прокси их видно не будет. Т.е. вполне можешь учесть то что торчит таки наружу (не ноду же ж считать) именно вебсервером. отхeр так отхeр...
> Судя по тому, как там отхер растёт, статистика уже не отражает действительности,
> те же апачи и т.п. просто не афишируют себя или находятся
> за балансерами, скрывающими инфру.Проблема апача как раз в том что сам по себе нормально работать - и сразу - это как раз не про него. За это он и пролюбливает рынок. Утюг энтерпрайзный. Умеет летать - но недолго и почти отвесно вниз.
PHP и высоконагруженное приложение уже смешно звучит! :)
2006-2010 ещё прошло бы, но не в 2025!
что смешного? такто сейчас бэк нередко на питонах всяких вообще а он на порядок медленней современного php
При всей моей нелюбви к php, он сильно быстрее питона, на котором сейчас пишут все бекенды. Так что если тебе не смешно от словосочетания "Python и высоконагруженное приложение в 2025", то хз что тебя насмешило в php.
> При всей моей нелюбви к php, он сильно быстрее питона, на котором
> сейчас пишут все бекенды. Так что если тебе не смешно от
> словосочетания "Python и высоконагруженное приложение в 2025", то хз что тебя
> насмешило в php.Если вы не заметили - питона нынче из веба везде выставляет Go. Изначально с подачи гугдя, но ... почему-то все знакомые PHPшники на него перешли.
Не заметили.
На питоне инструментов много всяких.
На го ничерта готового нет (то что есть — в 90% заброшено и дисфункционально), всё сам коди.И при этом питон дёргает си-модули быстрее всех на свете.
И позволяет писать аккуратно, а программисты всё ещё стоят дороже компьютеров.
Хайлоад можно сделать из всего, главное серверов побольше подключить)
Um, 1000 запросов в секунду на логику приложения я ещё 5 лет назад на пыхе без JIT'а в 4 ядра имел. Нет, не на "буизнес логику", на специфичную логику с кучей кеширования и костылями для предотвращения thundering herd, но тем не менее.
Нуээээ... некоторые админы (думают, что) его знают.
> А какие есть плюсы у nginx в настоящее время?Я бы сказал так: какие бы плюсы ни были у альтернативных решений, им всем сопутствует потеря производительности на 20-40% относительно nginx.
> А какие есть плюсы у nginx в настоящее время? Раньше-то понятно, если
> сравнивать с апачемОни и сейчас - остались. Конечно есть еще более специализированные ultra-performance штуки, которые и нжинксу мастеркласс дадут. Но они нишевые и либо спецом под занятие призовых мест в бенчах, либо просто странноватые зверушки под задачи. Их общий набор фич куда меньше.
>Нгинкс всё.Ты сказал?
а чем, кстати, в этом сезоне модно раздавать статику и дергать бэкенды?
в этом сезоне немодно статику. Жизненно необходимо favicon.ico хранить в amazon s3!
на этой неделе прячут за клаудфларью
А где ж ещё его хранить? На железном сервере с линуксом и сабжем? Ух, сейчас бы статические ресурсы не через cdn раздавать. Вам что, реально так нравится сервера админить?
> а чем, кстати, в этом сезоне модно раздавать статику и дергать бэкенды?Астрологи объявили неделю моды на раздачу статики через NodeJS:
NodeJS -- даёшь по ядру на каждые 10 rps!
>> а чем, кстати, в этом сезоне модно раздавать статику и дергать бэкенды?
> Астрологи объявили неделю моды на раздачу статики через NodeJS:
> NodeJS -- даёшь по ядру на каждые 10 rps!В принципе на топовом EPYC с 192 ядрами даже не так уж позорно будет. То что нжинкс с этого зальет весь глобус в одиночку - вопрос номер два :)
Современные сервера́ — это какие?
уря, теперь F5 копипастит код из agnie.
(но что-то как-то медленно получается - "предварительная версия" того что сто лет как работает)не то чтобы этот модуль конечно уже был кому-то сильно нужен...
> предварительный выпуск модуля ngx_http_acmeэто конечно всё очень интересно, но во-первых там всего лишь http-челлендж поддерживается, а dns-челлендж в большинстве случаев куда удобнее, а во-вторых, как они себе представляют дальнейшее добавление dns-челленджей без ущерба безопасности nginx-а? Всё-таки подобные вещи лучше держать за пределами веб-сервера.
как ты себе представляешь dns-01 в веб-сервере?> а dns-челлендж в большинстве случаев куда удобнее
в большинстве случаев он совершенно излишен.
Необходимо и достаточно для 99% сайтов-однодневок автоматически получить совершенно им ненужный сертификат и так же автоматически его обновить через пол-дня согласно новым улучшенным требованиям. И всьо.
А для обработки платежей неплохо бы хранить ключи не в /tmp с правами 666, для начала. И может быть даже, о ужас, зашифрованными и с ручной разблокировкой. Хотя, конечно, на самом деле все равно свалят в /tmp и сделают "ЧМОД" а потом еще в гитляп и шитхап закомитят для надежности. А тогда нафига было стараться и с основным сайтом-то?
dns-01 в веб-сервере можно сделать, дергая API dns-сервера (ограничившись dns-серверами, где API есть). Тут бы вполне пригодился njs, чтобы не писать плагины на C/Rust под каждый API.
если у тебя есть доступ к этому апи у веб-мордочки - у тебя уже все плохо.
многие думают, что апи существует для того, чтобы дергать его из любого места :)
> многие думают, что апи существует для того, чтобы дергать его из любого
> места :)оно потом _оказывается_ что так и есть ;-)
> оно потом _оказывается_ что так и есть ;-)для публичных апи может и быть, менеджмент апи - нет, сугубо приватное (изолированное от несанкционированного доступа).
>> оно потом _оказывается_ что так и есть ;-)
> для публичных апи может и быть, менеджмент апи - нет, сугубо приватное
> (изолированное от несанкционированного доступа).Ну так аэрофлота вон тебе и поменеджили немного :). Если нечто "сугубо приватное" это еще не значит что атакующий туда не доберется.
А там не надо доступ к апи у веб-мордочки. Там надо доступ у основного процесса мордочки, юзеры в него не смотрят. Ну и даже если проломится до рута - а чего оно кроме единственного TXT подёргает-то...Мне больше нравится само наличие ключей от ACME в контексте вёб-мордочки, поэтому я эти механизмы не использую вообще, генерацией сертификатов занимается совершенно отдельный сервис, который как раз DNS может подёргать, и уже потом их апдейтит в вебню.
> занимается совершенно отдельный сервисразделение труда :) эй нджинкс, завари ка чаю
есть такая штука, как разные права доступа для разных api keys
> как ты себе представляешь dns-01 в веб-сервере?Да элементарно, можно таки dynamic update подёргать. Тот же вайлдкард без dns-01 не выпихать.
> Да элементарно, можно таки dynamic update подёргать.я бы предпочел чтобы веб-сервер таки не имел доступа ни к каким dynamic updates. И вот особенно - основного домена самого веб-сервера (авторам идеи надо было бы кол в бошку вбить за то что они не додумались выделить субдомен для своих игрищ и еще и запихали запрещенный символ в имя записи)
> Тот же вайлдкард без dns-01 не выпихать.
тот же вайлдкард низачем и не нужен при автоматизированном получении стольких сертификатов сколько душа жаждет.
Он был нужен прежде всего чтобы сэкономить усилия (и еще немножечко вредить). А машина - она железная.
Ды ладно, why not. Разрешить вот конкретный _acme_challenge TXT подёргать - невелика беда. Тем более, что это не в контексте пользователя в том же апаче будет дёргаться, а в контексте основного процесса.> тот же вайлдкард низачем и не нужен при автоматизированном получении стольких сертификатов
Сейчас если лучшая идиотская идея в виде срока жизни в 30 дней пройдёт - уже будет нужен...
// в менее 30 дней
> Ды ладно, why not. Разрешить вот конкретный _acme_challenge TXT подёргатьА потом выяснится что где-то ошипка...
Или подергать могут что-то не то, или подергать может не тот, или оба сразу.> Сейчас если лучшая идиотская идея в виде срока жизни в 30 дней
> пройдёт - уже будет нужен...наоборот, поскольку придется отказываться от неавтоматических обновлений и надежных ключей - низачем станет не нужен. Раз уж оно все внутри и под контролем самого веб-сервера - то пусть на каждый домен получает, включая никому ненужные редиректилки ru.www.com -> www.com/ru
Инфры этих троянских коней совсем ведь не жаль.
> я бы предпочел чтобыя помню времена когда бинд (нейм сервер) и апач на одном сервере крутились :)))))
>> я бы предпочел чтобы
> я помню времена когда бинд (нейм сервер) и апач на одном сервере
> крутились :)))))только вот крутились они так что доступов у одного к другому не было.
(они и сейчас там у тебя крутятся, только под капотом модных-современных-кластерных-контейнерных тяп-ляпнологий ты об этом узнаешь когда-нибудь после)
> ты об этом узнаешь когда-нибудь послечур меня чур, не дожить бы до этого дня
> тот же вайлдкард низачем и не нужен при автоматизированном получении стольких сертификатов сколько душа жаждетРовно до тех пор, пока ты не захочешь, чтобы домен не светился в логах Certificate Transparency.
да да вайлдкард не нужен, зато теперь нужен SNIусилия, бугага
> да да вайлдкард не нужен, зато теперь нужен SNIтак он в любом случае теперь нужен
>> да да вайлдкард не нужен, зато теперь нужен SNI
> так он в любом случае теперь нуженнахрена он сдался
А чем он мешает-то? В IE 6 не работает?
>> а dns-челлендж в большинстве случаев куда удобнее
> в большинстве случаев он совершенно излишен......там, где работает полтора землекопа.
А что, если у тебя домен для приватной сети, и торчать в мир он в принципе не должен?
А что, если ты хочешь выставить в мир домен, но ты не хочешь, чтобы мир об этом домене узнал?
А что, если тебе нужно выписать сертификат в kubernetes, ingress-контроллер которого находится за балансером с proxy-protocol-ом? (см. [1])Чтобы не страдать в описанных выше случаях -- возьмите себе на вооружение сразу и для всего использовать DNS-01.
[1] https://github.com/compumike/hairpin-proxy?tab=readme-ov-fil...
>>> а dns-челлендж в большинстве случаев куда удобнее
>> в большинстве случаев он совершенно излишен...
> ...там, где работает полтора землекопа.
> А что, если у тебя домен для приватной сети, и торчать в
> мир он в принципе не должен?а днс для этой приватной сети мы гордо выснуем в мир, что может пойти не так, действительно? (и зачем такому домену сертификаты летшиткрипта? У таких сетей есть обычно свои pki, может даже не одна. Там еще и сертификаты на приватные ip адреса иногда нужны.)
> А что, если ты хочешь выставить в мир домен, но ты не
> хочешь, чтобы мир об этом домене узнал?и тут такой dns-сервачок встроенный прям в вебмордочку...
> Чтобы не страдать в описанных выше случаях -- возьмите себе на вооружение
> сразу и для всего использовать DNS-01.нет, спасибо. Я как раз категорически воздержусь от его использования где бы то ни было.
acme дыряв бай дизайн в ста местах, но ЭТО делает его еще в разы дырявее.В тех случаях (редких, и тебе не понравится для чего) где мне нужен wildcard, он будет коммерческий, благо пока доступен, и, к счастью, пока его не надо обновлять раз в три дня.
Какой-то сервачок в вебмордочку поставить, собственный PKI намутить, ACME оказывается дыряв...
Не, чур меня с этим спорить.
ну, в том редком случае (публичный хостинг) я написал на golang сервис, который через внутреннее апи powerdns-а кроме как этот самый acme challenge TXT менять, ничего и не умеет, и его и дергал из... кажется, это был acme.shпо большому счету, оба способа кривые (для dns-01 можно было бы какой-нибудь _acme делегировать на отдельные нсы, а http-01 это вечные проблемы курица vs яйцо), но лучше так, чем ручками ходить платить за сертифицированный воздух
> ну, в том редком случае (публичный хостинг) я написал на golang сервис,
> который через внутреннее апи powerdns-а кроме как этот самый acme challengeну да, он же у тебя никак не был связан с веб-сервером. А тут прямо в код сервера пихают и считают что так и нада.
> по большому счету, оба способа кривые
увы.
да даже если бы его дергал веб-сервер, ничего страшного бы не случилось
конечно, только в том случае если днс сервер отвечал только за одну зону, и тут что ломай днс, что ломай веб сервер - без разницы.
> а днс для этой приватной сети мы гордо выснуем в мир, что может пойти не так, действительно?Выставлял, ничего не случилось.
Просто нужно уметь пользоваться соответствующим инструментом. Я про views в bind'е. При запросах "снаружи" зона пустая. Ну т.е. там как раз только челенджи.
>как ты себе представляешь dns-01 в веб-сервере?Я другой аноним, но отвечу на вопрос.
Представляю его:
- либо [через встроенный DNS-сервер](https://angie.software/angie/docs/configuration/acme/#angie-...),
- либо через [хук](https://angie.software/angie/docs/configuration/modules/http...), например, к acme.sh
- либо через [обращение по API к DNS-провайдеру](https://doc.traefik.io/traefik/https/acme/#providers)
то есть надо "встраивать" в веб-сервер еще целый dns сервер и обеспечивать ему открытую дверь во весь интернет? Со всем набором адских днсных проблем. (причем рецепт от agnie, как я подозреваю, кривой. В in ns работает то же ограничение что и в in a - я об этом упоминал в исходном сообщении, что это факап авторов нескучного акме)
acme.sh тебе проще по крону запустить без ненужных хуков - и с гарантией что запустится acme.sh а не подсунутое васяном троянское нечто.
> либо через [обращение по API к DNS-провайдеру]то есть мы даем вебсерверку доступ к нашему dns. Здорово, что может пойти не так?
> то есть мы даем вебсерверку доступ к нашему dns. Здорово, что может пойти не так?если собственный нейм сервер (отдельный) с одной зоной, то разницы нет ломанули веб сервер или днс сервер (условно, банальный сайт), так что доступ еще можно дать.
> то есть надо "встраивать" в веб-сервер еще целый dns сервер и обеспечивать
> ему открытую дверь во весь интернет?Ну так пожелаем сэру плавать - на корабле без переборок, не одевать каску, забить на цепляние страховки, нахрен аварийные тормоза в лифтах - и ни в коем случае не использовать запасной парашют. Ведь что может пойти не так?!
...
> acme.sh тебе проще по крону запустить без ненужных хуков - и с
> гарантией что запустится acme.sh а не подсунутое васяном троянское нечто.А сервак как культурно информировать о смене серта? По моим наблюдениям на этой почве дохнет много чего.
реализация аж днс встроенная в вебпроксилку - это и есть корабль без переборок.
А если вместо этого в ней нескучный интерфейс к основному днс - то переборка есть но двери не закрываются.А у меня все хорошо - сервер отдельно, днс совершенно отдельно. Вообще другим кораблем доставляется. Вот система шифрованной связи сведена стараниями засланных казачков из летшиткрипта к -ю, но там крайне редко и имело смысл чего-то шифровать, поэтому и так сойдет.
> А сервак как культурно информировать о смене серта?
а зачем? nginx плохо обрабатывает эту смену. Поэтому тест, необязательно на самом сервере, что шиткрипта вернула сертификат а не ойпаламалася, и kill ему.
(и да, отдельно интересно было бы поковырять чего там в модном модуле на безопастнейшем йезычке на эту тему - и тестов, и плавного завершения кэшированных сессий. Но на самом деле - нет. Ничего об этом знать не хочу. Но для большинства однодневок и лэндингов с редиректиком оно и не надо, а такого в сто раз больше чем полноценных.)
dns-челлендж есть в российском форке Angie, с которого собственно и содран этот модуль. Причем там он написан на Си, как и все остальные.
> dns-челлендж есть в российском форке Angie, с которого собственно и содран этот
> модуль. Причем там он написан на Си, как и все остальные.Посмотрел, спасибо. Имплементация выглядит весьма разумно и безопасно. Единственный момент, который интересен: вот у certbot-а и cert-manager-а есть целый набор плагинов для управления DNS-ами через апишки популярных DNS-провайдеров. Для Angie уже есть готовые, или нужно самостоятельно их писать?
Upd: А Angie пилят серьёзные ребята, которые смотрят в будущее. Они даже ingress-контроллер запилили, смотрите-ка [1]. Жаль только, что:
> Программный продукт распространяется на условиях коммерческой лицензии.
> Информацию о стоимости программного продукта, условиях его приобретения
> и лицензионное соглашение можно получить, написав нам на адрес
> электронной почты: info@wbsrv.ru.
>целый набор плагинов для управления DNS-ами через апишки популярных DNS-провайдеров.
>Для Agnie уже есть готовые, или нужно самостоятельно их писатьГотовых нет, их надо писать или адаптировать от того же acme.sh. А потом прикручивать к серверу (например, без дополнительного сервера через cgi или njs), что может оказаться сложнее написания.
Как по мне - acme.sh и так неплох, да и достаточно прост, что с DNS, что без. А, например, при юзании т.н. =DNS API integration=, тот же Яндекс, лет пять-семь назад, эту самую интеграцию поддерживал плохо (в ТП им писал, соглашались, потом поправили, но ждать пришлось достаточно долго). Безотносительно модулей и прочего.И как бы что? (: Все это - самодостаточная вещь, требующая отдельного, не комбайнёрского, подхода. С другой стороны - её никто не мешает настраивать что через модуль nginx, что без него. Стало быть - пусть будет.
После выявленного RCE в acme.sh (https://github.com/acmesh-official/acme.sh/issues/4659) предпочитаю не использовать его в новых установках.