The OpenNET Project / Index page

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



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

"Первый стабильный релиз  сервера приложений NGINX Unit"  +/
Сообщение от opennews (??), 12-Апр-18, 22:07 
Разработчики проекта NGINX представили (https://www.nginx.com/blog/nginx-unit-1-0-released/) выпуск сервера приложений NGINX Unit 1.0 (http://unit.nginx.org/), в рамках которого подготовлено решение для обеспечения запуска web-приложений на различных языках программирования. Под управлением NGINX Unit может одновременно выполняться несколько приложений на разных языках программирования, параметры запуска которых можно изменять динамически без необходимости правки файлов конфигурации и перезапуска. Код  написан на языке Си и распространяется (https://github.com/nginx/unit) под лицензией Apache 2.0.


NGINX Unit обслуживает отдачу динамического контента самостоятельно, но также способен работать (http://unit.nginx.org/docs-integration-with-nginx.html) в тандеме с http-сервером nginx, который может выступать в роли балансировщика, кэша или сервера для отдачи статического контента. Изменение параметров запуска приложений производится через специальный  RESTful JSON API (http://unit.nginx.org/docs-configuration.html). RESTful API позволяет управлять работой сервера приложений удалённо и централизовано. Доступ к API может быть организован через UNIX domain socket или TCP.


Особенностью реализации является то, что изменение настроек не приводит к перезапуску рабочих процессов - меняются только содержимое структур в памяти, что сводит к минимуму накладные расходы и позволяет менять параметры с любой интенсивностью.  Одновременно под управлением NGINX Unit может выполняться несколько приложений на разных языках программирования, в том числе могут сочетаться разные версии языков Python, PHP, Perl, Ruby и  Go.

Функциональность NGINX Unit образует несколько процессов:


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


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

С правами root выполняется только главный управляющий процесс, а все остальные обработчики запускаются под отдельными непривилегированными пользователями.

Из функциональных изменений по сравнению с выпуском 0.7, отмечается (https://github.com/nginx/unit/blob/master/CHANGES) появление средств для ведения логов доступа (access_log). Запросы на изменение конфигурации через API теперь должны посылаться на URL /config/. Для пользователей, которые хотят на практике оценить возможности NGINX Unit подготовлена (https://www.nginx.com/blog/installing-wordpress-with-nginx-unit/) статья с примерном установки   системы управления контентом WordPress для запуска под управлением  данного сервера приложений.

URL: http://mailman.nginx.org/pipermail/unit/2018-April/000049.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=48434

Ответить | Правка | Cообщить модератору

Оглавление

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

2. Сообщение от Аноним (-), 12-Апр-18, 23:24   +6 +/
> разные версии языков
> Perl

Спасибо ребят за perl, будем изучать. Кажется я нашел где находится лучшее решение по организации test&&deploy поверх разных версии perl на базе NGINX Unit. Надо обкатать.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16

4. Сообщение от Aukamo (ok), 13-Апр-18, 02:47   +2 +/
Ура! Дождались.
Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от Аноним (-), 13-Апр-18, 03:39   +/
То есть чтобы определённую конфигурацию загрузить при старте/рестарте юнита, мне нужно завести скриптик вызывающий curl, чтобы он накидал юниту что и как делать.
Странно что это не предусмотрено изначально...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #19

6. Сообщение от кверти (ok), 13-Апр-18, 04:06   –2 +/
Странно, что ты вообще тогда нужен, если за тебя все можно сделать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

8. Сообщение от evkogan (?), 13-Апр-18, 08:48   –1 +/
А разграничение прав в API насколько гибко-диференцированное, можно на отдельный сайт права раздавать, чтобы получить аналог .htaccess?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #18

9. Сообщение от Аноним (-), 13-Апр-18, 11:41   +2 +/
.access не нужны, координацию запросов должно выполнять приложение на любом языке программирования

В последние годы только используют index.php+static и подобные, а все остальное скрыто на уровне выше.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #10, #12

10. Сообщение от Василий Топоровemail (?), 13-Апр-18, 11:48   +/
Очень даже нужны. Гораздо проще прописать один раз правило для редиректа (301-го, например) в .htaccess, чем дергать лишний раз тяжелое приложение для этого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #11, #21, #22

11. Сообщение от Аноним (-), 13-Апр-18, 12:08   +/
Это ведь не значит что нельзя, просто не рекомендуемый способ для application server.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #20

12. Сообщение от evkogan (?), 13-Апр-18, 14:34   +/
> В последние годы только используют index.php+static и подобные, а все остальное скрыто
> на уровне выше.

А может кто-то ответить по делу, нужны/не нужны это другой вопрос.
Я спрашивал насколько хорошо разграничиваются права на API, можно сделать аналог .htaccess или нет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #32

16. Сообщение от RudW0lfemail (?), 13-Апр-18, 17:48   +/
Что таки остались люди использующие перл в проде?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #23, #27

18. Сообщение от Anonimus (??), 13-Апр-18, 18:20   +/
Нельзя и никогда не будет можно. Приложение для другого предназначалось. Отдельные права на отдельный сайт вы можете раздавать и в nginx, а прямой аналог .htaccess никогда не появится в nginx и ранее кучу раз обсуждалось почему он не нужен.
Данное приложение, если очень грубо и брать во внимание только работу с php, по своему принципу работы аналогично работе nginx + php-fpm + upstreams, но с возможностью менять настройки php-fpm без рестарта php. Эта штука больше заточена под hi-load. Для своего блога есть смысл продолжать использовать классическую связку nginx + php-fpm.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #31

19. Сообщение от Anonimus (??), 13-Апр-18, 18:21   +/
> То есть чтобы определённую конфигурацию загрузить при старте/рестарте юнита, мне нужно
> завести скриптик вызывающий curl, чтобы он накидал юниту что и как
> делать.
> Странно что это не предусмотрено изначально...

Смысл юнита в том что б менять конфиг на лету без рестарта.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #30

20. Сообщение от Anonimus (??), 13-Апр-18, 18:22   +/
Именно что нельзя...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

21. Сообщение от Anonimus (??), 13-Апр-18, 18:26   +/
> Очень даже нужны. Гораздо проще прописать один раз правило для редиректа (301-го,
> например) в .htaccess, чем дергать лишний раз тяжелое приложение для этого.

... и тяжелое приложение для каждого запроса будет читать твой файлик и сканить рекурсивно папки замедляя работу сайта... Это же лучше чем просто перечитать конфиг командой reload?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #33

22. Сообщение от KonstantinB (ok), 13-Апр-18, 19:19   +2 +/
Если вам нужен htaccess, вам не нужен nginx unit.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #34

23. Сообщение от Аноним (-), 13-Апр-18, 19:23   +5 +/
>  Что таки остались люди использующие перл в проде?

То чувство когда ты вдруг осознаешь что реальный мир вокруг отличается от твоего представления?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #29

24. Сообщение от Аноним (-), 13-Апр-18, 20:00   +/
>в шланги свинец

как там, у вас в 80х? андропов уже умер?

Ответить | Правка | Наверх | Cообщить модератору

25. Сообщение от Аноним (-), 15-Апр-18, 01:07   –2 +/
Вот еще один пример как язык С погибает :)
Ответить | Правка | Наверх | Cообщить модератору

26. Сообщение от rvs2016 (ok), 16-Апр-18, 19:14   –2 +/
Чё-то я не понял - в чём радость?
Описали то, что можно делать в Apache.
Обычная система CGI что ли? А назвали-то! Сервер приложений...!
Ответить | Правка | Наверх | Cообщить модератору

27. Сообщение от антончик (?), 16-Апр-18, 19:35   +1 +/
Не поверишь, но в мире есть люди, которые не только что закончили школу и сразу побежали на первую галеру писать на модном-молодёжном языке профессионального программирования жопаскрипт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #28

28. Сообщение от пох (?), 17-Апр-18, 09:43   +2 +/
а сделали это все двадцать лет назад, и борода уже седая, а все та же цепь, почти не заржавела, и то же весло - почти и не стерлось?

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

нет, серьезно - кому-то все еще *нравится* программировать вебню на перле? И не потому что ниасиляторы, ибо возраст уже не позволяет ничему научиться, а "есть законченные проекты на руби/питоне/жабе..ЭЭ/php на худой конец, для данной задачи перл подходит лучше" ?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #35, #38

29. Сообщение от пох (?), 17-Апр-18, 09:44   –4 +/
>>  Что таки остались люди использующие перл в проде?
> То чувство когда ты вдруг осознаешь что реальный мир вокруг отличается от
> твоего представления?

да знаем мы что в мире все еще воруют у археологов мумии программистов на коболе, знаем.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

30. Сообщение от пох (?), 17-Апр-18, 17:48   +1 +/
> Смысл юнита в том что б менять конфиг на лету без рестарта.

перечитать текстовый файл (и "без рестарта") модные-современные программисты ниасилили?

(и да, если мне понадобится этот файл передавать из "уеб-приложения" [с кучей грабель при таймауте/ошибке/проблемах в самом приложении по пути] - уж поверьте, я как-нибудь сумею написать сверхсложный интерфейс, который в одну дырку принимает его из того же nginx'а, а из другой записывает в предназначенное для конфигов место. И даже без unit для этой мегахайлоадной задачи обойдусь.)

Впрочем, после вебинара про mod_security у меня странные мысли про тех людей, которые работают в nginx co.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

31. Сообщение от пох (?), 17-Апр-18, 17:55   +/
> аналог .htaccess никогда не появится в nginx и ранее кучу раз
> обсуждалось почему он не нужен.

патамушта ниасиляторы, да. К этому все и сводилось. (и да, htaccess не так прост как кажется на первый взгляд, нормально реализовать его в существующей архитектуре нынешние манки-кодеры не смогут)

> upstreams, но с возможностью менять настройки php-fpm без рестарта php. Эта
> штука больше заточена под hi-load. Для своего блога есть смысл продолжать

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

> использовать классическую связку nginx + php-fpm.

то есть ненужнейшее ненужно, я вас понял.

к php-fpm есть определенные претензии. Но вы явно не в курсе.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #37

32. Сообщение от пох (?), 17-Апр-18, 17:59   +1 +/
> А может кто-то ответить по делу, нужны/не нужны это другой вопрос.
> Я спрашивал насколько хорошо разграничиваются права на API, можно сделать аналог .htaccess
> или нет.

нет. Сысоев никогда не работал в организациях, где админы веб-фронтендов и приложений - разные недружественные команды, тем более - никогда не занимался хостингом untrusted сайтов.
Поэтому в свое время эту вещь делать не стал, объявив что ему она не нужна и портит всю музыку.

нынешние неспособны. Все на что их хватило, это вот выкатить на-гора универсальный fpm.

Так что и не ждите. Пишите скрипты/мэйкфайлы/юзерфрендли интерфейсы/чорта лысого для решения этой проблемы. Это всерьез и надолго, скорее всего - навсегда.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

33. Сообщение от пох (?), 17-Апр-18, 18:09   –3 +/
> ... и тяжелое приложение для каждого запроса будет читать твой файлик и

а по другому ты уже не умеешь? Вон из профессии!

> сканить рекурсивно папки замедляя работу сайта... Это же лучше чем просто
> перечитать конфиг командой reload?

это лучше тем, что у тебя нет доступа к тому конфигу. Ибо им ты поломаешь не только свою косорукую поделку, но и соседние. Поэтому пиши заявку в жиру, мы лет через пять до нее доберемся и "перечитаем конфиг", предварительно проверив на тестовой ферме, специально под твое изменение собранной (это еще пару лет займет).

а мог бы ты писать в .htaccess - давно бы домой улетел.
(впрочем я знаю, ты вместо этого будешь рерайты и редиректы вместе с базовым контролем доступа  пихать не в "тяжелое" приложение nginx, а в "легкую" хрень на пихоне/жабе/что там сегодня модно, всего пятьсот мегабайт rss с рестартом интерпретатора на каждый запрос)

"папки" говорят сами за себя, ага. (и нет, чтение даже десятка .htaccess - ни разу не ресурсоемкая операция. Если сделать как надо, а не как ты cумеешь. В том числе потому, что файловые системы по сей день разрабатывают те кто умеют, а не разработчики на модных языках.)

блин, дайте какой-нибудь другой глобус, этот засран окончательно :-(

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

34. Сообщение от пох (?), 17-Апр-18, 18:10   +/
> Если вам нужен htaccess, вам не нужен nginx unit.

nginx unit не нужен, мы уже поняли.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

35. Сообщение от maxemail (??), 20-Апр-18, 09:47   +/
ЫЫЫ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

37. Сообщение от нет (??), 18-Сен-18, 23:46   +/
Все у тебя есть претензии ко всему, всех успел обосрать не приведя не одного адекватного аргумента. Тебе никто не хочет даже доказывать то, что есть в открытом доступе и 100500 раз обсуждалось.
Мне кажется что ты просто страдаешь неофобией, или просто идиот :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

38. Сообщение от Gogi (??), 09-Окт-20, 12:51   +/
А чем вообще "вебня на перле" отличается от той же на "пестоне"?? У перла есть аналог ASP, позволяющий чётко выдавать контент. Сам язык - удобный, много полезных конструкций, есть ООП. Не писать на перле - это просто придумывать себе оправдания.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28


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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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