Состоялся (https://mailman.nginx.org/pipermail/unit/2019-August/000160....) выпуск сервера приложений NGINX Unit 1.10 (http://unit.nginx.org/), в рамках которого развивается решение для обеспечения запуска web-приложений на различных языках программирования (Python, PHP, Perl, Ruby, Go, JavaScript/Node.js и Java). Под управлением NGINX Unit может одновременно выполняться несколько приложений на разных языках программирования, параметры запуска которых можно изменять динамически без необходимости правки файлов конфигурации и перезапуска. Код написан на языке Си и распространяется (https://github.com/nginx/unit) под лицензией Apache 2.0. С особенностями NGINX Unit можно познакомиться в анонсе (https://www.opennet.me/opennews/art.shtml?num=48434) первого выпуска.В новой версии:
- Добавлена начальная поддержка встроенного сервера WebSocket, который пока доступен только для Node.js и скоро появится для Java. Для обработки соединений WebSocket в Node.js следует использовать серверный объект из модуля 'unit-http', например "var webSocketServer = require('unit-http/websocket').server";- Добавлена поддержка выделения PATH_INFO из URI в модуле PHP, что позволяет корректно обрабатывать запросы вида "/app.php/some/path?some=args";
- Добавлена возможность маршрутизации запросов по схеме протокола в URL (HTTP или HTTPS);
- В модуле Java добавлена поддержка multipart-запросов;
- Улучшена совместимость модуля Node.js с выпусками Node.js 11.10+.URL: https://mailman.nginx.org/pipermail/unit/2019-August/000160....
Новость: https://www.opennet.me/opennews/art.shtml?num=51342
Это старый добрый проверенный nginx с расширениями или новый продукт под раскрученным брендом?
Надо щюпать кенешн. Вдруг херак херак и в продакшен
Второе.
третье
и запеканку
А компот?
это новый продукт от создателей старого доброго
Это попытка авторами переосмыслить архитектуру nginx, заложенную в 2002-ом году с учетом 15+ лет опыта и современных реалий. Но не повторять при этом ошибок Apache2, Python3, KDE4 и подобных. А с самого начала зайти сперва с другого угла и не принуждать пользователей мигрировать с одного на другое, параллельно развивая оба продукта.
А ничего, что эти продукты предназначены для совершенно разных задач? Unit это сервер приложений, а не реверс-прокси.
Но nginx в паре с каким-нибудь php-fpm или uWSGI и используются как application server.
С чего вдруг, реверс прокси на фпм делает его аппсервером?
Начальная поддержка раздачи статики и проксирования сейчас в разработке. В следующем релизе осенью уже можно ожидать в примитивном виде с дальнейшим развитием.У нас нет установки на то, что юнит исключительно сервер приложений. Его архитектура закладывалась с учетом возможности эффективно отдавать статику и проксировать.
> Начальная поддержка раздачи статики и проксирования сейчас в разработке.А вот это уже очень интересно! Спасибо за новость.
Внимательно слежу за развитием Nginx Unit, но пока не видел особого смысла в его применении на задачах у меня или моих клиентов. Будем ждать.
nginx это веб-сервер, а не реверс-прокси.
Валентин, а насколько верна моя догадка, что столь удачная архитектура, основанная на shared memory, родилась из костылей вокруг того факта, что когда-то в 2003-м году Сысоев вопреки своему плану действий вместо тредов сделал воркеры, чтобы по-быстрому решить проблему с раздачей статики на рамблер-фотках? :-)
Исходя из этого Игорь с самого начала заложил обработку слущающих сокетов на асинхронных тредах. Там, где у nginx отдельный воркер, у нас просто тред в процессе роутера. С разделяемой между отдельными процессами воркеров памятью в nginx сполна намучались.В юните разделяемая память используется иначе. Она служит исключительно в качестве трубы для передачи данных, а не для хранения состояния. Это избавляет от большинства проблем. Я предложил такую архитектуру с целью устранения накладных расходов на общение с приложениями, когда речь зашла о том, как с ними работать правильно, не теряя асинхронности и изоляции.
А, понятно. Спасибо, интересно.У меня просто было ничем не обоснованное подозрение, что принцип работы Unit-а изначально придуман для nginx plus :-)
С разделяемой памятью - да уж. Мы как-то давно делали свой in house модуль для хитрого кастомного стриминга, я, правда, в основном со стороны наблюдал, но мата было много :-)
А почему в качестве трубы используется разделяемая память? Почему не хватает пары сокетов?
Это новый продукт, но основан на идеях (и частично коде) из nginx.
Старый добрый проверенный nginx с расширениями, нацеленный на использование в качестве сервера приложений, называется OpenResty, и оказался слишком сложен в приготовлении для широких масс интернетостроительной отрасли.
Вы тут под аппсервером имеете в виду луа-скриптинг? У этого очень узкое применение. Луа мало подходит для больших проектов.
Для БОЛЬШИХ проектов вообще ничего не подходит кроме J2EE и Большого Индийского Аутсорса. Но таких проектов в мире не очень много.
Новый костыль, форсируемый новыми хозяевами старого продукта
> корректно обрабатывать запросы вида "/app.php/some/path?some=args";уп-с, оно и этого даже не умело? Верной дорогой идут. Товарищи.
Ну, вообще, fastcgi_split_path_info это не так уж и часто нужная вещь. В основном в легаси коде встречается.
>В основном в легаси коде встречается.А можно глянуть на ссылочки, говорящиее что PATH_INFO стал legacy?
legacy в смысле связки с PHP.Конструкция вида script.php/foo/bar изначально работала только в apache1 mod_php, и никогда не задумывалась как фича, это был просто побочный эффект реализации.
Сделать из этого PATH_INFO придумали уже потом :-)
Имея опыт разработки на php в 2004-2008 годах, я верил, что уж в 2019 этот архаичный способ не нужен и все просто перенаправляют все запросы на index.php, что Unit умел с первых бета-версий.
Код на js у них в unit довольно скверно написан. Никак руки до pr не дойдут. Не исключаю наличие там багов.
Добрый день. Будем рады избавиться от скверного кода. =)
Насколько сильно будете рады? В измеримых величинах.
Приходите, обсудим: https://www.nginx.com/careers/current-openings/?job_id=1723908
Без javascript не отображается.
Отображается без JS, если угодно: https://boards.greenhouse.io/nginx/jobs/1723908
Кстати, а в каком именно месте код скверный? Я глянул - ну да, в 2019 году писать на прототипах, юзать bind вместо современных классов и стрелочных функций немного странно (хотя может там совместимость декларируется до версий ноды 0.12), но в остальном ничего критичного я не заметил.
А что не так в написании кода на прототипах?
Классы в JS - это просто синтаксический сахар над прототипами, для частного случая.Вот сейчас работаю над старым проектом, где все так, и не испытываю абсолютно никаких проблем с этим. Зато работает без транспайлеров в любом недобраузере типа IE.
Классы читаются гораздо проще, чем прототипы, и возможно, имеют некие внутренние оптимизации в движке.
В данном случае никаких "транспайлеров" не требуется - пакет работает на Node.js, где уже давно имеется поддержка классов.
Читаются чуточку проще, согласен. В новом коде так и делаю. Но переписывать легаси смысла не вижу.
Тоже глянул - используются какие-то нативные функции по работе со строками вместо npm leftpad.
Сырой, но перспективный продукт.
Чем больше сырости, тем больше перспективности?
Список продуктов, про которые в 2019 году этого нельзя было бы сказать, исчезающе мал.
Чет америкосы раскочегарились, так и лепят релиз за релизом.
Вот мне нравилась концепция NGINX Unix, но когда пробовал его применять для Go-приложений получалось одно разочарование :(- Проблемы с адаптацией (например, если используешь fasthttp в качестве сервера).
- Производительность снижалась.
- Начинало подвисать. Приходилось либо долго ждать ответа на запрос, либо перепосылать его.Видимо сыроват ещё был. Надо будет в этом году снова попробовать...
Unit уже научился взаимодействовать с nginx через unix socket?
Плюсану. А еще оно ondemand не умеет.
Та хрен с тем ondemand. Из-за отсутствия поддержки unix socket, невозможно его заюзать в хай лод проекте. TCP сокеты и так очень забиты другой нагрузкой.