Представлен (http://mailman.nginx.org/pipermail/unit/2019-March/000118.ht...) выпуск сервера приложений NGINX Unit 1.8 (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) первого выпуска.
Новый выпуск примечателен добавлением (https://unit.nginx.org/configuration/#java-application) поддержки языка Java с возможностью запуска сервлетов (Java Servlet 3.1, JSR-340). Кроме того в Unit 1.8 появилась начальная поддержка (https://unit.nginx.org/configuration/#routes) внутренней маршрутизации запросов между слушающими сокетами и приложениями. В настоящее время поддерживается простое сопоставление по маскам с использованием в качестве критериев проброса имени хоста, URI или HTTP-метода. В будущем обещают добавить поддержку регулярных выражений и проброс по произвольным HTTP-заголовкам, cookie, исходному и целевому адресам.
{
"match": {
"host": [ "*.example.com", "!php7.example.com" ],
"uri": [ "/admin/*", "/store/*" ],
"method": "POST"
},"action": {
"pass": "applications/php5_app"
}
}Начиная с текущего выпуска также задействован новый формат нумерации версий, вместо формата "x.y", теперь будут использоваться номера "x.y.z", где "z" номер корректирующего обновления.
URL: http://mailman.nginx.org/pipermail/unit/2019-March/000118.ht...
Новость: https://www.opennet.me/opennews/art.shtml?num=50230
Кто понимает зачем этот unit нужен? Почему я должен отказаться от websphere?
Пилить деньги инвесторов, изображая бурную деятельность. Видимо продажи nginx-plus перестали расти, а напоминать о себе надо.
nginx-plus слишком дорог для массового использования и обучения. Пусть остается в своих Enterprise.
Для массового использования есть опенсорсная версия. В плюсе нет ни одной фичи, которые нужны не ентерпрайзу.
health checks
least_time
upstream dynamic
upstream-server-resolve
JWT
что из этого нужно НЕ энтерпрайзу?
health checks
least_time
JWT?
HAProxy?
Более 100 метрик по апстримам
+ архитектурно более производительный, чем nginx
Думаю что ваш websphere, tomcat, jboss, wildfly(нужное подчеркнуть) не удобно использовать в контейнеризации и динамическом масштабировании, деплоях canary и blue-green, и ну каких то ещё случаях.
Для контейнерного деплоя war уже давно есть wildfly-swarm и иже с ними. Должна же быть киллер-фича у unit какая-то
> Должна же быть киллер-фича у unit какая-то+ легковесность
+ параллельная динамическая поддержка и обслуживание различных приложений (Python, PHP, Perl, Ruby, Go, JavaScript/Node.js и Java)
+ конфигурация/переконфигурация на лету (zero downtime)
Так это стандартный набор, я это могу и на nginx сделать или haproxy
> Так это стандартный набор, я это могу и на nginx сделать или
> haproxyинтересно как запустите Java приложение в nginx? запустите отдельно 1 экземпляр nginx и через upstream настроите работу с другим java server'ом (tomcat, jboss, wildfy и т.д.). в итоге у вас 2 сервера работают.
теперь возьмите 1 экземпляр unit и настроив модуль (python, php, go, java и т.д) этот 1 сервер будет обслуживать указанные вами языки независимо друг от друга и без лишних бэкенд серверов типа
(gunicorn, apache, tomcat и т.д.)One unit to route them all ;)
чтобы не быть многословным, просто возьмите и попробуйте сами поиграть и посмотреть разницу.
Точки старта:
1- http://unit.nginx.org/#demo
2- https://www.nginx.com/blog/nginx-unit-updating-apps-with-100.../
А вы хотите unit без load balancer в интернет выставлять?
> А вы хотите unit без load balancer в интернет выставлять?пока что нет, пока unit не приобретет нужные фичи: TCP, HTTP, HTTPS, HTTP/2 routing and proxying (coming soon)
О да, то что раньше делали админы за вечер теперь хотят продавать как продукт.
> О да, то что раньше делали админы за вечер теперь хотят продавать
> как продукт.если бы за вечер, зачастую админ может и до утра просидеть запуская и настраивая различные среды специфичных приложений (учитывая что многие горе админы кроме апача ничего не видели)
> теперь хотят продавать
> как продукт.он открытый и бесплатный, берите и используйте как хотите
лучше ковырять унит, че м скрипты напианные предыдущим васяном за вечер
> + легковесностьЕсли у меня уже enterpise java (war), то 10мб туда, 10мб сюда роли не играет
> + параллельная динамическая поддержка и обслуживание различных приложений (Python, PHP, Perl, Ruby, Go, JavaScript/Node.js и Java)
Если я уже пишу на java, зачем мне все вот это вот убогое (кроме go)? В крайнем случае я запихну в докер убогое, а не буду пытаться запускать java war в unit.
> + конфигурация/переконфигурация на лету (zero downtime)
О какой конфигурации идет речь? Unit знает о том как пул соединений внутри java процесса пересоздать? Сомневаюсь. Вся это переконфигурация с первых версий Java серверов приложений работает (wildfly, websphere, etc).
> О какой конфигурации идет речь? Unit знает о том как пул соединений внутри java процесса пересоздать? Сомневаюсь.Никакого пула соединений в Java процессе нет. Как и в случае других языков в Unit, обработкой соединений занимается не процесс приложения, а отдельный процесс-маршрутизатор - эффективное, асинхронное ядро юнита (похожее на nginx, только новее). Он работает с соединениями, а приложение уже забирает из очереди готовые для обработки запросы. Поэтому мы можем позволить себе и перезапуск приложения без разрыва соединений.
> Если у меня уже enterpise java (war), то 10мб туда, 10мб сюда
> роли не играетесли бы у вас был enterprise, вы бы тут не сидели и не читали ;) ждали бы support от поставщика ;)
если по теме, сравните комбайны jboss, wildfly, paraya, glassfish и т.д. unit не пытается завоевать места этих гигантов, а предоставляет легкий и быстрый способ в век микросервисов, пусть хоть пока что неполный функционал этих гигантов.а разница между гигантами не какие-то 10мб ;) если таким макаром рассуждать зачем ant, maven, gradle и так далее нужны, давайте олдскульно работать ;)
> Если я уже пишу на java, зачем мне все вот это вот
> убогое (кроме go)? В крайнем случае я запихну в докер убогое,
> а не буду пытаться запускать java war в unit.микросервисы не Docker'ом едины, есть куча еще вариантов ;) что там war, вы можете jar без каких либо серверов запустить.
> О какой конфигурации идет речь? Unit знает о том как пул соединений
> внутри java процесса пересоздать? Сомневаюсь. Вся это переконфигурация с первых версий
> Java серверов приложений работает (wildfly, websphere, etc).вам уже ответили со стороны разработчиков ;)
вы уже сами плывете с connection pooling, речь идет о конфигруации самого сервера unit. тут не нужно перезапускать демон unit постоянно, когда вы добавляете или удаляете приложения, меняете порты и т.д. попробуйте это сделать с традиционными серверами ;)
В новостях про предыдущие версии Юнита многие задавали вопрос "когда же, наконец, будет поддержка Java?". Давайте у них спросим.
> В новостях про предыдущие версии Юнита многие задавали вопрос "когда же, наконец,
> будет поддержка Java?". Давайте у них спросим.конструктивное предложение, поддерживаю ;)
со своей стороны, как java'вист с другой стороны, могу сказать почему интересен unit с поддержкой java: это то что нравится легкая архитектура (меньше файлов, использование памяти и процессора) и механизм обслуживания запросов (event-driven) что унаследовано от nginx.
> и механизм обслуживания запросов (event-driven) что унаследовано от nginx.так там же сервлеты, это спека один поток на запрос, какой event-driven? или они может захачили jvm?
хочешь event-driven: netty, undertow, ktor
> так там же сервлеты, это спека один поток на запрос, какой event-driven?
> или они может захачили jvm?какие сервлеты в 2019 году?
вы вообще понимаете о чем идет речь? речь идет об обработки сервера запросов со стороны клиента.> хочешь event-driven: netty, undertow, ktor
ну дык это фреймфорки, над которыми нужно еще посидеть подумать хорошо и реализовать свой сервер. никто не мешает их использовать :)
>Почему я должен отказаться от websphere?Потому что шпринг+кубернатес (а не этот смехотворный Unit).
Я сам ещё держусь за жбосс, но это уже трепыхания.
Даже смешно, что кто-то пилит новый сервер приложений на си, когда эта концепция уже несколько лет как в упадке.
кто-нибудь использует в продакшн?
> кто-нибудь использует в продакшн?на стадии тестирования (используем php и python), лично используем в нашей внутренней кухне. думаю как будет production ready, можно выходить.
теперь вот будем с поддержкой java, как говориться посмотреть ;)
uWSGI не пробовали использовать?
> uWSGI не пробовали использовать?используем, по его прямому назначению для python. но всегда смотрим на новые вещи и инновации в технологиях ;)
Бесперспективный путь: последняя спецификация - Servlet 4.0 (JSR 369) от Sep 2017
Очевидно, что разработчики Unit уже сильно отстали. Разумно пилить коннекторы (типа AJP) и не пытаться объять необъятное.
QuickBasic будет?
Это хорошо, что nginx-unit развивается и добавляет в себя новые языки программирования. Касательно чисто Java - посмотрим, во что оно выльется. Серверные приложения на Java часто используют кучу библиотек для различных целей - в БД сходить, ещё где-то что-то написать. И многие из них не заточены под асинхронный ввод-вывод, а написаны вполне себе для "блокирующего ввода-вывода". Плюс часто идёт контекстно-зависимая информация (зависящей от текущего потока исполнения - ThreadLocal). Слишком много всего (легаси).А с точки зрения "написания с нуля" Java слишком многословна по сравнению с другими языками.
Как тут уже заметили, выбор Servlet - это тупик. Но не из-за версии (AsyncContext появился ещё в Servlet 3.0), а из-за всего API. Лучше брать JBoss Netty (https://netty.io/) - вот это реально моща для таких приложений (event based io, async и всё такое).