Комментарии 69
Телеграм чат Envoy Proxy https://t.me/envoyproxy_ru
Dropbox drop Nginx
Интересно, что ДБ выбрали новый сервер вместо вложения сил в дописывание старого (nginx), для которого и кодовая база поменьше, и сам он очень знаком.
Похоже, еще и вся эта история с Рамблером добавила аргументов?
Написать и отдать в community. Если это хорошая и нужная вещь, то поддержка и миграция на новые версии не станет гигантской проблемой — энтузиасты найдутся.
Но, объективно, количество перечисленного в сумме более чем перевешивает и переход выглядит более чем оправданным. В конце концов это не Dropbox на nginx зарабатывает чтобы столько всего в него дописать.
код сишный
github.com/vozlt/nginx-module-vts/tree/master/src
Мы собирали пару лет назад и потом есть ещё модуль (nginx-vts-exporter) чтобы prometheus штатно читал. Но оно никогда не появится в основном nginx, потому что идёт в разрез с их платной версией.
Код заброшен, есть ошибки. Посмотрите список Pull requests и Issues.
Производительность системы мониторинга — это довольно просто решаемый вопрос.
Гораздо важнее то, что envoy дает нам огромное количество средств инструментирования из коробки (статы, точные причины ошибок в access log'ах, трейсинг, и т.д.), а так же, что его гораздо проще интегрировать с существующей инфраструктурой за счет строгого разделения между data и control plane'ами.
Вполне вероятно, что трудно уже там что-то дописывать, код зарос мхом и грибами. Часто так происходит со старой кодовой базой (тем более на Си). Очень хочется надеятся, что nginx тут исключение, конечно (тем более что альтернативное решение написано на C++, где тоже сложно надежно программировать, а не на, к примеру, дефолтно-секьюрном Расте).
Если внимательно прочитать аргументы из статьи, то видно, что envoy выбрали в первую очередь за хорошую интегрируемость в "новый код" (который не использует модель обычного демона), и за протобуферы.
Вебсервера с использованием fork, такие как Nginx, в большинстве окружений имеют проблемы с защитой стека, поскольку основной и рабочие процессы разделяют одно и то же значение для переменной-канарейки в стеке, а поскольку при проверке этой переменной сбойный рабочий процесс убивается — значение этой переменной можно перебрать бит за битом примерно за 1000 попыток.
Не уловил — а как атакующий получает доступ к «канарейке»-то?
я в код не смотрел, но предполагаю, что скорее всего канарейка инициализируется до fork
Имеется в виду Smash-Stack Protector (SSP) защита от переполнения стека, которая использует canary (канарейку) в качестве защитного слова между элементами стека.
При переполнении стека первым делом перетирается эта канарейка, что используется SSP для обнаружения факта совершения атаки.
Проблема в том, что значение канарейки определяется рандомным образом при старте процесса, и при форке у всех детей это значение наследуется без изменения.
Атакущий может слать запросы на тот же самый сервер и перебирать брутфорсом значение канарейки, пока рабочий процесс не перестанет падать.
Так как при смерти рабочего процесса главный просто форкнется еще раз с тем же значением канарейки — у атакующего есть бесконечное количество попыток.
Выходит, что канарейка будет работать какое-то время, а потом, если на крики канарейки (процесс-то падает с уведомлением, скорее всего) не обращать внимание, хакер сможет ее обойти — так?
Все способы защиты стека предполагают, что в приложении уже есть уязвимости, и они нацелены на недопущении их эксплуатации (обычно путем краха приложения при обнаружении атаки, так как remote code execution считается гораздо опаснее, чем временное падение доступности сервиса).
И (пожалуйста поправьте меня, если я не прав) кажется, статья и вы имеете в виду разные канарейки. Канарейка в терминологии SSP — это особая переменная внутри процесса, она не имеет никакого отношения к процедуре деплоймента с помощью canary.
Есть научные статьи на эту тему, но, насколько мне известно, этот подход не применяется текущими компиляторами.
Всё относительно просто: меняешь один бит в канарейке, если приложение упало то не угадал, приложение перефокнулось и пытаешься снова. И того на каждый бит у тебя 50/50 шанс — 8 байт так перебрать можно очень быстро.
В кои-то веки получил технооргазм при прочтении статьи на Хабре. Даже покурить захотелось. К сожалению, все реже это получается.
Вообще-то event loop — это именно цикл обработки событий, во множественном числе.
Так что вопрос только в появлении этих самых статей.
Ну и для 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-модуль, который к тому же не блистал производительностью и не рекомендовался в прод, либо модули на Си с крайне высоким входным порогом и большими трудозатратами на поддержку.
разве ситуация изменилась?
Мы последние несколько месяцев занимались серьезной переделкой внутреннего механизма распределения запросов по процессам приложения, фактически поменяв концепцию с push на pull в этом месте. Предыдущее решение оказалось неудачным — из-за чего в Go и Node.js наблюдаются проблемы с производительностью. Эта переделка войдет в ближайшую новую версию, которая выйдет уже в этом месяце. Данное изменение как раз позволит в дальнейшем хорошо поддержать асинхронные интерфейсы, а также ввести возможность многопоточной работы. Думаю поддержка ASGI может появиться уже до конца года.
Классно! Про quart не слышал, надеюсь, подключение других фреймворков, вроде aiohttp/fastapi, выглядит так же :)
А вот с aiohttp так не получится, поскольку его авторы похоже не понимают для чего нужны интерфейсы и поддержки ASGI там нет.
Извините, но перевод очень слабый, даже Google Translate проще читается.
Не только слабый, но ещё и с потерей смысла.
We’ll compare Nginx to Envoy across many software engineering and operational dimensions.
vs.
Мы сравним Nginx и Envoy различными способами.
На тему пользователей:
- Facebook использует свою L7 проксю на основе Proxygen в течение где-то последних 9 лет, с тех пор как существующие решения (такие как Nginx) перестали удовлетворять их нужды
- Cloudflare использует сильно модифицированную версию Nginx в качестве edge сервера, например у них свои патчи для http/2 server prioritization, http/3 и многих других случаев. Этот подход требует отдельную команду разработки для развития и поддержки с призрачными шансами быть когда-либо влитыми в open source версию Nginx (в том числе, по причинами данным в публикации).
На тему остальной части комментария, просьба посмотреть на авторов статьи (в самом вверху страницы) и контрибьюторов (последний абзац в переводе, предпоследний в оригинале) и переосмыслить ассоциативные цепочки.
По-больше им шанти, а мы пока продолжим использовать православный Nginx
Как уже написали, крупные простой nginx не используют как раз и либо пилят полностью свое, либо используют современную альтернативу (тот же envoy), либо обкладывают костылями nginx, потому что из коробки он ни на что не годится. Смысл держаться за nginx? Назло соседу отморожу уши? Сейчас на рынке есть пачка современных L7 балансеров, которые отлично интегрируются в современный стек. Нахер этот nginx не нужен в таких условиях с его устаревшим дизайном и отсутствием банально жизненно важных фич.
Не знаю какой у них там размер ДЦ, но даже если взять одну стойку с 48 серверами по 500 тыс руб каждый то появляется возможность сэкономить 14 млн руб.
Самое забавное, что за переход отвечали Олег из Подмосковья и Руслан из Екатеринбурга, а рядом держал свечку Питерский наркоман Алексей =)
Как мы в Dropbox перешли с Nginx на Envoy