Только что на конференции NginxConf в Портленде Nginx, Inc. объявил о запуске Nginx Application Platform. ITSumma тестировала один из его компонентов, собственно сам Application Server под названием Nginx Unit с закрытой версии. В этом посте мы расскажем о том, как выглядит Nginx Unit, и как на нем запускать приложения.
Nginx Unit — это сервер приложений для веба, позволяющий запускать веб-приложения, написанные на различных языках программирования (php, python, go). Этот инструмент достаточно легок и позволяет на лету переконфигурировать настройки и количество приложений по мере необходимости при разработке.
> Основной сайт проекта
Поддерживаемые на текущий момент платформы:
— Python 2.6, 2.7, 3
— PHP 5, 7
— Go 1.6 or later
Важная и крутая возможность для людей с зоопарком платформ: разные версии одной и той же платформы можно запустить в рамках одного конфига, одного аппсервера — прощай, зоопарк PHP-FPM-ов.
> Исходный код проекта загружен на Гитхаб.
Что классно и интересно: ребята загрузили на Гитхаб код начиная с первого коммита и обещают принимать пулл-реквесты в классическом для Гитхаба стиле. Среди всего прочего можно посмотреть историю, логику и стиль разработки — очень интересно.
Установка
Важно: текущая версия все еще бета, с огромным количеством отладочного кода, который добавляет свой оверхед. В следующих версиях обещают значительную оптимизацию, которая должна переплюнуть текущие апп-серверы по производительности.
Пакеты сейчас доступны для CentOS 7.0 и Ubuntu 16.04 LTS
Установка для CentOS 7
1. Создайте файл /etc/yum.repos.d/unit.repo со следующим содержимым:
[unit]
name=unit repo
baseurl=http://nginx.org/packages/mainline/centos/7/$basearch/
gpgcheck=0
enabled=12. Запустите установку пакета:
# yum install unitУстановка для Ubuntu 16.04
1. Скачайте PGP-ключ NGINX, Inc.
2. Добавьте ключ в связку ключей apt. После этого не должно быть оповещений об отсутствующем PGP-ключе во время установки Unit.
# sudo apt-key add nginx_signing.key3. Добавьте в конец файла /etc/apt/sources.list строки:
deb http://nginx.org/packages/mainline/ubuntu/ xenial nginx
deb-src http://nginx.org/packages/mainline/ubuntu/ xenial nginx4. Скачайте Unit:
# apt-get update
# apt-get install unitNginx Unit состоит из нескольких служебных процессов (master/controller/router) и непосредственно самих процессов-приложений. Конфигурация производится через REST API, через юникс сокет unit.control.sock.
Получение текущего конфига
curl --unix-socket ./control.unit.sock http://localhost/Загрузка нового
curl -X PUT -d @/path/to/start.json --unix-socket ./control.unit.sock http://localhost/Конфигурация состоит из набора приложений (application) и воркеров (listener).
Запуск приложения
Рассмотрим запуск приложения на примере запуска «1С-Битрикс» и Laravel:
Фронтэндом выступает классический nginx, а бэкэндом — Nginx Unit. Сейчас каждое «приложение» Nginx Unit для PHP подразумевает одну точку входа. В случае с Битриксом их может быть две — urlrewrite.php и index.php, соответственно в бете — нужно либо объединить эту логику в один файл в коде, либо запускать два приложения. В ближайших версиях Nginx Unit ребята обещают сделать роутинг, чтобы избежать этой проблемы.
Конфигурация для Laravel:
location / {
proxy_pass http://127.0.0.1:8300;
proxy_redirect http://127.0.0.1:8300/ /;
proxy_read_timeout 60s;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location ~ \.php$ {
proxy_pass http://127.0.0.1:8300;
proxy_redirect http://127.0.0.1:8300/ /;
proxy_read_timeout 60s;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}Конфигурация для «1С-Битрикс»:
location = / {
proxy_pass http://127.0.0.1:8601;
proxy_redirect http://127.0.0.1:8601/ /;
proxy_read_timeout 60s;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
break;
}
location / {
try_files $uri /bitrix/urlrewrite.php =404;
proxy_pass http://127.0.0.1:8600;
proxy_redirect http://127.0.0.1:8600/ /;
proxy_read_timeout 60s;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}Для замены конфигурации запускаем
curl -X PUT -d @/path/to/start.json --unix-socket ./control.unit.sock http://localhost/(По-умолчанию — сокет, проксировать с сокета в TCP порт можно посредством nginx.)
В настоящий момент конфигурацию надо подгружать при запуске апп-сервера, в следующих версиях Unit будет сохранять загруженную конфигурацию при перезапуске.
Сначала перечисляем приложения, при этом для каждого приложения указываем версию интерпретатора. В качестве точки входа можно указать параметр index (и тогда скрипт будет браться из строки запроса), или, в случае точки входа, script — и тогда запросы будут идти на конкретный скрипт. Опять же, обратите внимание, для «1С-Битрикс» запускаются два приложения:
Конфиг:
{
"applications": {
"laravel": {
"type": "php 7.0",
"user": "nobody",
"group": "nobody",
"workers": 2,
"root": "/var/www/vhosts/laravel/public",
"script": "index.php",
},
"plain": {
"type": "php 7.0",
"user": "nobody",
"group": "nobody",
"workers": 2,
"root": "/var/www/vhosts/test",
"index": "index.php"
},
"bitrix": {
"type": "php 5.6",
"user": "nobody",
"group": "nobody",
"workers": 2,
"root": "/var/www/vhosts/bitrix",
"script": "/bitrix/urlrewrite.php"
},
"bitrix_index": {
"type": "php 5.6",
"user": "nobody",
"group": "nobody",
"workers": 2,
"root": "/var/www/vhosts/bitrix",
"script": "index.php"
}
}, Затем апы вешаются на порты:
"listeners": {
"*:8300": {
"application": "laravel"
},
"*:8500": {
"application": "plain"
},
"*:8600": {
"application": "bitrix"
},
"*:8601": {
"application": "bitirx_index"
}
}
} Мы все ждали этого довольно давно, однако давайте все-таки рассмотрим случаи, когда Unit принесет серьезное преимущество:
- гетерогенная инфраструктура приложения. Сейчас в рамках одного app-сервера можно держать разные версии PHP, запускать Python и Go. К концу года ожидается NodeJS, Java и, возможно, Ruby. Все это в одном конфиге, одном и том же app-сервере. Приложения больше не пишут на одном языке, и это действительно облегчит всем нам жизнь.
- зоопарк версий на одной системе. Устали от многочисленных конфигураций и сборок fpm с разными версиями? Теперь это может быть запущено в пределах одного приложения. Понятно, что это не «чистая» ситуация, но она часто встречается и, опять же — серьезное облегчение жизни.
- если пункты 1 и 2 мы чувствуем на себе, то третий, о котором говорит Nginx, еще предстоит попробовать. Единое и простое управление конфигурацией микросервисной архитектурой. Единая система управления конфигурациями через REST API, единый продукт в целом.
Пока Application Platform еще бета, но уже можно пробовать и готовить свои конфигурации к продакшену. Ждем дальнейших новостей!
Комментарии (105)
schors
07.09.2017 00:48-7Я бы поспорил. Как раз сейчас тренд писать приложения на одном языке.
Документация ни к черту. Я например не могу найти где про «в рамках одного app-сервера можно держать разные версии PHP»
eapotapov Автор
07.09.2017 01:35+5хмм, ну не знаю.
из того что мы видим в целом (не привязываясь только к веб-аппликейшнам) «продукт» становится очень разрозненным, причем это происходит по всем направлениям.
больше нет одного мониторинга для всего (смотрим за инфраструктрой в прометеусе, за приложением в ньюрелике, шлем логи в ELK итп), больше нет «одного приложения», есть несколько проектов с нодой и руби на фронте, с питоном в бэкэнде, делают это разные команды с разными компетенциями и так далее.
как раньше собирали софт и кубиков/библиотек, так теперь кубики это «компентенции» групп разработчиков — ктото специализируется на фронте и они же пишут часть бэкэнда на ноде, _очень_ часто при этом может быть вообще какой-то старый кусок на PHP, ну и так далее.
также с базами, при всей противоречивости монги, очень часто видим монгу на фронте, постгрес и кликхаус на аналитике.
да, это сложнее и я до конца это не одобряю, но такой мир (имхо, могу быть и не прав ;) )
hamnsk
07.09.2017 12:48отвечу вам, вы действительно не правы.
Каждому сервису свой конфиг и своя платформа… зоопарки обычно живут на стейджах, и дев серверах, когда тот жже кликхаус живет рядом с постгресом нодой и фпм… в большом энтерпрайзе много автоматики, много серверов и сервера распределяются по ролям…selivanov_pavel
07.09.2017 22:29+1Насколько я понимаю, фишка не в том, чтобы держать на одном сервере и руби, и питон, и пхп — для этого есть контейнеры, виртуалки и так далее. А в том, что одна и та же софтина используется как app server для всего зоопарка языков/сервисов. Чем меньше разного софта — тем легче всё это сопровождать, обновлять и чинить когда сломается.
kamenevn
07.09.2017 12:25У нас, к примеру, один проект нельзя перевести на php 7, поэтому он живет на 5.6. А рядом живет проект на php 7.
У более-менее крупных проектов все переписывается на микросервисы, а микросервисы могут быть на разных языках.
Ipeacocks
07.09.2017 14:09+1Я бы точнее сказал, что в контейнере у вас приложение на 5.6, а не микросервис.
schors
07.09.2017 00:50Или вот чем отличается go application от просто binary application…
oxpa
07.09.2017 10:04+1Для интеграции с go предоставляется замена стандартной net/http либе
VBart
07.09.2017 11:19Верно. Мы не проксируем на Go, мы заменяем его сетевую либу.
schors
07.09.2017 11:20А где об этом почитать можно?
VBart
07.09.2017 11:28Пока что тут: http://unit.nginx.org/docs-installation.html#building-the-go-applications
Документация будет улучшаться. Это пока первые эскизы.
Если кратко, то вся модификация Go приложений для запуска в Unit сводится к добавлению модуля
unit:
import { "fmt" "net/http" "unit" }
и замене обработчика
http.ListenAndServe(":8080", nil)
на
unit.ListenAndServe(":8080", nil)
при этом заданный порт имеет значение только при запуске вне юнита, в этом случае происходит фоллбек вhttp.ListenAndServe(). Юнит указанный порт игнорирует, слушающий сокет уже конфигурируется в самом юните.
alehano
07.09.2017 13:53Не совсем понял как разрабатывать? Ведь на dev машине не будет пакета «unit».
VBart
07.09.2017 18:16Почему не будет? Кто помешает поставить его из репозитория, так же как и Go?
Aleksi
07.09.2017 19:56+5Как минимум, своеобразный import path: все известные мне тулзы, включая саму утилиту go, будут считать, что это пакет стандартной библиотеки. Если вы сделаете путь вроде github.com/nginx/go-unit, и положите пакет туда, вы избавите людей от большой головной боли.
mobilz
07.09.2017 15:35правильно я понимаю, что unit.ListenAndServe(":8080", nil) делает сокет для unit, а если его нет поднимает http на 8080?
VBart
07.09.2017 18:19+2Сокеты это лишние накладные расходы. Там все сложнее. Он общается с процессами юнита посредством нашего RPC, который построен на разделяемой памяти. Модуль как раз подсоединяет приложение на Go к этому RPC, когда запускается процессом юнита.
EvilFox
07.09.2017 22:38+2Спасибо, месяцами ранее рыл инет на тему подобного интеграции чтоб без накладных расходов проксирования, находил только какие-то недоделки, и вот оно!
Особенно учитывая вот эти тесты: https://gist.github.com/hgfischer/7965620 это может быть довольно насущно.
Вы уже сравнивали производительность?VBart
07.09.2017 23:17+1На данный момент там много всякого дебага и часть кода написана в стиле «proof-of-concept». Сейчас сравнивать производительность бессмысленно. Но архитектура спроектирована так, чтобы добавлять минимум накладных расходов и выжать максимум из приложений. К моменту выпуска первой стабильной версии доведем до ума и можно будет тестировать.
dgstudio
07.09.2017 01:07+4Пхп, питон… А ruby, ruby-то где?
VBart
07.09.2017 01:19+3Будет.
fend
07.09.2017 02:41+4а node.js?)
VBart
07.09.2017 02:51Вот тут примерный план на ближайшее время:
http://unit.nginx.org/docs-nginx-unit.html#supported-application-languagescaban
07.09.2017 07:12+1Под Java подразумевается весь JVM или только конкретно конкретно JAVA? То есть будет ли поддержка, языков на базе JVM?
VBart
07.09.2017 08:38+3Java — один из самых сложных стеков в плане интеграции. Пока только исследуем возможности. В начале скорее всего появится что-то из наиболее востребованных решений.
nomoreload
07.09.2017 10:50+1ASP.NET Core не планируется в виде нативного модуля?
VBart
07.09.2017 10:56+1Сегодня на конференции подходил человек из Microsoft, то же самое спрашивал. Возможно, надо смотреть.
onyxmaster
07.09.2017 13:19Я не думаю что это слишком сложно, если забить на reload.
onyxmaster
09.09.2017 09:26+1
knutov
09.09.2017 04:30+2а почему все вешается на tcp сокеты? Как быть тем, кто очень хочет экономить и использовать unix сокеты?
9660
07.09.2017 07:19+2Я может не понял сути.
А где этот unit возьмет какие нибудь специфические модули для того же php?
Или весь pecl будет поддерживаться?VBart
07.09.2017 08:42Там же, где и php-fpm или mod_php. Мы собираем свой собственный SAPI модуль для php-интерпретатора и линкуемся с libphp.
9660
07.09.2017 08:50Так php-fpm собираю я лично под свои задачи.
А unit собираете вы. Откуда вам знать что именно мне нужно?VBart
07.09.2017 08:53+1Никто не мешает вам собирать libphp под ваши собственные задачи, мы лишь подключаемся к стандартному SAPI, который един и не зависит от сборки.
9660
07.09.2017 09:16Спасибо, стало понятнее.
Еще вопрос. Посмотрел пакет собранный под убунту. Там у php.unit.so зависимость libphp7.so.
А как происходит работа с php5?VBart
07.09.2017 09:19+1Нужно собрать
php5.unit.soс зависимостью отlibphp5.so. Пакеты в наших репозиториях идут только с тем, что доступно в системных репозиториях.9660
07.09.2017 09:23Большое спасибо!
VBart
07.09.2017 09:28+4Я, например, вот так у себя в gentoo собираю три разных php-модуля для юнита:
$ ./configure php --module=php56 --config=/usr/lib64/php5.6/bin/php-config --lib-path=/usr/lib64/php5.6/lib64 $ ./configure php --module=php70 --config=/usr/lib64/php7.0/bin/php-config --lib-path=/usr/lib64/php7.0/lib64 $ ./configure php --module=php71 --config=/usr/lib64/php7.1/bin/php-config --lib-path=/usr/lib64/php7.1/lib64```schors
07.09.2017 11:22Хотя бы вот это бы в документацию. Потому что она не даёт «всей панорамы». А это вообще самое важное в документации
VBart
07.09.2017 11:29Вроде кое-что есть: http://unit.nginx.org/docs-installation.html#configuring-php-modules
shurutov
07.09.2017 12:22Под gentoo ручками что-то собирать?! o_O
Я удивлён.
Эххх, кто бы меня пнул в субботу/воскресенье — надо обязательно ебилд нарисовать, ибо хочется, однако! Благо есть куда запихать вместо всяких php-fpm-ов и прочих разных обёрток...VBart
07.09.2017 18:15Для разработки, почему нет. Не в систему же мне его после каждой правки кода ставить. =)
ebuild конечно хорошо было бы сделать и положить в репозиторий дженту.shurutov
07.09.2017 18:27+1Да я в своей практике частенько сталкивался с тем, что emerge <> быстре и дешевле обходились, нежели ручками собирать, особенно вот в таких хитрых конфигурациях, когда надо несколько вариантов собирать.
Ну и эксплуатация — профдеформация, однако! Низзя засорять систему! :)
SonicGD
07.09.2017 08:09+28> мы все задавались вопросом: когда же на nginx можно будет запускать приложения
Нет, не задавались. Наоборот, радовались, что Nginx такой клёвый и лёгкий и не берёт на себя все задачи в мире, в отличие от Apache.
А с появлением докера запуск разных версий пхп и смешивание технологий в одном проекте чрезвычайно упростились. Зачем это всё сейчас в Nginx — непонятно.caban
07.09.2017 08:44+8Как я понимаю, ничего не мешает, так же продолжать пользоваться nginx. Unit это отдельный продукт.
n0madic
07.09.2017 12:23+2Так оно и не в Nginx — по сути они сделали свой *-FPM и с Nginx у них общего только компания-разработчик. Даже конфиг в виде, не самого удобного для этого дела, JSON.
Я понимаю еслиб они это реализовали в виде динамических модулей к Nginx — подгрузил в конфиге и все работает, правда стабильность самого веб-сервера будет уже под вопросом… :)
SirEdvin
07.09.2017 10:30+1Это все, конечно, замечательно, но у нас уже есть, например, docker.
Не совсем понимаю, зачем такая фигня, учитывая, что, скорее всего, настройка дополнительных типов будет сложной.dikkini
07.09.2017 11:32+1docker в продакшене не всегда удачный выбор. иногда слишком «дорого»
SirEdvin
07.09.2017 11:43+2Хм… в чем именно дорого, не подскажите? Если использовать его без изоляции по сети и использовать только хостовые volume, то оверхед должен быть минимальный, если верить исследователям percona.
Если вы не про производительность, то тем более странно. Вряд ли удобнее будет через nginx хостить кучу разных версий python проектов, чем просто docker контейнеры.
dikkini
07.09.2017 11:48-1гораздо удобнее и дешевле в плане обслуживания и администрирования вместо докер использовать виртуализацию VMWare и нарезать маленькие виртуалки в ней, а уже там обычный app и если раньше это были скрипты ansible по накатке nginx+uwsgi то скоро это будет обычный процесс установки Application сервера, накатывание готовой конфигурации с минимум динамичных параметров и деплой кодовой базы.
SirEdvin
07.09.2017 11:54+3- Виртуализация VMWare как бы платная
- Виртуалки — это лишний оверхед. К тому же, очень большое количество используемых серверов уже виртуалки. Виртуалки в виртуалках — очень странно.
- Не понимаю, чем это будет отличатся от установки docker демона и накатывания готовой конфигурации? Проблема будет лишь в том, что, если вам нужно будет добавить какие-то дополнительные либы к python, то вы будете это делать собирая свой модуль к application серверу, если я правильно понял. Сейчас такой возможности нет.
Ну и + как вот тут отметили, реальная пользая такой штуки — систематизация. Как бы, через docker можно сделать так же, только вот плюшек больше. Включая запуск разных OS, окружений и прочего для проекта. Например, как при помощи nginx application можно будет запустить проекты, которые требует разные версии одной библиотеки?
VBart
07.09.2017 12:09Например, как при помощи nginx application можно будет запустить проекты, которые требует разные версии одной библиотеки?
В статье выше люди запускают две разных версии PHP, каждая использует свою собственную libphp.so (которые в свою очередь могли быть собраны со своими зависимостями). Я запускал одновременно приложения на 3-х разных версиях PHP, 2-х версиях Python и Go. Вообще это ни чем не ограничено.
Магия и секретные технологии. =)SirEdvin
07.09.2017 12:12+2Возможно я плохо читаю.
Подскажите, пожалуйста, как тогда указать разные версии интерпретаторов для python? Мне же их все равно нужно будет собирать и подсовывать application, или я не прав?
Так же, libphp.so это отлично, а подменить, скажем, системную библиотеку, как я понимаю, не получится. Хотя это уж совсем редкий случай.
VBart
07.09.2017 18:13Application на python — это собственно сам набор python скриптов, их собирать не надо, они компилируются в опкод самим cpython. Для запуска ваших .py скриптов с нужной версией cpython необходимы лишь соответствующие модули для юнита собранные с соответствующими версиями cpython. Пакеты с модулями юнита можно установить из репозитория, либо собрать самостоятельно.
Во многих дистрибутивах сейчас как минимум две версии cpython, ветки 2 и ветки 3. Соответственно и пакеты для них мы будем собирать сами, либо это будут делать майнтейнеры дистрибутива.
А если вам нужен какой-то особенный cpython, которого нет в репозиториях, то вы же его собираете так или иначе. Просто соберите динамический модуль для юнита с ним и юнит сможет его загружать и использовать для запуска ваших приложений на пайтоне.SirEdvin
07.09.2017 18:16+1Простите, что вас отвлекаю, но вы немного не поняли мой вопрос. Как мне, например, использовать virtualenv в связке с nginx unit? Я просто просмотрел доку и не нашел ответа :(
VBart
07.09.2017 18:27Такая возможность будет. Пока мы в стадии ранней беты, но планируем довести стабильность и функциональность до хорошего состояния и выпустить осмысленный релиз в начале 2018. Сейчас можно просто покрутить, поиграться, написать побольше фичреквестов.
dikkini
07.09.2017 19:06-1- Есть почти бесплатный RHEV, есть бесплатный KVM и OpenNebula
- Какой оверхед? Где? Виртуалки в виртуалках? Я о таком не говорил.
- docker это отдельный контейнер со своими проблемами. Виртуалка более надежна. И как раз docker более похож на виртуалку в виртуалке, если виртуализация уже есть.
SirEdvin
07.09.2017 19:09+1- Вот я не из большой компании, у меня почти все сервера vps. Какую технологию мне тут применить?
- Если вам не нравится docker, то почему бы не попробовать systemd-nspawn? Контейнеризация не виртуализация со своими проблемами, ну так их и в случае виртуалочек полно. Вот VMWare все еще не поддерживает нормально ядро Linux 4+ (по заверениям хостинга, с которым сотрудничают наши заказчики), как быть?
dikkini
07.09.2017 19:16Я говорю с позиции построения больших, распределенных систем. В случае веб сервиса на 4 сервера — тут можно и без докеров вообще в продакшене, а вот тест организовать на докерах. Я боюсь переводить продакшен на докеры (60+ контейнеров) без отдельного штата администраторов и продуманного мониторинга. А еще лучше написать автоматизированного администратора (была на highload компания, которая написала свою тулзу для выполнения рутинных администраторских задач, monkey что-то там).
Godless
07.09.2017 10:54Я правильно понимаю, что это просто прослойка для нативного запуска разных интерпретаторов с плюшками в виде dynamic config и т.п.?
И основное назначение сия творения — различные сервера приложений (именно где много проектов) на хостингах/девелопер серверах. Проблему наличия зоопарка интерпретаторов оно не решает, но пытается систематизировать и сделать конфигурабельным. так?
Пример с битриксом. Статику отдает nginx, редиректы в nginx. unit заменил только fpm.
Есть какие-то плюсы на серваках под 1 проект с 1 языком? Тот же битрикс, чтоб его.
VBart
07.09.2017 11:11Приблизительно. Я лишь добавлю, что предполагается удобное и единообразное конфигурирование, так что будет проще использовать и без зоопарка, для своего личного блога, например.
Обучить статике и редиректам — вопрос времени.
psvmcc
07.09.2017 10:58Единственный момент, пакеты для CentOS 7 и Ubuntu 16.04 доступны в mainline репозиториях, а не stable.
AterCattus
07.09.2017 12:28+1Что-то не осознал, как компилируемые ЯП интегрируются. Связь через сокеты? Не вкомпиливается же оно в воркеры этого юнита.
ibKpoxa
07.09.2017 12:29А в случае использования php в данном случае используется версия без поддержки персистентных коннектов?
Как работает opcache?
Есть какие-то бенчмарки?VBart
08.09.2017 00:25Это не CGI запускалка. У нас собственный SAPI модуль для php по типу как php-fpm, так что потенциально всё должно работать, включая opcache и кэш соединений. Сейчас opcache уникален для каждого процесса, позже научим юнит разделяемому между процессами кэшу.
По поводу бенчмарков ответил выше.JPEG
09.09.2017 11:31Вроде, становится яснее: приложение общается с юнитом через память и сисколы для синхронизации. А как оно всё дальше большому энжинксу улетает, уже по сети? Если да, то правильно ли я понял, что nginx unit это php-fpm плюс systemd / inetd?
defanator
07.09.2017 12:54+2Поправьте, пожалуйста, конфигурацию пакетных репо. Вот правильные варианты:
CentOS 7:
[unit] name=unit repo baseurl=http://nginx.org/packages/mainline/centos/7/$basearch/ gpgcheck=0 enabled=1
Ubuntu 16.04:
deb http://nginx.org/packages/mainline/ubuntu/ xenial nginx deb-src http://nginx.org/packages/mainline/ubuntu/ xenial nginx
Спасибо!
firk
07.09.2017 12:56+5зоопарк версий на одной системе. Устали от многочисленных конфигураций и сборок fpm с разными версиями? Теперь это может быть запущено в пределах одного приложения.
Если вам нужно было три разные версии пхп, то их всё равно надо будет собирать три разные, только вместо fpm sapi какое-то другое. Если вам нужно было чтобы они были по-разному настроены — то опять же эти разные настройки никуда не денутся если заменить fpm на что-то другое. Ну а объединить старт/стоп нескольких демонов в один скрипт никогда никакой проблемы не представляло (если это нужно). Так что совсем непонятно, что именно тут записано в качестве преимущества.
anarx
07.09.2017 23:31+1Да, именно. Например, в CentOS мы используем репозиторий Remi, где есть возможность установить разные пакеты с префиксами php54, php56, php70, php71, например, в разные подкаталоги в /opt/remi. И, конечно, запустить их все сразу в виде fpm или как модули к разным апачам.
Никакой мороки, никакой усталости. Обновляется, работает почти само.
Здесь же пока выглядит просто страшновато, уж простите.
lexore
07.09.2017 13:05Очень интересно.
Сразу ловите feature request — возможность указать workers auto, по аналогии с nginx.
Я бы это даже по дефолту поставил.VBart
07.09.2017 18:29Что должен делать auto в данном случае? Сколько процессов запускать?
F0iL
07.09.2017 19:41По аналогии с nginx — по количеству ядер процессора.
И да, на гитхабе даже уже появился пул-реквест на эту тему.isysoev
07.09.2017 20:37+4Auto по умолчанию у нас для router worker threads.
Для приложений число процессов по числу ядер не лучший выбор, потому что приложения могут блокироваться в базе, memcache, и тому подобном. Для них нужно больше процессов. По умолчанию используется один процесс.F0iL
08.09.2017 10:31Ну это уже от языка/платформы зависит. При разработке под NodeJS, например, код пишется в неблокирующем асинхронном стиле, и частой практикой является запуск через какой-нибудь pm2 или node-cluster количества инстансов, совпадающем с количество ядер.
sowrong
07.09.2017 17:05+1не понятно как это поможет питону.
там проблемы обычно с окружением, и решаются они с помощью virtualenv. что может нам предложить unit в этом случае? разные версии питона — ок, а разные окружения на одной версии питона? или все зависимости складывать в одно место?
и, кстати, в случае uwsgi, кроме кучи остальных плюшек там присутствует ряд способов общения между воркерами средствами самого uwsgi без своих велосипедов. в unit это планируется?VBart
07.09.2017 18:34+1Да, планируется поддержка расширение возможностей, как для самих запускаемых языков, так и обвязки в целом. Важность virtualenv прекрасно понимаю, всё будет.
mobilz
07.09.2017 17:10+1Потестили с го, интересно ) для про не тянет, но для dev сервера вполне приживётся. Зоопарк надоел, а докер слишком тяжёлый
stanrud
08.09.2017 01:43Как-то Ruby невзначай в конце добавляют :( Типа возможно и не будет поддерживать? Будет реально очень жаль.
russianlagman
08.09.2017 23:35+1Проект для тех, кто не осилил docker? Поддержка гетерогенности контейнерами делается гораздо гибче и удобнее.
Borz
09.09.2017 09:48+1Из описания не увидел — а как-то планируется лимитировать CPU и память на приложение? или они всей толпой будут налегать на всё предоставленное?
Ipeacocks
> Мы запускали PHP в php-fpm и на апаче, запускали Python через uWSGI, иногда жили с Apache, а если нам нужны были разные версии PHP — жили с зоопарком из FPM-ов
И, по-моему, вполне не плохая такая жизнь была. Лично я не страдал.
Lsh
Я тоже не понял суть проблемы. Конфиги в разных файлах были или что?
Eklykti
Так они и щас будут в разных судя по всему. Тогда как Passenger умел единый конфиг с момента появления.