The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Доступен сервер приложений NGINX Unit 0.2

20.10.2017 09:55

Игорь Сысоев представил второй публичный выпуск сервера приложений NGINX Unit, в рамках которого развивается решение для обеспечения запуска web-приложений на различных языках программирования. NGINX Unit обслуживает отдачу динамического контента самостоятельно, но также может работать в тандеме с http-сервером nginx, который может выступать в роли балансировщика, кэша или сервера для отдачи статического контента. Проект пока находится на стадии бета-тестирования и не рекомендован для промышленного использования. Код написан на языке Си и распространяется под лицензией Apache 2.0.

NGINX Unit предоставляет возможность динамического изменения параметров запуска приложений через специальный RESTful JSON API, без необходимости правки файлов конфигурации и перезапуска (ответ на потребность пользователей 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 образует несколько процессов: процесс управления конфигурацией, основной процесс для запуска обработчиков web-приложений и многопоточный процесс для маршрутизации вызовов, транслирующий внешние запросы к web-приложениям. Процесс маршрутизации в свою очередь состоит из координатора запросов и рабочих нитей, которые принимают запросы клиентов, направляют их web-приложениям и возвращают ответ. Каждая рабочая нить может работать в асинхронном режиме и обслуживать тысячи одновременных соединений. Под root выполняется только главный управляющий процесс, а все остальные обработчики запускаются под отдельными непривилегированными пользователями.

В новом выпуске улучшена поддержка пакетов на языке Go, добавлен режим постоянного сохранения конфигурации, улучшена обработка ошибок в конфигурации, добавлено свойство для установки таймаута выполнения запроса приложением, налажена обработка POST-запросов в приложениях на PHP. Из планов на будущее отмечается поддержка JavaScript/Node.js, Java и Ruby, возможность динамического управления процессами приложений, поддержка TLS, средства для маршрутизации и проксирования вызовов для TCP, HTTP, HTTPS, HTTP/2.



  1. Главная ссылка к новости (http://mailman.nginx.org/piper...)
  2. OpenNews: Увеличение пропускной способности и минимизация задержек на серверах с nginx
  3. OpenNews: Yandex опубликовал статический анализатор файлов конфигурации nginx
  4. OpenNews: Релиз HTTP-сервера nginx 1.12.0
  5. OpenNews: Root-уязвимость из-за некорректных настроек в пакете nginx для Debian и Ubuntu
  6. OpenNews: Увидел свет HTTP-сервер nginx 1.10.0
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/47423-nginx
Ключевые слова: nginx, unit
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (69) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, dkg (?), 10:40, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Выглядит интересно, конечно.
     
     
  • 2.2, Фуррь (ok), 10:43, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Чем конкретно? Или так, просто чтоб камент запостить?
     
     
  • 3.71, андрей (??), 11:20, 26/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну давай расскажи нам в чем такая информотивность твоего коммента? Или это так просто чтобы флейм тут устроить?
     
  • 2.5, лютый жабист__ (?), 10:55, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • –10 +/
    >Выглядит интересно, конечно.

    Выглядит как будто они изобрели J2EE 1.0 (1999 года) в 2017-м году.

    С учетом того, что jEE таки взлетело и летит уже 20 лет, а разрабатывать на си в разы медленнее, судьба этого "сервера приложений" немного предсказуема. Хотя, так понимаю, нашлись богатые буратинки-инвесторы, прогеры довольны, несколько лет без работы не останутся.

     
     
  • 3.7, username (??), 11:00, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Оно не нужно когда есть uwsgi
     
     
  • 4.12, jOKer (ok), 11:34, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Судя по документации сабж как раз и обслуживает питоновые приложения через uwsgi

    На первый взгляд, это не замена uwsgi, а скорее замена supervisord и, пожалуй, немного gunicorn, умеющая интегрироваться с инжинкс до кучи.

    В целом интересная штука.

     
     
  • 5.28, Аноним (-), 14:57, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +6 +/
    uwsgi - это сервер приложений, wsgi это интерфейс для интеграции сервера приложений и самого приложения. nginx unit не может работать через uwsgi, потому что он является альтернативой uwsgi. И пока не очень понятно, чем эта альтернатива лучше.
     
     
  • 6.45, Blind Vic (ok), 21:21, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А еще uwsgi это бинарный протокол http://uwsgi-docs.readthedocs.io/en/latest/Protocol.html
     
  • 3.10, Andrey Mitrofanov (?), 11:28, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Выглядит как будто они изобрели J2EE 1.0 (1999 года) в 2017-м году.

    Хорошо, что джавва теперь не нужна. 2017ый же, ты заметил!  А пхп-питон нужны, два раза.  Инвесторы уверены[I]!

     
     
  • 4.13, Аноним (-), 11:37, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Хорошо, что джавва теперь не нужна...

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

     
     
  • 5.23, Аноним (-), 13:17, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Не ломай уютный мир экперта по всем вопросам.
     
     
  • 6.43, _ (??), 19:59, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну про "J2EE 1999г" и 2017 - он прав. Все Ынтерпрайз жабы нынче на Spring-е :)
     
     
  • 7.69, Очередной аноним (?), 13:00, 23/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Все Ынтерпрайз жабы нынче на Spring-е :)

    Брэхня! И отучаемся говорить за всех.

     
  • 3.51, qsdg (ok), 01:29, 21/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Выглядит как будто они изобрели J2EE 1.0 (1999 года) в 2017-м году.

    Это точно, хотя уже через пару лет жабисты заметили что много приложений под одним сервером нужно только домашним страничкам. А во всех серьёзных проектах всегда только одно приложение на весь сервер, и на всю JVM. Поэтому Tomcat не нужен.

    Так что для домашних страничек может и полезно будет. Хотя посмотрим, ведь " Код написан на языке Си" -- сколько там дыр будет везде и повсюду.

     
     
  • 4.52, pavlinux (ok), 06:49, 21/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Хотя посмотрим, ведь " Код написан на языке Си" -- сколько там дыр будет везде и повсюду.

    Закрой код и вам пох....ю будет.

     
  • 4.65, АнониМ (ok), 22:04, 21/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >хотя уже через пару лет жабисты заметили что много приложений под одним сервером нужно только домашним страничкам.

    судя по мега квалифицированному утверждению - с лора человек пришёл.

     
  • 2.8, username (??), 11:01, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    ИНтересно чем? Тем что они идут явно мутными схемами с конфигурированием?
     
  • 2.30, Аноним (-), 15:37, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен, зелёная тема выглядит интересной.
     

  • 1.3, a1x (ok), 10:45, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Это можно сделать что-то похожее на Apache + PHP?
     
     
  • 2.41, пох (?), 19:12, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Это можно сделать что-то похожее на Apache + PHP?

    нет, поскольку, вопреки заявленному в новости, ничего похожего на .htaccess как не было, так и нет.

    Ни "динамического", ни какого либо еще.

    Что-то похожее на php-fpm, но без php-fpm. Зачем - неясно.

     
     
  • 3.53, Аноним (-), 08:14, 21/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну почему без. Можно в качестве этого самого "сервиса приложений" использовать, видимо. Просто у Сысоева маниакальная потребность рулить чуть ли не каждым битом в хттп-запросе. Многим нравится.
     
     
  • 4.55, пох (?), 10:52, 21/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну почему без.

    он там не используется, эта штука сама себе fpm и сама себе, видимо, uWSGI (а вот go придется руками патчить чтобы вместо net.http он использовал протокол этого чуда)

    кстати, во втором случае оно даже выглядит в теории несколько менее ненужно - пихоновский хреново документированный и совершенно загадочный для человека не в теме скрипт с миллиардом командных параметров у меня никогда не вызывал восторгов (php-fpm, понятно, ничем не лучше, но как-то уже привыкли все).

    А вот какой смысл заменять в go net/http на какой-то другой интерфейс "использующий shared mem", но все равно общающийся с веб-сервером еще через один сокет - загадка.

    В принципе, там настолько много всякого coming soon, что, возможно, мы пока недопонимаем всей глубины затеи.

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

     
     
  • 5.56, Аноним (-), 11:33, 21/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Да почти наверняка "чудо" - это некая хрень буферизирующая и распределяющая потоки всё в те же сокеты(ну или IPC), врядли они сумеют сварганить столь низкоуровневые библиотеки что для пхп, что для го, косяков не оберёшся. Будет всё аффигено управляемо, сбалансировнно, оптимизированно, во главе чего будет сидеть ацкий админ и выверять параметры с точностью до полбита.
     
     
  • 6.59, пох (?), 12:33, 21/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > врядли они сумеют сварганить столь низкоуровневые библиотеки что для пхп, что для го

    они используют стандартные - что для пехепе, что для go. И стандартную же libpython.
    Ничего военного в самостоятельной реализации на их основе fpm'а, uwsgi и просто запускалки дочернего процесса для go (вроде ему больше ничего и не надо) нет.

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

    но вот нафига оно нужно, переизобретение велосипеда - пока совершенно не видно.

     
     
  • 7.60, Andrey Mitrofanov (?), 12:48, 21/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > они используют стандартные - что для пехепе, что для go. И стандартную
    > же libpython.
    > Аналогичные модули для апача и то сложнее было написать, поскольку они не
    > изолированы в отдельном "unit", и им приходится жить среди апачевских корявых
    > потрохов и по их правилам.
    > но вот нафига оно нужно, переизобретение велосипеда - пока совершенно не видно.

    Впечатление, что они создали спрос на фичи апача, упростив их 'away' в nginx, и теперь _удовлетворяют запрос рынка_.  %)))

    .htaccess, mod_php, jee-coming-soon и т.д.

     
     
  • 8.62, пох (?), 14:13, 21/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    они и в апаче были весьма относительной нужности, создавая больше проблем чем ре... текст свёрнут, показать
     
  • 7.61, Andrey Mitrofanov (?), 12:55, 21/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > но вот нафига оно нужно, переизобретение велосипеда - пока совершенно не видно.

    Ещё вариант: войти в реку "упрощения" дважды. nginx _когда-то_ был прост и невелик, и быстр, а апач всё рос и ро-о-ос.  апач по-прежнему рОстет  --  уже пора делать "ма-а-ахонькие" mod_php и ко., решили ребята в маркетингах.

    Туда же: у каждого языка, который "ходил" в торону большого веба есть свой апп.сервер, на себе самом обычно, те же обычные, как везде, фаст-старты и (?)сокет-mux-ы...  Таки, может, если их всех "упростить" до одной апп-пускалки, то...

     
     
  • 8.63, пох (?), 14:19, 21/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    то зачем Запускать на одном и том же хосте разом go, пихон и пехепе Их наобор... текст свёрнут, показать
     

  • 1.4, Аноним (-), 10:54, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    выглядит как привет из 90х в виде cgi
     
  • 1.9, vitalif (ok), 11:27, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не, пока как раз выглядит бесполезно. Что такое "обработчик пхп"? Php-fpm? Ок, а нафига нужен еще один сервер, если за ним все равно php-fpm?
     
     
  • 2.14, jOKer (ok), 11:37, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже что ему Php-fpm не нужен вовсе, и вполне достаточно libphp-embed

    http://unit.nginx.org/docs-configuration.html

     
     
  • 3.16, vitalif (ok), 12:08, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А... тогда понятно, Сысоев изобрёл свой вариант уберкомбайна типа Apache, просто обработчики рассадил по дочерним процессам, а не держит в одном (это-то правильно, конечно).

    Ну, фиг знает. Все уже вроде ушли от этой концепции как раз - вроде все уже сошлись на том, что standalone / отдельные легковесные сервера под каждое приложение - лучше.

     
     
  • 4.18, Аноним (-), 12:16, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > А... тогда понятно, Сысоев изобрёл свой вариант уберкомбайна типа Apache, просто обработчики
    > рассадил по дочерним процессам, а не держит в одном (это-то правильно,
    > конечно).
    > Ну, фиг знает. Все уже вроде ушли от этой концепции как раз
    > - вроде все уже сошлись на том, что standalone / отдельные
    > легковесные сервера под каждое приложение - лучше.

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

     
     
  • 5.49, vitalif (ok), 00:22, 21/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А это актуально по факту только в шаред хостинге осталось...
     
  • 3.24, Sw00p aka Jerom (?), 13:42, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а смысл? всё равно один воркер-пхп-процесс на один запрос, чем пхп-фпм хуже ?
     
  • 3.66, username (??), 19:04, 22/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    ну надеюсь они в теме что пап отключает опкеш если оно ембед и в sapi стоит что либо отличное от  apache
     
  • 2.15, Аноним (-), 11:54, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Судя по всему есть желание создать более-менее работающий сервер позволяющих деплоить приложения не под jvm с возможностью поддержки встроенных сервисов.
     

  • 1.11, ЫгиПгт (?), 11:31, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Не могу понять в чем принцип Юнита. Я вроде бы точно так же могу запускать одновременно виртуалхосты с php5, php7, passenger и в обычном nginx. Зачем тогда Юнит?
     
     
  • 2.17, Аноним (-), 12:15, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Принцип в том, чтобы выкинуть апач, заменив его предсказуемым и надёжным сервером приложений, отвечающим требованиям промышленного использования.
     
     
  • 3.19, _hide_ (ok), 12:38, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Апач достаточно предсказуем и легко настраивается. Но он наказывает за незнание и ошибки слишком сильно, чтобы с ним рисковать. Да и ресурсов потребляет как не в себя.
     

  • 1.20, eRIC (ok), 12:44, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    это открытый сервер приложений построенный по способу работы nginx, можно его использовать как standalone или embedded. вполне нормальная и хорошая реализация на СИ. вспомните бредоизвестный G-WAN непонятной реализации с многообещающим перформансом.  
     
     
  • 2.21, Andrey Mitrofanov (?), 12:51, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > это открытый сервер приложений построенный по способу работы nginx

    У nginx-а способ работы - мультиплексирокание кучи ядрёных сокетов одним процессом. И условие: "быстрые/короткие/живые соединения".

    Как это всё отнести к "серверу приложений" -- не вижу. Инвесторы умнее и проницательнее меня, наверное. Они будут в восторге от серебряной пули, ускоряющей apache-и...

    >, можно его использовать
    > как standalone или embedded. вполне нормальная и хорошая реализация на СИ.

     
     
  • 3.26, Аноним (-), 14:11, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > У nginx-а способ работы - мультиплексирокание кучи ядрёных сокетов одним процессом.

    Подозреваю, что здесь что-то похожее.

    > Процесс маршрутизации в свою очередь состоит из координатора запросов и рабочих нитей, которые принимают запросы клиентов, направляют их web-приложениям и возвращают ответ. Каждая рабочая нить может работать в асинхронном режиме и обслуживать тысячи одновременных соединений.

     

     
  • 2.25, Sw00p aka Jerom (?), 13:47, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >>это открытый сервер приложений

    нет!

     

  • 1.22, Анонимус2 (?), 12:56, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Особенностью реализации является то, что изменение настроек не приводит к перезапуску рабочих процессов - меняются только содержимое структур в памяти, что сводит к минимуму накладные расходы и позволяет менять параметры с любой интенсивностью.

    Если это относится только к внутренней кухне unit, то Сысоев конечно открыл Америку - оказывается не обязательно все перезапускать на каждый чих в 2017 году. А если это относится и к параметрам запуска приложений - хотелось бы посмотреть на реализацию.

     
  • 1.27, Аноним (-), 14:57, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Все нобт и говорят, что это не нужно, и вообще уже было в 99. А я чувствую себя, как с другой планеты. Лично мне уже надоело костылявить с динамической конфигурацией nginx (на сотнях сайтов даже тупо reload уже начинает выполняться несколько секунд). Вот те, кто говорят, что это не нужно, вы как сами обеспечиваете динамическую (автоматическую) конфигурацию nginx?
     
     
  • 2.31, Аноним (-), 15:39, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Они говорят, что динамическая конфигурация nginx... та-дам!.. не нужна!
    "Работает - не трогай" и все такое.
     
  • 2.50, vitalif (ok), 00:23, 21/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Все нобт и говорят, что это не нужно, и вообще уже было
    > в 99. А я чувствую себя, как с другой планеты. Лично
    > мне уже надоело костылявить с динамической конфигурацией nginx (на сотнях сайтов
    > даже тупо reload уже начинает выполняться несколько секунд). Вот те, кто
    > говорят, что это не нужно, вы как сами обеспечиваете динамическую (автоматическую)
    > конфигурацию nginx?

    А ты что, серьёзно руками админишь сервак с сотней сайтов?

     
     
  • 3.64, Аноним (-), 18:23, 21/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Как раз нет, не вручную. О чём, собственно, и говорилось, если вы внимательно читали. Именно с точки зрения автоматизации NGINX Unit и кажется потенциально более прямым решением.
     

  • 1.29, Kodir (ok), 15:12, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Все эти REST'ы и вебсервисы - тyп0й сакс, придуманый от слабоумия. Обычный TCP-сервер прекрасно работает - тот же FTP или SMTP.
    Если тебе нужно выполнить 10 команд, не имеет никакого значения, будешь ты отдавать их в одну TCP сессию или делать 10 отдельных запросов. Только в последнем случае ты сразу имеешь геморой с подтверждением сессии (что второй запрос пришёл в контексте первого) и оверхэд в виде @е6ильных HTTP-хэдеров. Ну и смысл?? ВСЕ ДЕСЯТЬ команд должны выполниться, так что сервер по-любому будет всеми ими нагружен. Ну и чего вы добиваетесь своими веб-перделками??
     
     
  • 2.34, K4 (?), 16:11, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    хотелось бы посмотреть на твои достижения
     
  • 2.36, Аноним (-), 16:52, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Если тебе нужно продавать площадку, то продавать её выгодней только порезав на как можно больше кусочков.
     
  • 2.37, Andrey Mitrofanov (?), 17:17, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Все эти REST'ы и вебсервисы - тyп0й сакс, придуманый от слабоумия.

    Бузинесы раз-вы-инкорпорируешь, ещё не так раскорячишься.

     
  • 2.38, KonstantinB (ok), 17:20, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    REST действительно переоценен, при этом единственной умной там штукой - HATEOAS - никто не пользуется. А с GraphQL и прочими JSON-RPC все хорошо. Причем там, как раз, HTTP(S) - это тупо транспортный протокол, и легко заменяется на любой другой.

    Остается вопрос, при чем тут Nginx Unit.

     
     
  • 3.74, Аноним (-), 00:04, 30/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > единственной умной там штукой - HATEOAS - никто не пользуется.

    Ахаха. HATEOAS это лютая хрень, которая в реальной жизни не работает. И судя по высказыванию, Вы ни разу не пытались сделать что-то в духе hateoas, иначе сразу бы поняли это.

    А с REST всё отл.

     
  • 2.40, пох (?), 19:02, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Обычный TCP-сервер прекрасно работает - тот же FTP или SMTP.

    но есть один ньюанс: в пехепе, жабке, libcurl - есть, в принципе, и ftp, и даже местами smtp - а вот snginxp - нету. Поэтому если ты изобретешь еще один ненужно-протокол, веб-кодиры не будут знать, что им с него пользы.

    Одно дело - просто заполнить поля в структурке и дернуть интуитивно-приятный, а главное - уже давно выученный апи. Совсем-совсем другое - самостоятельно строить хотя бы даже smtp-like сессию (с авторизацией, с защитой от подмены, с обработкой всех возможных ошибок, от таймаутов на любой стадии протокола (обрабатываемых по разному!) до rogue server, самостоятельно сооружать для нее синтаксические конструкции (помня о возможностях injection!) и самостоятельно парсить ответы (и смотри не перепутай с полями самого протокола!)

    А что http и REST для этой супер-задачи (да практически для всех задач где используют) что-то вроде робота-марсохода, забивающего банальный гвоздь в метре от тебя (но сигналы управления идут через марсианский ретранслятор, чтоб жизнь не казалась медом) - всем пoх.

    Совершенно плевать, сколько там слоев и чего понаворочено ради команды "забить гвоздик", когда можно нажать кнопочку и наслаждаться результатом, а не идти в магазин за микрос...э...как эта штука называется? а-а-а, молоток, что-ли?

    "а других разработчиков у меня для вас нет".

     

  • 1.33, Наставление (?), 16:04, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Родина дала им FastCGI - пользуйся! Не хотим, хотим монолитный комбайн.
     
     
  • 2.44, Аноним (-), 20:27, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Комбайн - это удобно.
    А когда тебе нужно админить сотню-другую контейнеров, удобство перевешивает любую философию.
     
     
  • 3.48, Sw00p aka Jerom (?), 23:32, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    поэтому комбайн в виде апача заменили на нгиникс?
     

  • 1.35, Аноним (-), 16:50, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да, двадцать лет спустя доросли до уровня JEE 2.0. Ну почти доросли.
     
     
  • 2.39, Аноним (-), 17:52, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    пока росли, jee успело сдохнуть и осталось разлагаться в у терпил, швыряющих миллиарды на ветер
     
     
  • 3.47, Кузнец (?), 23:16, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Подыхать jee будет ещё очень долго. А пока это 2/3 всего платежеспособного рынка. И чем больше миллиардов на этот "рынок" выбрасывают "терпилы", тем лучше.
    Просто пытло-скриптеры не понимают того простого факта, что когда помре ява помре любая разработка ПО, в которой в принципе участвует человек.
     
     
  • 4.54, BernersLess (?), 10:22, 21/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Подыхать jee будет ещё очень долго. А пока это 2/3 всего платежеспособного рынка. И чем больше миллиардов на этот "рынок" выбрасывают "терпилы", тем лучше.
    > Просто пытло-скриптеры не понимают того простого факта, что когда помре ява помре любая разработка ПО, в которой в принципе участвует человек.

    http://danlik.ru/wp-content/uploads/2014/09/Fantazjory.-Nikolajj-Nosov.jpg

     

  • 1.42, Аноним (-), 19:57, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Java is neither supported nor planned?
     
     
  • 2.46, Аноним (-), 21:29, 20/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Not needed.
     

  • 1.58, gogo (?), 12:19, 21/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Типа универсальная фигня, которая может запускать что угодно...
    Только для каждого из этих "что угодно" уже давно есть нормальные нативные методы.
    Зачем пытаться собрать их в кучу - не понятно.
    Если бы это было как модуль nginx'а "искаропки", то может и был бы смысл.
     
     
  • 2.67, username (??), 19:07, 22/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Да что вам тут все в комментах непонятно. Как дети.
    Нужен он затем чтобы сделать еще один paas и брать бабки. Отсюда и его "особенности".
     
     
  • 3.68, пох (?), 22:32, 22/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Нужен он затем чтобы сделать еще один paas и брать бабки.

    и кто понесет-то? те, кто ниасилили настроить php-fpm ? те кто асилили, но слегка затрахались (вообще-то там начинаются чудеса, когда система сложная и нагруженная - но там где они начинаются, у этого проекта пустое место вообще) ?

    мы ж тоже хотим из г-на на курорт, и пытаемся угадать, где деньги.

    в случае с коммерческим nginx вопрос ясен - бабки платят за латание твоих дыр в приоритетном порядке, а не когда-если ты убедишь Максима, и за некоторые фичи, полезные для больших проектов, тоже в приоритетном порядке, а не когда большие уже наиграются.
    Почему нет, у нас тоже был логин для Сысоева в ядро системы - что-то, по результатам, вернули в апстрим, что-то он сам поправил. Если за это можно заплатить - почему же не заплатить, деньги ведь дядины, мне их в зарплату все равно не отдадут.

    но для этого сперва надо было написать такой nginx, чтобы им все захотели пользоваться, вместо апачей и всяких там недоhttpd, и десять лет как папа карла его развивать и поддерживать. А тут ничего похожего. Даже жаба только "coming soon".

     
     
  • 4.73, zo0M (?), 12:07, 28/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    так никто и не говорит что Unit 0.2 это готовый продукт! это даже не предрелизная версия...
    эхх, сейчас бы альфа-версии ПО за недостаток функционала хаить.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру