Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск сервера приложений NGINX Unit 1.1"	+/–
Сообщение от opennews (??) on 26-Апр-18, 22:56
Опубликован (http://mailman.nginx.org/pipermail/unit/2018-April/000050.html)  выпуск сервера приложений NGINX Unit 1.1 (http://unit.nginx.org/), в рамках которого развивается решение для обеспечения запуска web-приложений на различных языках программирования (Python, PHP, Perl, Ruby и Go). Под управлением NGINX Unit может одновременно выполняться несколько приложений на разных языках программирования, параметры запуска которых можно изменять динамически без необходимости правки файлов конфигурации и перезапуска. Проект пока находится на стадии бета-тестирования и не рекомендован для промышленного использования. Код написан на языке Си и распространяется (https://github.com/nginx/unit) под лицензией Apache 2.0. С особенностями NGINX Unit можно познакомиться в анонсе (https://www.opennet.ru/opennews/art.shtml?num=48434) прошлого выпуска. Новый выпуск в основном включает исправления ошибок. Например, налажена работа Python-приложений, использующих вызов write(), обеспечена поддержка виртуальых окружений с Python 3.3+, устранены проблемы с работой приложений на языке Go, выполняющих request.Read(), устранён крах при переоткрытии лога, реализована возможнсть загрузки модулей приложений в OpenBSD. URL: http://mailman.nginx.org/pipermail/unit/2018-April/000050.html Новость: https://www.opennet.ru/opennews/art.shtml?num=48499
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Выпуск сервера приложений NGINX Unit 1.1"	–3 +/–
Сообщение от Аноним (??) on 26-Апр-18, 22:56
А Ruby хоть и объявлен но на Centos unit-ruby нет!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Выпуск сервера приложений NGINX Unit 1.1"	–1 +/–
Сообщение от Алконим on 27-Апр-18, 02:25
А C++ где?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Выпуск сервера приложений NGINX Unit 1.1"	–2 +/–
	Сообщение от Аноним (??) on 27-Апр-18, 02:51
	nginx-ctpp. правда, возникает ощущение, что vbart его уже не поддерживает N времени, где N ~ 6 лет.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Выпуск сервера приложений NGINX Unit 1.1"	–3 +/–
Сообщение от лютый жабист__ on 27-Апр-18, 08:59
Я понимаю, что судя по частоте появления новостей о NU, они опеннет кормят. А значит сильно ругать нашего танцора не положено :) но всё же... судя по Full Example конфигу, разные приложения вешаются на разные порты. Извините, а в чём революционность-то данного продукта тогда?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Выпуск сервера приложений NGINX Unit 1.1"	–1 +/–
	Сообщение от пох on 27-Апр-18, 09:45
	> Я понимаю, что судя по частоте появления новостей о NU, они опеннет кормят. да, спам nginx'ов о ниочемных версиях, выпускаемых только для ублажения инвесторов по графику, без плана, есть хоть одна строка в commit log - бамп, ужасно достал. Что про сервер, что про "все еще немножко неготовый для продакшна". > Извините, а в чём революционность-то данного продукта тогда? да ни в чем. Смысл тот же что и у вебсервера - скорее эволюционный. От апача отказались не из-за каких-то революционных идей, а просто потому что он всех уже достал, вменяемые разработчики свалили еще во времена версии 1.2 И не говорите мне, что nginx'овые конфиги лучше, удобопонимаемей и удобоуправляемей внешними средствами, не поверю. Они и семантически г-но, и функционально оно же. И тредовые воркеры - тоже вовсе не являются обязательным элементом, если, конечно, у тебя сервер не под windows. (особенно смешно что версии 0.x писались для/под freebsd4, у которой с тредами было очень и очень плохо) Сейчас та же самая петрушка с php-fpm. Он a) уродлив внутри b) имеет неодолимые проблемы под нагрузкой, связанные не с форковой архитектурой, а с рукожопостью и желанием угодить windows-братии, которой вообще-то нахрен не нужен c) еще пачку более мелких проблем, вызванных опять же уродливостью своей внутренней начинки (там простота что хуже воровства). На этом фоне curl вместо нормального конфига - ну, можно как-то и пережить (fpm'ный конфиг тоже, если честно, неудобочитаемая дрянь). "Если бы еще и работало". Но вот тут есть большие сомнения, с тех пор как хороший разработчик стал плохим менеджером, а потом и вовсе ушел в туман.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	8. "Выпуск сервера приложений NGINX Unit 1.1"	+/–
	Сообщение от KonstantinB (ok) on 27-Апр-18, 10:18
	Что-то вы про fpm странное говорите. Никогда там поддержки windows не было, это и технически бессмысленно (там используется libevent, который на винде все, что умеет, это косплеить слоупока через select, а в комбинации с форком и невозможно ввиду его отсутствия).
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	17. "Выпуск сервера приложений NGINX Unit 1.1"	+/–
	Сообщение от пох on 28-Апр-18, 11:50
	> Что-то вы про fpm странное говорите. Никогда там поддержки windows не было, Не проверял, собирается или нет. Но тогда совсем непонятно, кому они хотели угодить таким кодом. > это и технически бессмысленно (там используется libevent, который на винде все, > что умеет, это косплеить слоупока через select, а в комбинации с > форком и невозможно ввиду его отсутствия). CreateProcess вполне присутствует. fork - функция c runtime 1003.1, которая и в линуксе враппер.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	14. "Выпуск сервера приложений NGINX Unit 1.1"	+/–
	Сообщение от Адноним on 27-Апр-18, 20:57
	Ты наверное про microservices с discovery zeroconf dns mesh и не слышал...
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	16. "Выпуск сервера приложений NGINX Unit 1.1"	+1 +/–
	Сообщение от пох on 28-Апр-18, 11:44
	я про него раз в день слышу из дурацких рассылок nginx corp, а вот зачем он нужен - остается только догадываться. Вероятно, нужен "девопам", которые не умеют не только админить, но и кодить тоже.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	20. "Выпуск сервера приложений NGINX Unit 1.1"	–1 +/–
	Сообщение от anonimous on 29-Апр-18, 11:30
	тем что блокировки интернета не страшны (в свете послежних событий был заблокирован докер)
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "Выпуск сервера приложений NGINX Unit 1.1"	+/–
Сообщение от via (??) on 27-Апр-18, 12:19
+ вчера Flask допилили до 1.0.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Выпуск сервера приложений NGINX Unit 1.1"	+/–
Сообщение от ананим.orig on 27-Апр-18, 15:16
Я правильно понимаю, что это альтернатива uWSGI https://ru.wikipedia.org/wiki/UWSGI
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Выпуск сервера приложений NGINX Unit 1.1"	+/–
	Сообщение от ыы on 27-Апр-18, 15:35
	нет
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "Выпуск сервера приложений NGINX Unit 1.1"	–2 +/–
	Сообщение от Аноним (??) on 27-Апр-18, 16:27
	> Я правильно понимаю, что это альтернатива uWSGI нет. uwsgi-с шифтом так и остался неэффективной бесполезной прослойкой для запуска пихона (авторы которого, как всегда, "не такие как все" и наворотили ненужную несовместимую ни с чем замену fcgi), претензии на универсальность слились давным-давно. a это замена всех кривых запускалок разом, включая php-fpm, который поглавнее будет - с претензией на эффективность.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	13. "Выпуск сервера приложений NGINX Unit 1.1"	–1 +/–
	Сообщение от XoRe (ok) on 27-Апр-18, 20:55
	> Я правильно понимаю, что это альтернатива uWSGI https://ru.wikipedia.org/wiki/UWSGI Да. И не только ему, а сразу пачке запускаторов для нескольких языков. НО - надо сделать пару правок в коде.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	18. "Выпуск сервера приложений NGINX Unit 1.1"	+/–
	Сообщение от пох on 28-Апр-18, 11:54
	> И не только ему, а сразу пачке запускаторов для нескольких языков. uWSGI - изначально задуман как запускатор для нескольких языков. Нивзлитело. Потому что крокодилы в принципе очень хреново летают. > НО - надо сделать пару правок в коде. например, поддерживать в нем wsgi протокол (не путать с uwsgi) или другие аналоги - в других языках.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	15. "Выпуск сервера приложений NGINX Unit 1.1"	+1 +/–
	Сообщение от Адноним on 27-Апр-18, 20:59
	> Я правильно понимаю, что это альтернатива uWSGI https://ru.wikipedia.org/wiki/UWSGI Замена это lsPHP (lsAPI)
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	19. "Выпуск сервера приложений NGINX Unit 1.1"	+/–
	Сообщение от Аноним (??) on 28-Апр-18, 20:09
	Это попытка сделать альтернативу uwsgi. Но, в отличии от юнита, uwsgi намного дальше продвинут.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

21. "Выпуск сервера приложений NGINX Unit 1.1"	+/–
Сообщение от Аноним (??) on 02-Май-18, 07:32
Я немного растерян и не могу понять, что именно эта штука делает. Если тут есть те, кто регулярно читает рассылки этой конторы, то может подскажите, что из этого можно реализовать этой штукой? А то вроде бы и можно, и вроде бы из другой сказки. 1. Реализовать индикатор загрузки файлов и указать скорость загрузки. Да, есть отдельные плагины как к nginx, так и к php в частности, но это чужой код и я должен зависеть от него. А собственный обработчик - никак, ведь мой код выполняется лишь после загрузки всех файлов целиком. 2. Обрабатывать контент и управлять соединением в процессе запроса. Допустим на Ютуб лью 10 гиговый файл, он мне сразу начинает показывать превьюшки, с первых секунд заливки. Я тоже так хочу, а если мне заливают некропедозоопорно, то я хочу как-то дропнуть коннект, но не заносить клиента в iptables. 3. К нам пришел запрос от веб-формочки, нам надо как-то процессить присланные файлы, хотя бы тумбинашки от них посчитать. В принципе, тумбинашку сгенерить не долго и это часто делают в основном скрипте, тем самым задерживая исполнение реквеста и отдачу "ок, все впорядке". А я хочу процессить картинки в отдельном треде, чтобы одновременная заливка 500 картинок не положила мне сервер, но в этом случае я получаю condition race, так как пользователь вернется на страничку раньше, чем я успею ее обновить. Хотелось бы какой-то инструмент, чтобы я мог как-то тормознуть отдачу результата клиенту, но при этом сам скрипт-обработчик мог бы спокойно завершиться/завершить цикл и приступить к новому запросу. В общем, хочу в обработчике запросов делать тяжелые задачи и чтобы мне за это ничего не было. 4. Ко мне на файлообменник заливают файл весом в 10 гигов, не быстро так, а часов за 5. Это может быть плохая скорость у пира, где-то по пути проблемы, или у меня большой iowait, не суть важно. Почему бы мне этот файл не попробовать раздавать еще до того, как он окончательно будет долит? Скажем, мне успели залить 10 мегабайт, они уже где-то лежат на моем винте, почему бы их не отдать новоприбывшим с полной скоростью, а остаток не скормить за оставшиеся 5 часов со скоростью заливальщика? По идее, процесс один, все данные для этого есть, просто я не знаю как сервить такие вот обновляемые файлы. 5. Ну и всякие мультиплексоры тоже хочу, такие как realplexor или что там теперь пришло ему на смену? Куча клиентов присоединяется к ресурсу и ждут событий, а когда событие произошло - получают одно или несколько штук сразу. Чтобы посылать несколько событий, неплохо бы чтобы скрипт посылающий события мог бы сделать некий flush() и все ушло разом, а не 10 байт через 10 запросов. Может есть какие-то другие решения? Просто обработчики запросов легко бы решили все эти проблемы, но у меня нету такого API. Когда-то давно начинал писать вебсервер где запросы просто складировались в память и дальше рассылались уведомления на мотив epoll, но запрокрастинировал и бросил.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "Выпуск сервера приложений NGINX Unit 1.1"	+/–
Сообщение от rvs2016 (ok) on 03-Май-18, 14:24
Так это чё за "сервер приложений"? Это то, что раньше называлось скриптами, работающими через CGI, теперь решили называть по модному - "сервером приложений"? Это же сервер не приложений типа Офис удалённо  через "терминал" запустить или 1С? Это именно CGI? А зачем тогда называют это по модному?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	23. "Выпуск сервера приложений NGINX Unit 1.1"	+/–
	Сообщение от Andrey Mitrofanov on 03-Май-18, 14:40
	> Так это чё за "сервер приложений"? > Это то, что раньше называлось скриптами, работающими через CGI, теперь решили Не, это https://ru.wikipedia.org/wiki/%D0%A1%D0%... FastCGI и далее. > А зачем тогда называют это по модному?
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	24. "Выпуск сервера приложений NGINX Unit 1.1"	+/–
	Сообщение от dvc on 03-Май-18, 15:38
	Бартенёв об этом рассказывал на Стачке в Ульяновске. Есть слайды: https://drive.google.com/file/d/1F1Q3arKhgbY20sKT0bs7Xn326f-... Если всё пойдёт, как надо, то Unit потеснит и Apache, и nginx и множество кастомных app-серверов. Имхо.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	25. "Выпуск сервера приложений NGINX Unit 1.1"	–1 +/–
	Сообщение от пох on 03-Май-18, 18:27
	> то, что раньше называлось скриптами, работающими через CGI, теперь решили называть по модному нет. это не "решили назвать", это "решили переделать" (лет пятнадцать назад, что характерно), cgi был немодно, использовал fork который плохо имитировался винд...ой... в общем, вместо него понапридумывали миллиард несовместимых протоколов, с "серверами" (не веб, а снова ни с чем несовместимых протоколов) то на пихоне, то на go, еще Б-г знает на чем, оно "почему-то" оказалось глючным, нестабильным и сложным в настройке (и программировании, но мы шлеп-шлеп, подтянем готовую библиотеку и ее стопиццот зависимостей...ой, пока тянули одна обновилась и ничего не работает) - и вот теперь nginx решили всем показать "как надо". Поддержку cgi в своем замечательном веб-сервере, кстати, так и не осилили - зачем, немодно, ненужно, неинтересно, хайпа нет, индустрия не поймет. > Это именно CGI? нет. Залазьте обратно в свою криокамеру - тут XXI, все стильное, модное, молодежное, вы проспали 20 лет и годитесь только в музейные экспонаты. А экспонаты не кормят.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	26. "Выпуск сервера приложений NGINX Unit 1.1"	–1 +/–
	Сообщение от rvs2016 (ok) on 04-Май-18, 15:43
	>> Это именно CGI? > нет. > Залазьте обратно в свою криокамеру - тут XXI, все стильное, модное, молодежное, > вы проспали 20 лет и годитесь только в музейные экспонаты. А > экспонаты не кормят. Чё-то я не понял. CGI (от англ. Common Gateway Interface — «общий интерфейс шлюза») — стандарт интерфейса, используемого для связи внешней программы с веб-сервером. Браузеры (клиенты) с сайтами (серверами) по прежнему работают по этому правилу: клиент посылает запрос и получает ответ. Или всё (передача данных) нынче работает теперь только через торсионные поля и субпространственные запросы? :о)
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	27. "Выпуск сервера приложений NGINX Unit 1.1"	+/–
	Сообщение от Andrey Mitrofanov on 04-Май-18, 15:49
	> Чё-то я не понял. - Ну, это ты зря. Надо себя заставлять..  http://anigdoty.ru/id/31075
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	28. "Выпуск сервера приложений NGINX Unit 1.1"	+/–
	Сообщение от пох on 07-Май-18, 20:53
	> Чё-то я не понял. говорю, возвращайтесь в криокамеру, вас разморозили по ошибке. Cейчас спрос только на специалистов по коболу. Специалисты по cgi пока не нужны. > CGI (от англ. Common Gateway Interface — «общий интерфейс шлюза») — стандарт интерфейса, > используемого "использовавшегося" в XX веке. Ныне практически вышел из употребления, поскольку предусматривал запуск (и, соответственно, контроль, в минимальном виде - хотя бы wait() ) посторонней программы веб-сервером, что для вебсервера несвойственная и неудобная задача.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема