Comments 69
UFO landed and left these words here

Интересно, что ДБ выбрали новый сервер вместо вложения сил в дописывание старого (nginx), для которого и кодовая база поменьше, и сам он очень знаком.


Похоже, еще и вся эта история с Рамблером добавила аргументов?

Там все аргументы в статье написаны. И про дописывание. Рамблер может и подкинул дополнительные аргументы на чашу, но по мне так мониторинг, который жрет в 2 раза больше, чем основной ворклоад — и так более чем весомый аргумент
Так себе аргумент, потому что не надо сбор статистики писать на Lua.
Не факт, что написание своего модуля для Nginx на сях будет проще, чем его смена на что-нибудь другое. Да и кто этот код потом поддерживать будет?
Для веб-студии из 3 человек, конечно, это неразрешимый вопрос. Для компании масштаба Dropbox все перечисленные пункты не являются проблемой.

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

Уже есть VTS, кто про него знает? например sysadmin.pm/nginx-vhost-traffic-status
код сишный
github.com/vozlt/nginx-module-vts/tree/master/src

Мы собирали пару лет назад и потом есть ещё модуль (nginx-vts-exporter) чтобы prometheus штатно читал. Но оно никогда не появится в основном nginx, потому что идёт в разрез с их платной версией.
Форкнуть (или взять живой форк). Собственно это и был пример «Написать и отдать в community.». Есть работающий код, который можно поправить под свои нужды или просто закрыть ошибки. Но я в том числе про то, что этот код неинтересен авторам того же nginx, потому что мешает им платную версию продавать.
Возникает закономерный вопрос, почему же она была написана на lua

Производительность системы мониторинга — это довольно просто решаемый вопрос.


Гораздо важнее то, что envoy дает нам огромное количество средств инструментирования из коробки (статы, точные причины ошибок в access log'ах, трейсинг, и т.д.), а так же, что его гораздо проще интегрировать с существующей инфраструктурой за счет строгого разделения между data и control plane'ами.

Вполне вероятно, что трудно уже там что-то дописывать, код зарос мхом и грибами. Часто так происходит со старой кодовой базой (тем более на Си). Очень хочется надеятся, что nginx тут исключение, конечно (тем более что альтернативное решение написано на C++, где тоже сложно надежно программировать, а не на, к примеру, дефолтно-секьюрном Расте).

Если внимательно прочитать аргументы из статьи, то видно, что envoy выбрали в первую очередь за хорошую интегрируемость в "новый код" (который не использует модель обычного демона), и за протобуферы.

Вебсервера с использованием fork, такие как Nginx, в большинстве окружений имеют проблемы с защитой стека, поскольку основной и рабочие процессы разделяют одно и то же значение для переменной-канарейки в стеке, а поскольку при проверке этой переменной сбойный рабочий процесс убивается — значение этой переменной можно перебрать бит за битом примерно за 1000 попыток.


Не уловил — а как атакующий получает доступ к «канарейке»-то?

я в код не смотрел, но предполагаю, что скорее всего канарейка инициализируется до fork

Все равно не понимаю, как атакующий получает доступ к «канарейке».

Имеется в виду Smash-Stack Protector (SSP) защита от переполнения стека, которая использует canary (канарейку) в качестве защитного слова между элементами стека.
При переполнении стека первым делом перетирается эта канарейка, что используется SSP для обнаружения факта совершения атаки.


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

Это понятно. Непонятно, почему канарейка «перетирается». Видимо, подразумевается, что в атакуемой программе уже есть уязвимость, которая позволяет это делать?

Выходит, что канарейка будет работать какое-то время, а потом, если на крики канарейки (процесс-то падает с уведомлением, скорее всего) не обращать внимание, хакер сможет ее обойти — так?

Все способы защиты стека предполагают, что в приложении уже есть уязвимости, и они нацелены на недопущении их эксплуатации (обычно путем краха приложения при обнаружении атаки, так как remote code execution считается гораздо опаснее, чем временное падение доступности сервиса).


И (пожалуйста поправьте меня, если я не прав) кажется, статья и вы имеете в виду разные канарейки. Канарейка в терминологии SSP — это особая переменная внутри процесса, она не имеет никакого отношения к процедуре деплоймента с помощью canary.

к процедуре деплоймента с помощью canary


Не думаю, что я имею это ввиду :)

Но вопросов больше нет, благодарю за помощь!
и при форке у всех детей это значение наследуется без изменения.

А его не изменить при старте форка?

Всё относительно просто: меняешь один бит в канарейке, если приложение упало то не угадал, приложение перефокнулось и пытаешься снова. И того на каждый бит у тебя 50/50 шанс — 8 байт так перебрать можно очень быстро.

Поправка: меняешь байт (по битово перебирать нельзя ибо перезаписывать можно только по байтово.) Вероятность угадать байт 1/256 и того за (в среднем) 1024 попытки перебирается 8 байт.

как Envoy поддерживает acept range, передачу видео и конечно самый главный вопрос как обстоят дела с перемоткой видео при отображение в вебе
Подожди, вроде статья про то КАК они переходили, а не про остальные косвенные темы
ну так они точно это проверяли при переходе, т.к. понимаю их направление именно в мультимедию
Мне кажется что это вопрос не к Envoy, поскольку сам он вообще не умеет раздавать статику. Это практически чистый прокси. А потому поддержка всего, что вы описали зависит от того сервиса, который стоит за Envoy.

В кои-то веки получил технооргазм при прочтении статьи на Хабре. Даже покурить захотелось. К сожалению, все реже это получается.

Envoy does not have any blocking IO operations in the event loop. Пилять в цикле обработки событиЯ а не событий

Вообще-то event loop — это именно цикл обработки событий, во множественном числе.

Причём тут вообще сигнатура функции в nginx? Это как бы широко распространенный термин, который на русском языке звучит именно как "цикл [обработки] событий".


Почему на английском слово event пишется в единственном числе — спрашивайте носителей языка.

Потому что синтаксически в этой фразе слово «event» играет роль прилагательного: событийный цикл.

Не помню, чтоб так подробно описывались сложности перехода на nginx, где без самого Игоря Сысоева переход бы не получился. Пока простой человек быстро не может разобраться в Envoy ни о какой популярности и стандарте de facto не может быть и речи. На любую проблему типа «ограничить полосу пропускания» и прочие, что в nginx задается одной строчкой, в Envoy нужно перелапатить кучу литературы, посетить несколько github веток с обсуждениями, перепробовать кучу примеров из разных обсуждений, понять нужен или не нужен в этой цепочке sidecar контейнер в поде и все-равно вернуться на nginx. Конкретно Dropbox'у это нужно было, сообразили и перешли с привлечением целой командой разработчиков Envoy. Среднестатистический проект столько усилий позволить себе не может. Пока Envoy не упростят для внедрения, не быть ему популярным
В nginx тоже простой человек с разбегу не разберется (и в апаче и тд), все «простые человеки» настраивают его по статьям в интернете (иногда ужасным), методом копипаста конфигов и подставления своих переменных.
Так что вопрос только в появлении этих самых статей.
Ну и для nginx это вполне себе фидбэк что пора бы завести динамические конфигурации и прочее чего Дропбоксу не хватило (возможно часть этого уже давно в проекте).
> Ну и для nginx это вполне себе фидбэк что пора бы завести динамические конфигурации и прочее чего Дропбоксу не хватило (возможно часть этого уже давно в проекте).

Это было понятно много лет назад, поэтому в том числе появился Unit. Наращиваем функциональность постепенно.
NGINX Unit is a lightweight dynamic open-source server for diverse web applications; to install it, see here.

Built from scratch, Unit can run web apps in different language versions; fully configurable in runtime with zero interruption, it enables on-the-fly granular management for engineering and operations.

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

Интересно узнать про лиценизию и отношению к этому продукту нового собственника nginx. Лицензия внезапно Apache License Version 2.0, January 2004.

Интересно узнать про лиценизию
Никакого большого замысла в этом нет. Проект соверешнно новый, написан практически с нуля. Посидели, подумали под какой лицензией его выкладывать: привычной нам «2-clause BSD-like» или что-то другое. Проконсультировались с юристами, посчитали, что Apache-2.0 будет не хуже и при этом теоретически лучше защитит пользователей, в том числе потому, что оговаривает отказ от патентных претензий.
и отношению к этому продукту нового собственника nginx
К тому, что об этом в своё время уже писал Игорь, мне особо добавить нечего:
mailman.nginx.org/pipermail/nginx-ru/2019-March/061949.html — так оно есть и остается. С другой стороны в рамках крупной корпорации появилось больше возможностей для развития проекта, само собой больше ресурсов.

А поддержки Lua в "Supported App Languages" нет по каким-то веским причинам?
Тот же Openresty КМК довольно популярен (в узких кругах :).

Никаких веских причин, кроме отсутствия интереса со стороны сообщества веб-разработчиков.

Если бы Lua WSAPI был популярен, то давно бы уже сделали поддержку, но я ни одного запроса на это не припомню, как и других стандартизованных интерфейсов для веб-приложений на Lua. Да и популярных приложений и фреймворков, использующих Lua WSAPI — как-то не встречал. Тот же Orbit заброшен уже много лет. RestServer — также заброшен. Sputnik — заброшен. А что есть, может я не в курсе?

Openresty не является WSAPI сервером и поэтому его популярность тут мало релевантна. Это история исключительно про расширение nginx. Тот API, который предлагает Openresty для программирования веб-приложений на Lua — он крайне нишевый и сильно завязан на внутренности nginx, а у Unit от nginx нет практически ничего в плане кода и интерфейсов.

Openresty популярен не благодаря большой популярности Lua среди веб-программистов, а скорее благодаря тому, что не было другой вменяемой альтернативы расширять функциональность nginx. На тот момент nginx мог предложить только примитивный Perl-модуль, который к тому же не блистал производительностью и не рекомендовался в прод, либо модули на Си с крайне высоким входным порогом и большими трудозатратами на поддержку.

Unit — это история не про ещё один Node.js или Openresty (почему-то хочется поставить их рядом). Unit в плане поддержки языков программирования — это на данный момент история про запуск уже готовых популярных веб-приложений, существовавших задолго до Unit-а и использующих стандартизованные интерфейсы, общие для многих серверов: Python/WSGI, Perl/PSGI, PHP/SAPI, Ruby/Rack. На этом поле мы конкурируем с uWSGI, Gunicorn, Phusion Passenger, Unicorn, PHP-FPM и подобными.

Спасибо за развернутый ответ.


Тот API, который предлагает Openresty для программирования веб-приложений на Lua — он крайне нишевый и сильно завязан на внутренности nginx, а у Unit от nginx нет практически ничего в плане кода и интерфейсов.

Ясно, я несколько не верно представлял, что такое Unit. Думал, что это тот же Openresty, только "родной" и более правильный и под большее кол-во языков.

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

разве ситуация изменилась?

разве ситуация изменилась?
Появилась возможность расширять конфигурацию сценариями на JavaScript.
Ваш Unit это классная тема! Коммент из мира Python: а у вас есть поддержка ASGI? На сайте вижу только классический WSGI. Сейчас популярные такие асинхронные фреймворки как AIOHTTP, FastAPI, к ним обещает присоединиться Django3 (при этом, Django.Channels уже давно на ASGI). Технически должно быть не сложно, раз у вас уже есть поддержка Node.js и GoLang.
На данный момент поддерживается только классический WSGI.

Мы последние несколько месяцев занимались серьезной переделкой внутреннего механизма распределения запросов по процессам приложения, фактически поменяв концепцию с push на pull в этом месте. Предыдущее решение оказалось неудачным — из-за чего в Go и Node.js наблюдаются проблемы с производительностью. Эта переделка войдет в ближайшую новую версию, которая выйдет уже в этом месяце. Данное изменение как раз позволит в дальнейшем хорошо поддержать асинхронные интерфейсы, а также ввести возможность многопоточной работы. Думаю поддержка ASGI может появиться уже до конца года.

Классно! Про quart не слышал, надеюсь, подключение других фреймворков, вроде aiohttp/fastapi, выглядит так же :)

По идее да, должно быть легко, если они соответствуют спеке ASGI. Указал техническому писателю на эти фреймворки, он попробует и добавит по ним инструкции на сайт.

Извините, но перевод очень слабый, даже Google Translate проще читается.


Не только слабый, но ещё и с потерей смысла.


We’ll compare Nginx to Envoy across many software engineering and operational dimensions.

vs.


Мы сравним Nginx и Envoy различными способами.
Намасте всем! Есть мнение что Приянки, Ананды, Прадеепы и Випули из Дропбокса по древней восточной традиции на столько усложнили бэкенд, что nginx такое количество костылей не потянул даже с Lua модулем. Есть Cloudflare, Facebook и много еще чего очень большого и крупного, которые отлично себя чувствуют с nginx. По-больше им шанти, а мы пока продолжим использовать православный Nginx

На тему пользователей:


  1. Facebook использует свою L7 проксю на основе Proxygen в течение где-то последних 9 лет, с тех пор как существующие решения (такие как Nginx) перестали удовлетворять их нужды
  2. Cloudflare использует сильно модифицированную версию Nginx в качестве edge сервера, например у них свои патчи для http/2 server prioritization, http/3 и многих других случаев. Этот подход требует отдельную команду разработки для развития и поддержки с призрачными шансами быть когда-либо влитыми в open source версию Nginx (в том числе, по причинами данным в публикации).

На тему остальной части комментария, просьба посмотреть на авторов статьи (в самом вверху страницы) и контрибьюторов (последний абзац в переводе, предпоследний в оригинале) и переосмыслить ассоциативные цепочки.

По-больше им шанти, а мы пока продолжим использовать православный Nginx

Как уже написали, крупные простой nginx не используют как раз и либо пилят полностью свое, либо используют современную альтернативу (тот же envoy), либо обкладывают костылями nginx, потому что из коробки он ни на что не годится. Смысл держаться за nginx? Назло соседу отморожу уши? Сейчас на рынке есть пачка современных L7 балансеров, которые отлично интегрируются в современный стек. Нахер этот nginx не нужен в таких условиях с его устаревшим дизайном и отсутствием банально жизненно важных фич.
У меня вообще сложилось впечатление что переход делался просто ради перехода. Статистику ведь можно было и в Lua обсчитать. Стоило оно того или нет из статьи непонятно. Ресурсы типа памяти и CPU сейчас дешёвые, вместо танцев с бубнами как правило проще докупить железа. Хотя сама статья конечно интересная.
Дык пишут что освободилось 60% серверов, т.е. больше половины, это большой прирост.
Не знаю какой у них там размер ДЦ, но даже если взять одну стойку с 48 серверами по 500 тыс руб каждый то появляется возможность сэкономить 14 млн руб.
Тут даже не об одном ДЦ речь. Это edge сеть c point of presence по всему миру, которых в статье от 2018 года было 20 штук. Число это только растет, и цепляться тут за технологию, которая плохо справляется с работой, себе дороже.
Сейчас у нас порядка 30-ти точек присутствия в мире.
И да, освободившиеся ресурсы — это приятный бонус, но не цель самого проекта.
У меня вот сложилось впечатление, что люди статьи не читают. Вся статья посвящена причинам перехода. Железо не проще докупить, когда nginx это банально технический долг, который тащит за собой все остальное, а железа этого сотни и тысячи штук (в статье речь об их edge сети, которая по всему миру раскидана), где уже не имеет значения насколько что дешевое. Если бы переходили ради интереса, то этот переход не наблюдался бы настолько повсеместно. Простой nginx в нынешних условиях это скорее для мелких приложений сервер. Поставил, скопипастил из инета пример конфига и забыл.

Самое забавное, что за переход отвечали Олег из Подмосковья и Руслан из Екатеринбурга, а рядом держал свечку Питерский наркоман Алексей =)

Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

22 March 2008

Location

Россия

Employees

31–50 employees

Registered

15 November 2012