Опубликован (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
А Ruby хоть и объявлен но на Centos unit-ruby нет!
А C++ где?
nginx-ctpp. правда, возникает ощущение, что vbart его уже не поддерживает N времени, где N ~ 6 лет.
Я понимаю, что судя по частоте появления новостей о NU, они опеннет кормят. А значит сильно ругать нашего танцора не положено :) но всё же... судя по Full Example конфигу, разные приложения вешаются на разные порты. Извините, а в чём революционность-то данного продукта тогда?
> Я понимаю, что судя по частоте появления новостей о NU, они опеннет кормят.да, спам nginx'ов о ниочемных версиях, выпускаемых только для ублажения инвесторов по графику, без плана, есть хоть одна строка в commit log - бамп, ужасно достал. Что про сервер, что про "все еще немножко неготовый для продакшна".
> Извините, а в чём революционность-то данного продукта тогда?
да ни в чем. Смысл тот же что и у вебсервера - скорее эволюционный. От апача отказались не из-за каких-то революционных идей, а просто потому что он всех уже достал, вменяемые разработчики свалили еще во времена версии 1.2
И не говорите мне, что nginx'овые конфиги лучше, удобопонимаемей и удобоуправляемей внешними средствами, не поверю. Они и семантически г-но, и функционально оно же. И тредовые воркеры - тоже вовсе не являются обязательным элементом, если, конечно, у тебя сервер не под windows.
(особенно смешно что версии 0.x писались для/под freebsd4, у которой с тредами было очень и очень плохо)Сейчас та же самая петрушка с php-fpm. Он a) уродлив внутри b) имеет неодолимые проблемы под нагрузкой, связанные не с форковой архитектурой, а с рукожопостью и желанием угодить windows-братии, которой вообще-то нахрен не нужен c) еще пачку более мелких проблем, вызванных опять же уродливостью своей внутренней начинки (там простота что хуже воровства).
На этом фоне curl вместо нормального конфига - ну, можно как-то и пережить (fpm'ный конфиг тоже, если честно, неудобочитаемая дрянь). "Если бы еще и работало". Но вот тут есть большие сомнения, с тех пор как хороший разработчик стал плохим менеджером, а потом и вовсе ушел в туман.
Что-то вы про fpm странное говорите. Никогда там поддержки windows не было, это и технически бессмысленно (там используется libevent, который на винде все, что умеет, это косплеить слоупока через select, а в комбинации с форком и невозможно ввиду его отсутствия).
> Что-то вы про fpm странное говорите. Никогда там поддержки windows не было,Не проверял, собирается или нет. Но тогда совсем непонятно, кому они хотели угодить таким кодом.
> это и технически бессмысленно (там используется libevent, который на винде все,
> что умеет, это косплеить слоупока через select, а в комбинации с
> форком и невозможно ввиду его отсутствия).CreateProcess вполне присутствует. fork - функция c runtime 1003.1, которая и в линуксе враппер.
Ты наверное про microservices с discovery zeroconf dns mesh и не слышал...
я про него раз в день слышу из дурацких рассылок nginx corp, а вот зачем он нужен - остается только догадываться.Вероятно, нужен "девопам", которые не умеют не только админить, но и кодить тоже.
тем что блокировки интернета не страшны
(в свете послежних событий был заблокирован докер)
+ вчера Flask допилили до 1.0.
Я правильно понимаю, что это альтернатива uWSGI https://ru.wikipedia.org/wiki/UWSGI
нет
> Я правильно понимаю, что это альтернатива uWSGIнет. uwsgi-с шифтом так и остался неэффективной бесполезной прослойкой для запуска пихона (авторы которого, как всегда, "не такие как все" и наворотили ненужную несовместимую ни с чем замену fcgi), претензии на универсальность слились давным-давно.
a это замена всех кривых запускалок разом, включая php-fpm, который поглавнее будет - с претензией на эффективность.
> Я правильно понимаю, что это альтернатива uWSGI https://ru.wikipedia.org/wiki/UWSGIДа.
И не только ему, а сразу пачке запускаторов для нескольких языков.
НО - надо сделать пару правок в коде.
> И не только ему, а сразу пачке запускаторов для нескольких языков.uWSGI - изначально задуман как запускатор для нескольких языков. Нивзлитело. Потому что крокодилы в принципе очень хреново летают.
> НО - надо сделать пару правок в коде.
например, поддерживать в нем wsgi протокол (не путать с uwsgi)
или другие аналоги - в других языках.
> Я правильно понимаю, что это альтернатива uWSGI https://ru.wikipedia.org/wiki/UWSGIЗамена это lsPHP (lsAPI)
Это попытка сделать альтернативу uwsgi. Но, в отличии от юнита, uwsgi намного дальше продвинут.
Я немного растерян и не могу понять, что именно эта штука делает. Если тут есть те, кто регулярно читает рассылки этой конторы, то может подскажите, что из этого можно реализовать этой штукой? А то вроде бы и можно, и вроде бы из другой сказки.1. Реализовать индикатор загрузки файлов и указать скорость загрузки. Да, есть отдельные плагины как к nginx, так и к php в частности, но это чужой код и я должен зависеть от него. А собственный обработчик - никак, ведь мой код выполняется лишь после загрузки всех файлов целиком.
2. Обрабатывать контент и управлять соединением в процессе запроса. Допустим на Ютуб лью 10 гиговый файл, он мне сразу начинает показывать превьюшки, с первых секунд заливки. Я тоже так хочу, а если мне заливают некропедозоопорно, то я хочу как-то дропнуть коннект, но не заносить клиента в iptables.
3. К нам пришел запрос от веб-формочки, нам надо как-то процессить присланные файлы, хотя бы тумбинашки от них посчитать. В принципе, тумбинашку сгенерить не долго и это часто делают в основном скрипте, тем самым задерживая исполнение реквеста и отдачу "ок, все впорядке". А я хочу процессить картинки в отдельном треде, чтобы одновременная заливка 500 картинок не положила мне сервер, но в этом случае я получаю condition race, так как пользователь вернется на страничку раньше, чем я успею ее обновить. Хотелось бы какой-то инструмент, чтобы я мог как-то тормознуть отдачу результата клиенту, но при этом сам скрипт-обработчик мог бы спокойно завершиться/завершить цикл и приступить к новому запросу. В общем, хочу в обработчике запросов делать тяжелые задачи и чтобы мне за это ничего не было.
4. Ко мне на файлообменник заливают файл весом в 10 гигов, не быстро так, а часов за 5. Это может быть плохая скорость у пира, где-то по пути проблемы, или у меня большой iowait, не суть важно. Почему бы мне этот файл не попробовать раздавать еще до того, как он окончательно будет долит? Скажем, мне успели залить 10 мегабайт, они уже где-то лежат на моем винте, почему бы их не отдать новоприбывшим с полной скоростью, а остаток не скормить за оставшиеся 5 часов со скоростью заливальщика? По идее, процесс один, все данные для этого есть, просто я не знаю как сервить такие вот обновляемые файлы.
5. Ну и всякие мультиплексоры тоже хочу, такие как realplexor или что там теперь пришло ему на смену? Куча клиентов присоединяется к ресурсу и ждут событий, а когда событие произошло - получают одно или несколько штук сразу. Чтобы посылать несколько событий, неплохо бы чтобы скрипт посылающий события мог бы сделать некий flush() и все ушло разом, а не 10 байт через 10 запросов.
Может есть какие-то другие решения? Просто обработчики запросов легко бы решили все эти проблемы, но у меня нету такого API. Когда-то давно начинал писать вебсервер где запросы просто складировались в память и дальше рассылались уведомления на мотив epoll, но запрокрастинировал и бросил.
Так это чё за "сервер приложений"?
Это то, что раньше называлось скриптами, работающими через CGI, теперь решили называть по модному - "сервером приложений"? Это же сервер не приложений типа Офис удалённо через "терминал" запустить или 1С? Это именно CGI? А зачем тогда называют это по модному?
> Так это чё за "сервер приложений"?
> Это то, что раньше называлось скриптами, работающими через CGI, теперь решилиНе, это https://ru.wikipedia.org/wiki/%D0%A1%D0%... FastCGI и далее.
> А зачем тогда называют это по модному?
Бартенёв об этом рассказывал на Стачке в Ульяновске. Есть слайды: https://drive.google.com/file/d/1F1Q3arKhgbY20sKT0bs7Xn326f-...Если всё пойдёт, как надо, то Unit потеснит и Apache, и nginx и множество кастомных app-серверов. Имхо.
> то, что раньше называлось скриптами, работающими через CGI, теперь решили называть по модномунет. это не "решили назвать", это "решили переделать" (лет пятнадцать назад, что характерно), cgi был немодно, использовал fork который плохо имитировался винд...ой... в общем, вместо него понапридумывали миллиард несовместимых протоколов, с "серверами" (не веб, а снова ни с чем несовместимых протоколов) то на пихоне, то на go, еще Б-г знает на чем, оно "почему-то" оказалось глючным, нестабильным и сложным в настройке (и программировании, но мы шлеп-шлеп, подтянем готовую библиотеку и ее стопиццот зависимостей...ой, пока тянули одна обновилась и ничего не работает) - и вот теперь nginx решили всем показать "как надо". Поддержку cgi в своем замечательном веб-сервере, кстати, так и не осилили - зачем, немодно, ненужно, неинтересно, хайпа нет, индустрия не поймет.
> Это именно CGI?
нет.
Залазьте обратно в свою криокамеру - тут XXI, все стильное, модное, молодежное, вы проспали 20 лет и годитесь только в музейные экспонаты. А экспонаты не кормят.
>> Это именно CGI?
> нет.
> Залазьте обратно в свою криокамеру - тут XXI, все стильное, модное, молодежное,
> вы проспали 20 лет и годитесь только в музейные экспонаты. А
> экспонаты не кормят.Чё-то я не понял.
CGI (от англ. Common Gateway Interface — «общий интерфейс шлюза») — стандарт интерфейса, используемого для связи внешней программы с веб-сервером.
Браузеры (клиенты) с сайтами (серверами) по прежнему работают по этому правилу: клиент посылает запрос и получает ответ. Или всё (передача данных) нынче работает теперь только через торсионные поля и субпространственные запросы? :о)
> Чё-то я не понял.- Ну, это ты зря. Надо себя заставлять.. http://anigdoty.ru/id/31075
> Чё-то я не понял.говорю, возвращайтесь в криокамеру, вас разморозили по ошибке. Cейчас спрос только на специалистов по коболу. Специалисты по cgi пока не нужны.
> CGI (от англ. Common Gateway Interface — «общий интерфейс шлюза») — стандарт интерфейса,
> используемого"использовавшегося" в XX веке. Ныне практически вышел из употребления, поскольку предусматривал запуск (и, соответственно, контроль, в минимальном виде - хотя бы wait() ) посторонней программы веб-сервером, что для вебсервера несвойственная и неудобная задача.