Доступен (http://mailman.nginx.org/pipermail/unit/2018-July/000075.html) выпуск сервера приложений NGINX Unit 1.3 (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) прошлого выпуска.В новой версии:
- Добавлен параметр max_body_size для ограничения размера тела запроса;- Добавлены новые параметры для настройки таймаутов при установке HTTP-соединения;
"settings": {
"http": {
"header_read_timeout": 30,
"body_read_timeout": 30,
"send_timeout": 30,
"idle_timeout": 180,
"max_body_size": 8388608
}
},
- В модуле для языка Ruby обеспечено автоматическое использование Bundler при наличии такой возможности;
- В модуле для языка Go реализован интерфейс http.Flusher;
- В содержимом полей в заголовках запросов разрешено использовать символы в кодировке UTF-8;
- Устранены проблемы с обработкой ошибок при установке HTTP-соединений.
URL: http://mailman.nginx.org/pipermail/unit/2018-July/000075.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=48962
поскорее бы добавили поддержку Java™. Почему упор пока идет на ПЫХОПЛЕЯДУ (Perl, PHP, Python, Ruby) - неясно.
У Java же свои серверы приложений есть
Подкупает, что NGIИX Unit написан на си, что безусловно понаддаст производительности.
для производительности нужно выбросить жабу.PS
сейчас будут втирать что в синтетических супер тестах она быстрей машкода
> для производительности нужно выбросить жабуА я тебе о чем? Низкоуровневый Java™-код, работающий с хттп, следует перевести на си. И NGIИX Unit тому возможная реализация.
Кстати, если сравнивать с ПЫХОПЛЕЯДОЙ (Perl, PHP, Python, Ruby), то написанные на них хттп-сервера в энтерпрайзе юзать даже не пытались. Так что про "супиртармазную" Java™ мне втирать не нужно, на которой написан не один реально юзаемый в энтерпрайзе хттп-сервер.
> если сравнивать с ПЫХОПЛЕЯДОЙ (Perl, PHP, Python, Ruby), то написанные на них хттп-сервера в энтерпрайзе юзать даже не пытались.Ну это лишь говорит о степени некомпетентности в вашем типа энтерпрайзе. Но никак не о качестве и скорости этих серверов.
Эх, старый добрый argumentum ad hominem.
каким образом эта великая, богоподобная поговорка оправдывает твою безграмотность?
В качестве ликбеза, argumentum ad hominem это "некто известный дурак/негодяй/редиска и поэтому всё, что он говорит, является глупостью", а вот "некто сказал откровенную глупость и поэтому он дурак" таковым не является.
Вообще, "интерпрайз" не часто сталкивается с проблемой скорости исполнения кода.Предварительная оптимизация без необходимости усложняет код, который отражает как правило чужие деньги, чужое время.
> Кстати, если сравнивать с ПЫХОПЛЕЯДОЙ (Perl, PHP, Python, Ruby), то написанные на них хттп-сервера в энтерпрайзе юзать даже не пытались.Такой серьёзный довод требует пруфов.
И желательно без перевода стрелок "ну назовите мне сервис в энтерпрайзе на ПЫХОПЛЕЯДЕ".
Сами тезис выдвинули, сами доказывайте.
Мешать сишку с джавой не особо, как по мне. Не энтерпрайзно
а про микросервисы слыхал? там хачкиль и пхп мешают
Честно отвечаю - не слышал. Сейчас этих модных концепций и приемов столько расплодилось - черт ногу сломит за ними всеми следить
NGIИX Unit - это просто обёртка над зоопарком представленных выше языков программирования, выбивается только Go. Оверхед не критичен по сравнению с тем что Unit запускает.
>NGIИX Unit написан на си, что безусловно понаддаст производительностиЯ понимаю, что ты полный ламер в вопросе, лови шмат бисера. В большом проекте голая скорость среды вообще не роляет. Допустим плюсы в 2 раза быстрее жабы и в 3 раза меньше ОЗУ хотят. Но ты на сях замаешься писать архитектурно грамотное решение, в итоге у тебя вся бизнеслогика будет на костылях и хипсторских микросервисах. Со скоростью в четверть жабы.
> неясноХотя сейчас стало ясно. Начали с самых тормозных языков. (Не объясняет, почему тогда там числится Go.)
Java традиционно деплоится в своих форматах (WAR, EAR, SAR и т.п.), поддерживать их, или новый создать? Да и embedded JVM понадобится, тоже еще задачка не из легких.
Добавят. На главной странице Юнита: Supported Application Languages: Java (coming soon).Почему - на самом деле ясно, из-за нетривиальности разработки. С перечисленными языками техническая реализация намного проще.
> Добавят. На главной странице Юнита: Supported Application Languages: Java (coming soon).
>Java (coming soon).Оно там каминг сун с самого начала. https://www.opennet.ru/openforum/vsluhforumID3/112553.html#60
Есть версия, что: 1/ эта java очень хороша для "pro" версии -- продажники смотрят на анонимов, плачущих "ах, где же джавва" и потирают ручонки; 2/ она совсем не хороша для "про"-версии -- не нашлось ни одного, даже анонимного, покупателя [разработки] фичи.
Диалектика.
> Почему - на самом деле ясно, из-за нетривиальности
> техническая реализация
У них много чего "каминг сун" с самого начала, и постепенно это все появляется.Полагаю, у них есть какой-то план, и они его придерживаются :-)
> У них много чего "каминг сун" с самого начала, и постепенно это
> все появляется.pro-версия-то с фичами только "для клиентов" -- есть, или я зря слюной брызжу? //ну, то есть, я-то пусто-порожне, но вы, я вижу, ближе к-
> Полагаю, у них есть какой-то план, и они его придерживаются :-)
Не, я не ближе, я просто активно слежу.Насколько мне известно, на данный момент про-версии нет, что в меркуриал-репозитории лежит - это все, что есть.
> параметры запуска которых можно изменять динамически без необходимости правки файлов конфигурации и перезапускаА по-нормальному-то (с изменением конфига) оно умеет работать?
Ты для начала пойди на википедию и ознакомимся с термином сервер приложений.Изменения в настройках приложения, таких, как изменение сервера базы данных или системных настроек, могут производиться централизованно.
А централизованные настройки у вас на бумажке хранятся и после перезагрузки (не дай боже) в ручную вбиваете? Расшарить скрипт - он же файл - это же очень просто надо городить сервер приложений и ни как иначе, а ещё можно протокол передачи под это придумать :)
> а ещё можно протокол передачи под это придуматьну что вы, коллега, зачем же изобретать велосипед с квадратными колесами, когда под рукой есть готовый с восьмиугольными?
У нас есть прекрасный rest api! Правда, теперь вместо текстового конфига, который либо читается, либо немедленно дает ошибку, у нас есть какой-то конфиг (лучше всего - в тазе банных, чтобы еще налететь на локи или тормоза и отдельно обработать эту ситуацию, когда, конечно, удастся ее вычленить как источник проблем), отдельно его парсилка (может распарсить, может поломаться, может содержать ошибку), отдельно скармливатель в сетевой сокет (еще десять мест для появления трудноуловимых проблем), отдельно парсер ответов в интуитивно-приятном формате.
зато у девопов всегда будет работа и зарплата... ну или хотя бы иногда их, наверное, будут кормить?
Когда допилят возможность использования Unit-Ruby на CentOS ?
А в чём там проблема?
CentOS сильно старый? Или там rack нет?
Обычный CentOS Linux release 7.5.1804. Под rvm модуль unit-ruby не собирается./bin/ld: build/src/ruby/nxt_ruby-ru244.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; перекомпилируйте с параметром -fPIC
/bin/ld: build/src/ruby/nxt_ruby_stream_io-ru244.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; перекомпилируйте с параметром -fPIC
"перекомпилируйте с параметром -fPIC"
И что, не помогает?
Нет, не помогает, при запуске... failed: "libruby.so.2.4: cannot open shared object file: No such file or directory ...
Нафик с пляжу такой софт.
Можно подробностей? Как собирали, устанавливали какие нибудь дополнительные флаги. Версия руби и как она была собрана?
Можете написать на почту или на гитхаб в https://github.com/nginx/unit/issues мы разберемся.Спасибо!
Да обычным образом:
# su - rdu1
$ gpg2 --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
$ curl -L https://get.rvm.io | bash -s stable
$ exit
# su - rdu1
$ rvm install 2.4
$ ruby -v
ruby 2.4.4p296 (2018-03-28 revision 63013) [x86_64-linux]
$ which ruby
~/.rvm/rubies/ruby-2.4.4/bin/ruby$ cd unit
$ ./configure
$ ./configure ruby --module=ru244
$ make ru244Помогает
$ export CFLAGS="-fPIC"
Но один бил не работает, не может найти libruby.so.2.4
Проделал на свежеустановленном CentOS, правда под рукой был 7.4, а не 7.5 - всё собралось и заработало без проблем, никаких CFLAGS="-fPIC" не понадобилось.Что показывает:
$ ruby -r rbconfig -e 'printf("%s",RbConfig::CONFIG["configure_args"])'
?
'--prefix=/home/rdu1/.rvm/rubies/ruby-2.4.4' '--disable-install-doc' '--enable-shared'
> '--prefix=/home/rdu1/.rvm/rubies/ruby-2.4.4' '--disable-install-doc' '--enable-shared'Скачал CentOS-7-x86_64-Minimal-1804.iso, установил в виртуалку, проделал все вышеописанные шаги, даже пользователя нового такого же завел и никаких проблем не возникло - собралось и заработало без правки CFLAGS.
У нас каждый коммит собирается билдботом на десятках различных систем и всевозможных архитектурах. В том числе там полно всяких CentOS-ов. И гоняются функциональные тесты.
Флаг -fPIC юнит устанавливает сам при сборке модуля, а также прописывает -rpath, чтобы загрузчик без труда мог найти libruby, даже если та находится в нестандартном месте. Но похоже по какой-то причине в вашем окружении все эти флаги не доходят до компилятора.
Чтобы разобраться что и где сломано нужно больше информации. Просьба показать полный вывод ./configure, ./configure ruby и make. А также cc -v.
Можно создать тикет на github.com/nginx/unit/issues, можно залить куда-нибудь и дать ссылку, а можно мне на почту vbart @ nginx.com
Очень странно, я специально чистую систему для теста Unit развернул по стандартной методике. Я постараюсь подготовить, но уже на следующей неделе.
Отправил на почту.
flask поддерживает?
Полгода назад - нет. С новыми версиями - без понятия.
Flask точно также использует интерфейс WSGI и работает с Unit-ом с самой первой публичной беты.
> Flask точно также использует интерфейс WSGI и работает с Unit-ом с самой
> первой публичной беты.понятно...
> В содержимом полей в заголовках запросов разрешено использовать символы в кодировке UTF-8Если я правильно помню спецификацию, в заголовках допускется только ascii
HTTP/2.0 умеет в бинарную кодировку с чанками.
Согласно RFC 7230 в значениях полей заголовка допускается c 0x20 по 0xFF.
Интересно, оно хотя бы позволяет теперь пускать что-то сложнее phpinfo
Учитывая, что с первого стабильного релиза там уже все прекрасно работало, а для таких как ты была статья про тот же вордпресс(https://www.nginx.com/blog/installing-wordpress-with-nginx-unit/)…
я успешно гонял большой навороченный сайт на битриксе в продакшне
Спасибо, вырвало