LINUX.ORG.RU

Новый сервер приложений - Nginx Unit

 


2

6

На конференции NginxConf представлен новый application server - Nginx Unit

Сейчас поддерживаются приложения на языках

  • go
  • php
  • python

Доступны репозитории для rhel/centos и debian/ubuntu

Код проекта с полной историей коммитов доступен на github. Обещают принимать pull request'ы от всех желающих

Официальный сайт: http://unit.nginx.org

GitHub: https://github.com/nginx/unit

Пример настройки + сопряжение с nginx есть в статье на хабре ( https://habrahabr.ru/company/itsumma/blog/337346/ )

Для тех, кто не в теме: application server это не веб-сервер и тем более не reverse proxy. Его задача

  • запуск приложений
  • предоставление к ним доступа ( обычно по протоколу http )

Т.е. это замена не nginx или apache, а php-fpm и uwsgi. И дальний родственник tomcat'а ;)

Конфигурирование Nginx Unit пока сделано, хмм..., довольно необычно, через REST API поверх unix socket

>>> Подробности

★★★★★

Проверено: leave ()

Стоит добавить что также планируется добавить поддержку ruby, java, nodejs

Я правильно понял, что к примеру для ruby это может быть заменой puma или thin или passenger к примеру?

anonymous ()

Ура, товарищи! Больше никаких uwsgi-костылей. Надеюсь.

Конфигурирование Nginx Unit пока сделано, хмм..., довольно необычно, через REST API поверх unix socket

Считается ли запихивание REST туда, где он не нужен, наркотической зависимостью от микросервисов?

AlarinPerfect ★★ ()

Теперь все приложения будут падать и тормозить одновременно, а квотирования, профилирования, изоляции, и статистики не будет? Ну и .so-hell в придачу (или вы серьёзно думаете, что авторы языков переименовывают либы к каждой мажорной версии?)

Я то думал, что будет как в яве: интеграция с IDE, CI, БД конфигов, REST-API с кучей наворотов, веб-морда с графиками, ну и нормальная архитектура: кластер приложений, сервер приложений, контейнер приложений, J2EE-апплеты (ой).

anonymous ()
Ответ на: комментарий от AlarinPerfect

Считается ли запихивание REST туда, где он не нужен, наркотической зависимостью от микросервисов?

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

anonymous ()
Ответ на: комментарий от anonymous

Веб-морда с графиками выделена в отдельный продукт (nginx controller), который будет, вероятно, только для сабов nginx plus. Остальным - рестапи, ну или ждать, пока запилят сторонний опенсорс.

l0stparadise ★★★★★ ()

Пока по фичастости до php-fpm в плане сервера приложений для запуска php-приложений оно, судя по документации, не дотягивает. Если php-fpm позволяет довольно гибко настраивать пул приложения, то тут только количество обработчиков ограничить, судя по документации, пока можно. Надеюсь, со временем настроек у него станет больше. И страница со статистикой по приложениям появится, как у php-fpm.

А конфигурация через REST API выглядит очень интересно. Проект интересный, но пока сырой.

lucentcode ★★★★★ ()
Ответ на: комментарий от l0stparadise

А можно подробнее ? Или нужно самому инет парсить ? :( Просто когда я давно писал что то на го то на выходе получал бины.

Или они хотят на ЭТО дело ложить сразу исходники что ли ? И при каждом изменении файла пересобирать его ?

mx__ ★★★ ()

в питоне есть джанга
джанга прикручивается к обычному нгинсу через mod_wsgi
в юните, как я понимаю, wsgi не нужен ?

и да - зачем гоу какой-то сервер, если гоу - сам сервер ?

kto_tama ★★★★★ ()
Последнее исправление: kto_tama (всего исправлений: 1)
Ответ на: комментарий от loz

Объясните по-хардкору что такое сервер приложений и чем это отличается от примерно всего остального?

Остального это чего ? Апач к примеру сервер приложений.

Вообще есть мысль что из нгниха хотят сделать апач.

mx__ ★★★ ()
Последнее исправление: mx__ (всего исправлений: 1)

в нжинкс забрались эффективные менеджеры: нжинкс всё. жаль, хороший сервачок был. ну я пожалуй обратно на апач поползу

anonymous ()
Ответ на: комментарий от Jopich1

Оно заменят php-fpm и тому подобное. Зачем? Может что-бы не было зоопарка срверов приложений, а может у всех существующих серверов приложений есть фатальные недостатки

MrClon ★★★★★ ()
Ответ на: комментарий от loz

Всё дальнейшее - ИМХО. буду рад услышать альтернативные мнения

reverse proxy - точка между интернетом и веб-серверами. Его задачи

  • демультиплексирование запросов ( то, что называется name based virtual hosts - на один адрес вешается несколько сайтов. reverse proxy распознаёт запрос и прокидывает его к нужному сайту )
  • создание и поддержание TLS сессий ( SSL/TLS довольно дорого для ресурсов сервера. поэтому шифрование обычно идёт между клиентом и reverse proxy, а между reverse proxy и веб-сервером голый http )
  • ограничение нагрузки к веб-серверу ( лимпиты по числу одновременных коннектов, по числу запров в секунду и т.д. )
  • балансировка запросов между backend'ами ( ресурсов одного сервера не хватает. одинаковые веб-серверы поднимаются на нескольких серверах, и reverse proxy балансирует запросы между ними )

веб-сервер предоставляет доступ к веб-сайту целиком. При этом сайт может быть собран из многих отдельных приложений и статики

сервер приложений публикует приложение(я). его не интересует сайт целиком, он не взаимодействует с клиентом непосредственно. Его задача - запускать отдельныые приложения. Т.е. грубо говоря взять код и повесить его на определённый порт

router ★★★★★ ()
Ответ на: комментарий от anonymous

в нжинкс забрались эффективные менеджеры: нжинкс всё. жаль, хороший сервачок был. ну я пожалуй обратно на апач поползу

Ползи, без тебя легче будет. Вменяемые люди способны прочитать пару строк на оффсайте и не нести подобного бреда

nginx unit не входит в nginx. это отдельный проект со своей узкой задачей. И кстати, у nginx конкурент - haproxy, а не apache

router ★★★★★ ()
Ответ на: комментарий от router

демультиплексирование запросов

хостеры будут довольны

нгинх идет по пути развития всевозможных тонких серверных настроек, и все это из коробки

kto_tama ★★★★★ ()
Последнее исправление: kto_tama (всего исправлений: 1)

Очередная попытка создать хайп за счёт хомячков :-) Особенно доставила «поддержка Node.js» в будущем :-) Зачем это надо, если любая Node.js аппликуха спокойно и без проблем работает за реверсивным прокси? :-)

anonymous ()
Ответ на: комментарий от anonymous

Любой язык работает за реверсивным прокси. Да и без реверсивной прокси работает. Если подумаешь, сколько лишних копирований памяти и дублирующихся парсингов происходит при использовании реверсивной прокси, может поймёшь, зачем это надо.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

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

Если подумаешь, сколько копирований памяти надо, чтобы картинка пришла через тонны роутеров от сервера до клиента, то ещё одно копирование от аппликухи до реверсивного прокси погоды не делают :-) Проблемами копирования стращают, обычно, пионэров, которые думают, что это самая великая проблема :-) И проблемы копирования должны решаться всякими SQUID у провайдеров, а не у васьки-стартапера на его VPS :-) Лол :-)

anonymous ()
Ответ на: комментарий от anonymous

Если подумаешь, сколько копирований памяти надо, чтобы картинка пришла через тонны роутеров от сервера до клиента, то ещё одно копирование от аппликухи до реверсивного прокси погоды не делают :-)

Проблемы роутеров это проблемы тех, кто за эти роутеры отвечают, например провайдеров. Проблема твоего сервера это проблема твоего сервера. Если это копирование памяти снижает число возможных запросов с миллиона до 900 тысяч в секунду, а серверов у тебя, скажем, тысяча, то лишних 100 серверов погоду сделают.

васьки-стартапера на его VPS :-) Лол :-)

Ему это не надо, как и nginx в принципе, статику можно и встроенными в ноду средствами отдавать.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

Проблемы роутеров это проблемы тех, кто за эти роутеры отвечают, например провайдеров.

Это проблемы объективной реальности, в которой от сервера до клиента десятка три роутеров :-) На роутерах проблем с копированием нет - они честно выполняют его при передачи данных :-) И никакой nginx unit число роутеров не изменит :-)

Если это копирование памяти снижает число возможных запросов с миллиона до 900 тысяч в секунду, а серверов у тебя, скажем, тысяча, то лишних 100 серверов погоду сделают.

Ага, а если 300 против 330? :-) Какая разница в обслуживании 1000 серверов против 1100, равно как и 300 против 330? :-) Зачем вообще конкретными числами какими-то оперировать? :-) 10% экономии, о которых ты говоришь, - это пшик :-) Лол :-)

Ему это не надо, как и nginx в принципе, статику можно и встроенными в ноду средствами отдавать.

Ну да :-) Зачем тогда этот nginx unit мне не ведомо :-)

anonymous ()
Ответ на: комментарий от Legioner

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

WitcherGeralt ()
Ответ на: комментарий от Radjah

Хуже. Там ведь не заявлено, мол сделали новый in-memory *CGI протокол. Вместо этого предоставляеются какие-то невнятные SDK под несколько избранных языков

makoven ★★★★ ()