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

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

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

php-pfm

Что это? о_О

и нахера он?

Видимо чтоб самим не городить велосипеды.

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

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

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

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

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

php-pfm

Что это? о_О

Очепятки. php-fpm

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

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

Я мало работал с ruby. Насколько я понимаю, да - если добавят поддержку ruby, это будет альтернативой passenger

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

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

Это точно не ошибка ?

Нет, не ошибка. Go-приложения управляются через shared memory.

http://unit.nginx.org/docs-nginx-unit.html#supported-application-languages

application server это не веб-сервер

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

Ну да :-)

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

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

Ну да :-)

Ну может граница не так очевидна. Но вообще разница между nginx и nginx unit примерно та же, что между apache httpd и apache tomcat

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

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

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

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

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

нет, класть надо именно бинарники.

я подробнее не могу сказать, не работаю с go. да и unit пока не накатывал, в выходные буду тестить

Хорошая новость.

Вполне ожидаемо.

Долгих лет проекту!

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

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

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

нет, класть надо именно бинарники.

Упс. Э.... хм. Полез читать инет :(((

Оно не заменяет nginx а ставится рядом ? Зачем тогда это нужно ?

Будут тесты производительности php-fpm vs nginx unit, и если они положительные, то тогда и можно будет попробовать.

Оно не заменяет nginx а ставится рядом ?

да

Зачем тогда это нужно ?

хз

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

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

У апача кстати был mod_perl - там доп сервис не был нужен

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

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

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

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

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

go

Наверное наваяли либу для го, позволяющую обмениваться данными с энжииксом через ipc

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

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

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

Бред какой-то с REST API - т е нужно теперь puppet научить синхронизировать конфиги по REST API ?

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

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

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

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

Ничо так, по-хипстерски.

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

меня тут уже ткнули носом : http://unit.nginx.org/docs-installation.html#building-the-go-applications

... func main() {

http.HandleFunc(«/», handler)

//http.ListenAndServe(":8080", nil)

unit.ListenAndServe(":8080", nil) ...

;))))))))))))))))))))))))))))))

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

В ожидание поддержки ruby ну и elixir

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

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

SQUID у провайдеров

Сдохни.

Сдохни.

Будь счастлив :-)

import {
    "fmt"
    "net/http"
    "unit"
}

Эй, unit уже стал стандартным модулем?

В смысле ? Вообще то они подменяют собой встроенный в го хттп сервер.

Да я-то понимаю разницу. Но из текста новости это нифига не очевидено :-)

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

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

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

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

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

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

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

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

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

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

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

Чет у меня комикс про 15 стандартов в памяти всплывает от этой новости.

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