Игорь Сысоев представил (http://mailman.nginx.org/pipermail/unit/2017-October/000009....) второй публичный выпуск сервера приложений NGINX Unit (http://unit.nginx.org/), в рамках которого развивается решение для обеспечения запуска web-приложений на различных языках программирования. NGINX Unit обслуживает отдачу динамического контента самостоятельно, но также может работать (http://unit.nginx.org/docs-integration-with-nginx.html) в тандеме с http-сервером nginx, который может выступать в роли балансировщика, кэша или сервера для отдачи статического контента. Проект пока находится на стадии бета-тестирования и не рекомендован для промышленного использования. Код написан на языке Си и распространяется (https://github.com/nginx/unit) под лицензией Apache 2.0.
NGINX Unit предоставляет возможность динамического изменения параметров запуска приложений через специальный RESTful JSON API (http://unit.nginx.org/docs-configuration.html), без необходимости правки файлов конфигурации и перезапуска (ответ на потребность пользователей nginx в возможностях ".htaccess"). Особенностью реализации является то, что изменение настроек не приводит к перезапуску рабочих процессов - меняются только содержимое структур в памяти, что сводит к минимуму накладные расходы и позволяет менять параметры с любой интенсивностью. RESTful API
позволяет управлять работой сервера приложений удалённо и централизовано. Доступ к API может быть организован через UNIX domain socket или TCP.Одновременно под управлением NGINX Unit может выполняться несколько приложений на разных языках программирования, в том числе могут сочетаться разные версии языков (например, PHP 5 и PHP 7, Python 2.7 и Python 3.3). В настоящий момент поддерживаются Python, PHP и Go. NGINX Unit обеспечивает изоляцию компоентов - под root выполняется только управляющий процесс, а обработчики запускаются под отдельными пользователями.
В новом выпуске улучшена поддержка пакетов на языке Go, добавлен режим постоянного сохранения конфигурации, улучшена обработка ошибок в конфигурации, добавлено свойство для установки таймаута выполнения запроса приложением, налажена обработка POST-запросов в приложениях на PHP. Из планов на будущее отмечается поддержка JavaScript/Node.js, Java и Ruby, возможность динамического управления процессами приложений, поддержка TLS и средства для маршрутизации и проксирования вызовов для TCP, HTTP, HTTPS, HTTP/2.
URL: http://mailman.nginx.org/pipermail/unit/2017-October/000009....
Новость: https://www.opennet.ru/opennews/art.shtml?num=47423
Выглядит интересно, конечно.
Чем конкретно? Или так, просто чтоб камент запостить?
Ну давай расскажи нам в чем такая информотивность твоего коммента? Или это так просто чтобы флейм тут устроить?
>Выглядит интересно, конечно.Выглядит как будто они изобрели J2EE 1.0 (1999 года) в 2017-м году.
С учетом того, что jEE таки взлетело и летит уже 20 лет, а разрабатывать на си в разы медленнее, судьба этого "сервера приложений" немного предсказуема. Хотя, так понимаю, нашлись богатые буратинки-инвесторы, прогеры довольны, несколько лет без работы не останутся.
Оно не нужно когда есть uwsgi
Судя по документации сабж как раз и обслуживает питоновые приложения через uwsgiНа первый взгляд, это не замена uwsgi, а скорее замена supervisord и, пожалуй, немного gunicorn, умеющая интегрироваться с инжинкс до кучи.
В целом интересная штука.
uwsgi - это сервер приложений, wsgi это интерфейс для интеграции сервера приложений и самого приложения. nginx unit не может работать через uwsgi, потому что он является альтернативой uwsgi. И пока не очень понятно, чем эта альтернатива лучше.
А еще uwsgi это бинарный протокол http://uwsgi-docs.readthedocs.io/en/latest/Protocol.html
> Выглядит как будто они изобрели J2EE 1.0 (1999 года) в 2017-м году.Хорошо, что джавва теперь не нужна. 2017ый же, ты заметил! А пхп-питон нужны, два раза. Инвесторы уверены[I]!
>Хорошо, что джавва теперь не нужна...А мужики-то не знают. Продолжают клепать свой никому не нужный энтерпрайз и даже не догадываются про 2017 год.
Не ломай уютный мир экперта по всем вопросам.
Ну про "J2EE 1999г" и 2017 - он прав. Все Ынтерпрайз жабы нынче на Spring-е :)
> Все Ынтерпрайз жабы нынче на Spring-е :)Брэхня! И отучаемся говорить за всех.
> Выглядит как будто они изобрели J2EE 1.0 (1999 года) в 2017-м году.Это точно, хотя уже через пару лет жабисты заметили что много приложений под одним сервером нужно только домашним страничкам. А во всех серьёзных проектах всегда только одно приложение на весь сервер, и на всю JVM. Поэтому Tomcat не нужен.
Так что для домашних страничек может и полезно будет. Хотя посмотрим, ведь " Код написан на языке Си" -- сколько там дыр будет везде и повсюду.
> Хотя посмотрим, ведь " Код написан на языке Си" -- сколько там дыр будет везде и повсюду.Закрой код и вам пох....ю будет.
>хотя уже через пару лет жабисты заметили что много приложений под одним сервером нужно только домашним страничкам.судя по мега квалифицированному утверждению - с лора человек пришёл.
ИНтересно чем? Тем что они идут явно мутными схемами с конфигурированием?
Согласен, зелёная тема выглядит интересной.
Это можно сделать что-то похожее на Apache + PHP?
> Это можно сделать что-то похожее на Apache + PHP?нет, поскольку, вопреки заявленному в новости, ничего похожего на .htaccess как не было, так и нет.
Ни "динамического", ни какого либо еще.
Что-то похожее на php-fpm, но без php-fpm. Зачем - неясно.
Ну почему без. Можно в качестве этого самого "сервиса приложений" использовать, видимо. Просто у Сысоева маниакальная потребность рулить чуть ли не каждым битом в хттп-запросе. Многим нравится.
> Ну почему без.он там не используется, эта штука сама себе fpm и сама себе, видимо, uWSGI (а вот go придется руками патчить чтобы вместо net.http он использовал протокол этого чуда)
кстати, во втором случае оно даже выглядит в теории несколько менее ненужно - пихоновский хреново документированный и совершенно загадочный для человека не в теме скрипт с миллиардом командных параметров у меня никогда не вызывал восторгов (php-fpm, понятно, ничем не лучше, но как-то уже привыкли все).
А вот какой смысл заменять в go net/http на какой-то другой интерфейс "использующий shared mem", но все равно общающийся с веб-сервером еще через один сокет - загадка.
В принципе, там настолько много всякого coming soon, что, возможно, мы пока недопонимаем всей глубины затеи.
но зачем было выкладывать полудописанный код, если даже внятно объяснить его назначение не можешь (я даже, поборов отвращение, запустил видео - но там просто пересказывается документация, без всяких попыток объяснить, нахрена ж нам это щастье)
Да почти наверняка "чудо" - это некая хрень буферизирующая и распределяющая потоки всё в те же сокеты(ну или IPC), врядли они сумеют сварганить столь низкоуровневые библиотеки что для пхп, что для го, косяков не оберёшся. Будет всё аффигено управляемо, сбалансировнно, оптимизированно, во главе чего будет сидеть ацкий админ и выверять параметры с точностью до полбита.
> врядли они сумеют сварганить столь низкоуровневые библиотеки что для пхп, что для гоони используют стандартные - что для пехепе, что для go. И стандартную же libpython.
Ничего военного в самостоятельной реализации на их основе fpm'а, uwsgi и просто запускалки дочернего процесса для go (вроде ему больше ничего и не надо) нет.Аналогичные модули для апача и то сложнее было написать, поскольку они не изолированы в отдельном "unit", и им приходится жить среди апачевских корявых потрохов и по их правилам.
но вот нафига оно нужно, переизобретение велосипеда - пока совершенно не видно.
> они используют стандартные - что для пехепе, что для go. И стандартную
> же libpython.
> Аналогичные модули для апача и то сложнее было написать, поскольку они не
> изолированы в отдельном "unit", и им приходится жить среди апачевских корявых
> потрохов и по их правилам.
> но вот нафига оно нужно, переизобретение велосипеда - пока совершенно не видно.Впечатление, что они создали спрос на фичи апача, упростив их 'away' в nginx, и теперь _удовлетворяют запрос рынка_. %)))
.htaccess, mod_php, jee-coming-soon и т.д.
> Впечатление, что они создали спрос на фичи апача, упростив их 'away' вони и в апаче были весьма относительной нужности, создавая больше проблем чем решая.
Исключая как раз .htaccess, смысла которого Сысоев, работавший в закрытом аквариуме рамблера, видимо, совершенно искренне не понимает.Но он скоро тоже и в апаче станет ненужен - он был нужен для двух вещей - переносимости кривых поделок, чтоб ее можно было закатать таром и раскатать на совершенно другом хосте, с совершенно другими настройками - и те, что ей нужны, она при этом принесла с собой.
И для shared hosting, где разным пользователям настройки нужны разные, а бегать за ними всеми собирать с них предложения, админ не может.Первое разработчики делать разучились, им теперь непременно нужно нагадить в целую кучу всяких разных /etc/*/*.d/ , "а если тебе не нравится - используй докер", второе вымирает, заменяясь всякими aws.
> но вот нафига оно нужно, переизобретение велосипеда - пока совершенно не видно.Ещё вариант: войти в реку "упрощения" дважды. nginx _когда-то_ был прост и невелик, и быстр, а апач всё рос и ро-о-ос. апач по-прежнему рОстет -- уже пора делать "ма-а-ахонькие" mod_php и ко., решили ребята в маркетингах.
Туда же: у каждого языка, который "ходил" в торону большого веба есть свой апп.сервер, на себе самом обычно, те же обычные, как везде, фаст-старты и (?)сокет-mux-ы... Таки, может, если их всех "упростить" до одной апп-пускалки, то...
> Туда же: у каждого языка, который "ходил" в торону большого веба есть
> свой апп.сервер, на себе самом обычно, те же обычные, как везде,
> фаст-старты и (?)сокет-mux-ы... Таки, может, если их всех "упростить" до
> одной апп-пускалки, то...то зачем? Запускать на одном и том же хосте разом go, пихон и пехепе ? Их наоборот хочется растащить друг от друга как можно дальше, даже если они все на пехепе, и даже, так случается, одной и той же версии. (кстати, а разные версии пихона оно, походу, нишмагло? Или авторы не знают о том, что они разные?)
В современном мире, где виртуализация "дешева", а контейнеры вообще "ничего не стоят" (обе фразы в кавычках неверны, но инвесторам на самом деле пох) - оно в общем давно именно так у всех и делается. И выковырять ЭТО обратно из контейнера уже и невозможно в принципе.
выглядит как привет из 90х в виде cgi
Не, пока как раз выглядит бесполезно. Что такое "обработчик пхп"? Php-fpm? Ок, а нафига нужен еще один сервер, если за ним все равно php-fpm?
Похоже что ему Php-fpm не нужен вовсе, и вполне достаточно libphp-embed
А... тогда понятно, Сысоев изобрёл свой вариант уберкомбайна типа Apache, просто обработчики рассадил по дочерним процессам, а не держит в одном (это-то правильно, конечно).Ну, фиг знает. Все уже вроде ушли от этой концепции как раз - вроде все уже сошлись на том, что standalone / отдельные легковесные сервера под каждое приложение - лучше.
> А... тогда понятно, Сысоев изобрёл свой вариант уберкомбайна типа Apache, просто обработчики
> рассадил по дочерним процессам, а не держит в одном (это-то правильно,
> конечно).
> Ну, фиг знает. Все уже вроде ушли от этой концепции как раз
> - вроде все уже сошлись на том, что standalone / отдельные
> легковесные сервера под каждое приложение - лучше.Лучше, когда у вас мало приложений. Если их сотни и тысячи, отдельные сервера будут создавать накладные расходы.
А это актуально по факту только в шаред хостинге осталось...
а смысл? всё равно один воркер-пхп-процесс на один запрос, чем пхп-фпм хуже ?
ну надеюсь они в теме что пап отключает опкеш если оно ембед и в sapi стоит что либо отличное от apache
Судя по всему есть желание создать более-менее работающий сервер позволяющих деплоить приложения не под jvm с возможностью поддержки встроенных сервисов.
Не могу понять в чем принцип Юнита. Я вроде бы точно так же могу запускать одновременно виртуалхосты с php5, php7, passenger и в обычном nginx. Зачем тогда Юнит?
Принцип в том, чтобы выкинуть апач, заменив его предсказуемым и надёжным сервером приложений, отвечающим требованиям промышленного использования.
Апач достаточно предсказуем и легко настраивается. Но он наказывает за незнание и ошибки слишком сильно, чтобы с ним рисковать. Да и ресурсов потребляет как не в себя.
это открытый сервер приложений построенный по способу работы nginx, можно его использовать как standalone или embedded. вполне нормальная и хорошая реализация на СИ. вспомните бредоизвестный G-WAN непонятной реализации с многообещающим перформансом.
> это открытый сервер приложений построенный по способу работы nginxУ nginx-а способ работы - мультиплексирокание кучи ядрёных сокетов одним процессом. И условие: "быстрые/короткие/живые соединения".
Как это всё отнести к "серверу приложений" -- не вижу. Инвесторы умнее и проницательнее меня, наверное. Они будут в восторге от серебряной пули, ускоряющей apache-и...
>, можно его использовать
> как standalone или embedded. вполне нормальная и хорошая реализация на СИ.
> У nginx-а способ работы - мультиплексирокание кучи ядрёных сокетов одним процессом.Подозреваю, что здесь что-то похожее.
> Процесс маршрутизации в свою очередь состоит из координатора запросов и рабочих нитей, которые принимают запросы клиентов, направляют их web-приложениям и возвращают ответ. Каждая рабочая нить может работать в асинхронном режиме и обслуживать тысячи одновременных соединений.
>>это открытый сервер приложенийнет!
>Особенностью реализации является то, что изменение настроек не приводит к перезапуску рабочих процессов - меняются только содержимое структур в памяти, что сводит к минимуму накладные расходы и позволяет менять параметры с любой интенсивностью.Если это относится только к внутренней кухне unit, то Сысоев конечно открыл Америку - оказывается не обязательно все перезапускать на каждый чих в 2017 году. А если это относится и к параметрам запуска приложений - хотелось бы посмотреть на реализацию.
Все нобт и говорят, что это не нужно, и вообще уже было в 99. А я чувствую себя, как с другой планеты. Лично мне уже надоело костылявить с динамической конфигурацией nginx (на сотнях сайтов даже тупо reload уже начинает выполняться несколько секунд). Вот те, кто говорят, что это не нужно, вы как сами обеспечиваете динамическую (автоматическую) конфигурацию nginx?
Они говорят, что динамическая конфигурация nginx... та-дам!.. не нужна!
"Работает - не трогай" и все такое.
> Все нобт и говорят, что это не нужно, и вообще уже было
> в 99. А я чувствую себя, как с другой планеты. Лично
> мне уже надоело костылявить с динамической конфигурацией nginx (на сотнях сайтов
> даже тупо reload уже начинает выполняться несколько секунд). Вот те, кто
> говорят, что это не нужно, вы как сами обеспечиваете динамическую (автоматическую)
> конфигурацию nginx?А ты что, серьёзно руками админишь сервак с сотней сайтов?
Как раз нет, не вручную. О чём, собственно, и говорилось, если вы внимательно читали. Именно с точки зрения автоматизации NGINX Unit и кажется потенциально более прямым решением.
Все эти REST'ы и вебсервисы - тyп0й сакс, придуманый от слабоумия. Обычный TCP-сервер прекрасно работает - тот же FTP или SMTP.
Если тебе нужно выполнить 10 команд, не имеет никакого значения, будешь ты отдавать их в одну TCP сессию или делать 10 отдельных запросов. Только в последнем случае ты сразу имеешь геморой с подтверждением сессии (что второй запрос пришёл в контексте первого) и оверхэд в виде @е6ильных HTTP-хэдеров. Ну и смысл?? ВСЕ ДЕСЯТЬ команд должны выполниться, так что сервер по-любому будет всеми ими нагружен. Ну и чего вы добиваетесь своими веб-перделками??
хотелось бы посмотреть на твои достижения
Если тебе нужно продавать площадку, то продавать её выгодней только порезав на как можно больше кусочков.
> Все эти REST'ы и вебсервисы - тyп0й сакс, придуманый от слабоумия.Бузинесы раз-вы-инкорпорируешь, ещё не так раскорячишься.
REST действительно переоценен, при этом единственной умной там штукой - HATEOAS - никто не пользуется. А с GraphQL и прочими JSON-RPC все хорошо. Причем там, как раз, HTTP(S) - это тупо транспортный протокол, и легко заменяется на любой другой.Остается вопрос, при чем тут Nginx Unit.
> единственной умной там штукой - HATEOAS - никто не пользуется.Ахаха. HATEOAS это лютая хрень, которая в реальной жизни не работает. И судя по высказыванию, Вы ни разу не пытались сделать что-то в духе hateoas, иначе сразу бы поняли это.
А с REST всё отл.
> Обычный TCP-сервер прекрасно работает - тот же FTP или SMTP.но есть один ньюанс: в пехепе, жабке, libcurl - есть, в принципе, и ftp, и даже местами smtp - а вот snginxp - нету. Поэтому если ты изобретешь еще один ненужно-протокол, веб-кодиры не будут знать, что им с него пользы.
Одно дело - просто заполнить поля в структурке и дернуть интуитивно-приятный, а главное - уже давно выученный апи. Совсем-совсем другое - самостоятельно строить хотя бы даже smtp-like сессию (с авторизацией, с защитой от подмены, с обработкой всех возможных ошибок, от таймаутов на любой стадии протокола (обрабатываемых по разному!) до rogue server, самостоятельно сооружать для нее синтаксические конструкции (помня о возможностях injection!) и самостоятельно парсить ответы (и смотри не перепутай с полями самого протокола!)
А что http и REST для этой супер-задачи (да практически для всех задач где используют) что-то вроде робота-марсохода, забивающего банальный гвоздь в метре от тебя (но сигналы управления идут через марсианский ретранслятор, чтоб жизнь не казалась медом) - всем пoх.
Совершенно плевать, сколько там слоев и чего понаворочено ради команды "забить гвоздик", когда можно нажать кнопочку и наслаждаться результатом, а не идти в магазин за микрос...э...как эта штука называется? а-а-а, молоток, что-ли?
"а других разработчиков у меня для вас нет".
Родина дала им FastCGI - пользуйся! Не хотим, хотим монолитный комбайн.
Комбайн - это удобно.
А когда тебе нужно админить сотню-другую контейнеров, удобство перевешивает любую философию.
поэтому комбайн в виде апача заменили на нгиникс?
Да, двадцать лет спустя доросли до уровня JEE 2.0. Ну почти доросли.
пока росли, jee успело сдохнуть и осталось разлагаться в у терпил, швыряющих миллиарды на ветер
Подыхать jee будет ещё очень долго. А пока это 2/3 всего платежеспособного рынка. И чем больше миллиардов на этот "рынок" выбрасывают "терпилы", тем лучше.
Просто пытло-скриптеры не понимают того простого факта, что когда помре ява помре любая разработка ПО, в которой в принципе участвует человек.
> Подыхать jee будет ещё очень долго. А пока это 2/3 всего платежеспособного рынка. И чем больше миллиардов на этот "рынок" выбрасывают "терпилы", тем лучше.
> Просто пытло-скриптеры не понимают того простого факта, что когда помре ява помре любая разработка ПО, в которой в принципе участвует человек.http://danlik.ru/wp-content/uploads/2014/09/Fantazjory.-Niko...
Java is neither supported nor planned?
Not needed.
Типа универсальная фигня, которая может запускать что угодно...
Только для каждого из этих "что угодно" уже давно есть нормальные нативные методы.
Зачем пытаться собрать их в кучу - не понятно.
Если бы это было как модуль nginx'а "искаропки", то может и был бы смысл.
Да что вам тут все в комментах непонятно. Как дети.
Нужен он затем чтобы сделать еще один paas и брать бабки. Отсюда и его "особенности".
> Нужен он затем чтобы сделать еще один paas и брать бабки.и кто понесет-то? те, кто ниасилили настроить php-fpm ? те кто асилили, но слегка затрахались (вообще-то там начинаются чудеса, когда система сложная и нагруженная - но там где они начинаются, у этого проекта пустое место вообще) ?
мы ж тоже хотим из г-на на курорт, и пытаемся угадать, где деньги.
в случае с коммерческим nginx вопрос ясен - бабки платят за латание твоих дыр в приоритетном порядке, а не когда-если ты убедишь Максима, и за некоторые фичи, полезные для больших проектов, тоже в приоритетном порядке, а не когда большие уже наиграются.
Почему нет, у нас тоже был логин для Сысоева в ядро системы - что-то, по результатам, вернули в апстрим, что-то он сам поправил. Если за это можно заплатить - почему же не заплатить, деньги ведь дядины, мне их в зарплату все равно не отдадут.но для этого сперва надо было написать такой nginx, чтобы им все захотели пользоваться, вместо апачей и всяких там недоhttpd, и десять лет как папа карла его развивать и поддерживать. А тут ничего похожего. Даже жаба только "coming soon".
так никто и не говорит что Unit 0.2 это готовый продукт! это даже не предрелизная версия...
эхх, сейчас бы альфа-версии ПО за недостаток функционала хаить.
