Разработчики проекта 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.dev/opennews/art.shtml?num=48434
> разные версии языков
> PerlСпасибо ребят за perl, будем изучать. Кажется я нашел где находится лучшее решение по организации test&&deploy поверх разных версии perl на базе NGINX Unit. Надо обкатать.
Что таки остались люди использующие перл в проде?
> Что таки остались люди использующие перл в проде?То чувство когда ты вдруг осознаешь что реальный мир вокруг отличается от твоего представления?
>> Что таки остались люди использующие перл в проде?
> То чувство когда ты вдруг осознаешь что реальный мир вокруг отличается от
> твоего представления?да знаем мы что в мире все еще воруют у археологов мумии программистов на коболе, знаем.
Не поверишь, но в мире есть люди, которые не только что закончили школу и сразу побежали на первую галеру писать на модном-молодёжном языке профессионального программирования жопаскрипт.
а сделали это все двадцать лет назад, и борода уже седая, а все та же цепь, почти не заржавела, и то же весло - почти и не стерлось?(кстати, имейте в виду, модным-современным пластиковым грести легче, чем этим вашим тесанным из цельной сосны, хотя мозоли первое время и будут мешать, а новые образуются не сразу и в других местах)
нет, серьезно - кому-то все еще *нравится* программировать вебню на перле? И не потому что ниасиляторы, ибо возраст уже не позволяет ничему научиться, а "есть законченные проекты на руби/питоне/жабе..ЭЭ/php на худой конец, для данной задачи перл подходит лучше" ?
ЫЫЫ
А чем вообще "вебня на перле" отличается от той же на "пестоне"?? У перла есть аналог ASP, позволяющий чётко выдавать контент. Сам язык - удобный, много полезных конструкций, есть ООП. Не писать на перле - это просто придумывать себе оправдания.
Ура! Дождались.
То есть чтобы определённую конфигурацию загрузить при старте/рестарте юнита, мне нужно завести скриптик вызывающий curl, чтобы он накидал юниту что и как делать.
Странно что это не предусмотрено изначально...
Странно, что ты вообще тогда нужен, если за тебя все можно сделать
> То есть чтобы определённую конфигурацию загрузить при старте/рестарте юнита, мне нужно
> завести скриптик вызывающий curl, чтобы он накидал юниту что и как
> делать.
> Странно что это не предусмотрено изначально...Смысл юнита в том что б менять конфиг на лету без рестарта.
> Смысл юнита в том что б менять конфиг на лету без рестарта.перечитать текстовый файл (и "без рестарта") модные-современные программисты ниасилили?
(и да, если мне понадобится этот файл передавать из "уеб-приложения" [с кучей грабель при таймауте/ошибке/проблемах в самом приложении по пути] - уж поверьте, я как-нибудь сумею написать сверхсложный интерфейс, который в одну дырку принимает его из того же nginx'а, а из другой записывает в предназначенное для конфигов место. И даже без unit для этой мегахайлоадной задачи обойдусь.)
Впрочем, после вебинара про mod_security у меня странные мысли про тех людей, которые работают в nginx co.
А разграничение прав в API насколько гибко-диференцированное, можно на отдельный сайт права раздавать, чтобы получить аналог .htaccess?
.access не нужны, координацию запросов должно выполнять приложение на любом языке программированияВ последние годы только используют index.php+static и подобные, а все остальное скрыто на уровне выше.
Очень даже нужны. Гораздо проще прописать один раз правило для редиректа (301-го, например) в .htaccess, чем дергать лишний раз тяжелое приложение для этого.
Это ведь не значит что нельзя, просто не рекомендуемый способ для application server.
Именно что нельзя...
> Очень даже нужны. Гораздо проще прописать один раз правило для редиректа (301-го,
> например) в .htaccess, чем дергать лишний раз тяжелое приложение для этого.... и тяжелое приложение для каждого запроса будет читать твой файлик и сканить рекурсивно папки замедляя работу сайта... Это же лучше чем просто перечитать конфиг командой reload?
> ... и тяжелое приложение для каждого запроса будет читать твой файлик иа по другому ты уже не умеешь? Вон из профессии!
> сканить рекурсивно папки замедляя работу сайта... Это же лучше чем просто
> перечитать конфиг командой reload?это лучше тем, что у тебя нет доступа к тому конфигу. Ибо им ты поломаешь не только свою косорукую поделку, но и соседние. Поэтому пиши заявку в жиру, мы лет через пять до нее доберемся и "перечитаем конфиг", предварительно проверив на тестовой ферме, специально под твое изменение собранной (это еще пару лет займет).
а мог бы ты писать в .htaccess - давно бы домой улетел.
(впрочем я знаю, ты вместо этого будешь рерайты и редиректы вместе с базовым контролем доступа пихать не в "тяжелое" приложение nginx, а в "легкую" хрень на пихоне/жабе/что там сегодня модно, всего пятьсот мегабайт rss с рестартом интерпретатора на каждый запрос)"папки" говорят сами за себя, ага. (и нет, чтение даже десятка .htaccess - ни разу не ресурсоемкая операция. Если сделать как надо, а не как ты cумеешь. В том числе потому, что файловые системы по сей день разрабатывают те кто умеют, а не разработчики на модных языках.)
блин, дайте какой-нибудь другой глобус, этот засран окончательно :-(
Если вам нужен htaccess, вам не нужен nginx unit.
> Если вам нужен htaccess, вам не нужен nginx unit.nginx unit не нужен, мы уже поняли.
> В последние годы только используют index.php+static и подобные, а все остальное скрыто
> на уровне выше.А может кто-то ответить по делу, нужны/не нужны это другой вопрос.
Я спрашивал насколько хорошо разграничиваются права на API, можно сделать аналог .htaccess или нет.
> А может кто-то ответить по делу, нужны/не нужны это другой вопрос.
> Я спрашивал насколько хорошо разграничиваются права на API, можно сделать аналог .htaccess
> или нет.нет. Сысоев никогда не работал в организациях, где админы веб-фронтендов и приложений - разные недружественные команды, тем более - никогда не занимался хостингом untrusted сайтов.
Поэтому в свое время эту вещь делать не стал, объявив что ему она не нужна и портит всю музыку.нынешние неспособны. Все на что их хватило, это вот выкатить на-гора универсальный fpm.
Так что и не ждите. Пишите скрипты/мэйкфайлы/юзерфрендли интерфейсы/чорта лысого для решения этой проблемы. Это всерьез и надолго, скорее всего - навсегда.
Нельзя и никогда не будет можно. Приложение для другого предназначалось. Отдельные права на отдельный сайт вы можете раздавать и в nginx, а прямой аналог .htaccess никогда не появится в nginx и ранее кучу раз обсуждалось почему он не нужен.
Данное приложение, если очень грубо и брать во внимание только работу с php, по своему принципу работы аналогично работе nginx + php-fpm + upstreams, но с возможностью менять настройки php-fpm без рестарта php. Эта штука больше заточена под hi-load. Для своего блога есть смысл продолжать использовать классическую связку nginx + php-fpm.
> аналог .htaccess никогда не появится в nginx и ранее кучу раз
> обсуждалось почему он не нужен.патамушта ниасиляторы, да. К этому все и сводилось. (и да, htaccess не так прост как кажется на первый взгляд, нормально реализовать его в существующей архитектуре нынешние манки-кодеры не смогут)
> upstreams, но с возможностью менять настройки php-fpm без рестарта php. Эта
> штука больше заточена под hi-load. Для своего блога есть смысл продолжатьнастоящему highload абсолютно фиолетово на рестарт единичного php-fpm. (который может и сам йапнутся от миллиона причин, или сервер под ним)
Это ваши блохи разбегаются, потому что он у вас вообще один-единственный.> использовать классическую связку nginx + php-fpm.
то есть ненужнейшее ненужно, я вас понял.
к php-fpm есть определенные претензии. Но вы явно не в курсе.
Все у тебя есть претензии ко всему, всех успел обосрать не приведя не одного адекватного аргумента. Тебе никто не хочет даже доказывать то, что есть в открытом доступе и 100500 раз обсуждалось.
Мне кажется что ты просто страдаешь неофобией, или просто идиот :)
>в шланги свинецкак там, у вас в 80х? андропов уже умер?
Вот еще один пример как язык С погибает :)
Чё-то я не понял - в чём радость?
Описали то, что можно делать в Apache.
Обычная система CGI что ли? А назвали-то! Сервер приложений...!