Comments 119
И, по-моему, вполне не плохая такая жизнь была. Лично я не страдал.
Документация ни к черту. Я например не могу найти где про «в рамках одного app-сервера можно держать разные версии PHP»
из того что мы видим в целом (не привязываясь только к веб-аппликейшнам) «продукт» становится очень разрозненным, причем это происходит по всем направлениям.
больше нет одного мониторинга для всего (смотрим за инфраструктрой в прометеусе, за приложением в ньюрелике, шлем логи в ELK итп), больше нет «одного приложения», есть несколько проектов с нодой и руби на фронте, с питоном в бэкэнде, делают это разные команды с разными компетенциями и так далее.
как раньше собирали софт и кубиков/библиотек, так теперь кубики это «компентенции» групп разработчиков — ктото специализируется на фронте и они же пишут часть бэкэнда на ноде, _очень_ часто при этом может быть вообще какой-то старый кусок на PHP, ну и так далее.
также с базами, при всей противоречивости монги, очень часто видим монгу на фронте, постгрес и кликхаус на аналитике.
да, это сложнее и я до конца это не одобряю, но такой мир (имхо, могу быть и не прав ;) )
Каждому сервису свой конфиг и своя платформа… зоопарки обычно живут на стейджах, и дев серверах, когда тот жже кликхаус живет рядом с постгресом нодой и фпм… в большом энтерпрайзе много автоматики, много серверов и сервера распределяются по ролям…
Насколько я понимаю, фишка не в том, чтобы держать на одном сервере и руби, и питон, и пхп — для этого есть контейнеры, виртуалки и так далее. А в том, что одна и та же софтина используется как app server для всего зоопарка языков/сервисов. Чем меньше разного софта — тем легче всё это сопровождать, обновлять и чинить когда сломается.
У более-менее крупных проектов все переписывается на микросервисы, а микросервисы могут быть на разных языках.
Пока что тут: 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(). Юнит указанный порт игнорирует, слушающий сокет уже конфигурируется в самом юните.
Как минимум, своеобразный import path: все известные мне тулзы, включая саму утилиту go, будут считать, что это пакет стандартной библиотеки. Если вы сделаете путь вроде github.com/nginx/go-unit, и положите пакет туда, вы избавите людей от большой головной боли.
Почти все разработчики на языках, отличных от C и С++, не ставят библиотеки для этих языков yum'ом и apt'ом, а используют средства экосистемы языка: gem, pip, crate, etc. Пакетный менеджер системы придумали совсем не для них, и пользоваться им, чтобы ставить, например, gem'ы, дико неудобно.
В Go для этого используются go get и различные менеджеры зависимостей, которые постепенно вытесняются официальным экспериментом: https://github.com/golang/dep. Если у вас будут SemVer-теги для релизов, то будет ещё приятнее.
Отвечая на вопрос – да, пользоваться инструментом, привычным разработчику на языке, удобнее, чем инструментом, грубо говоря, системного администратора. Тут между вами, разработчиками unit'а, и разработчиками на Go пропасть, которую надо преодолеть.
К слову, разработчики на Go редко ставят Go из репозитория системы. Во-первых, он почти всегда там старый. Во-вторых, я ещё должен найти packager'а, которой понял концепцию GOPATH и GOROOT, и не применил какие-то патчи, которые, как ему кажется, делают что-то лучше и Fedora/Debian/Ubuntu-way, но всё ломают для разработчиков. Последний раз смотрел года два назад – было дно.
Особенно учитывая вот эти тесты: https://gist.github.com/hgfischer/7965620 это может быть довольно насущно.
Вы уже сравнивали производительность?
Пхп, питон… А ruby, ruby-то где?
Будет.
Вот тут примерный план на ближайшее время:
http://unit.nginx.org/docs-nginx-unit.html#supported-application-languages
а почему все вешается на tcp сокеты? Как быть тем, кто очень хочет экономить и использовать unix сокеты?
А где этот unit возьмет какие нибудь специфические модули для того же php?
Или весь pecl будет поддерживаться?
Там же, где и php-fpm или mod_php. Мы собираем свой собственный SAPI модуль для php-интерпретатора и линкуемся с libphp.
А unit собираете вы. Откуда вам знать что именно мне нужно?
Никто не мешает вам собирать libphp под ваши собственные задачи, мы лишь подключаемся к стандартному SAPI, который един и не зависит от сборки.
Еще вопрос. Посмотрел пакет собранный под убунту. Там у php.unit.so зависимость libphp7.so.
А как происходит работа с php5?
Нужно собрать php5.unit.so с зависимостью от libphp5.so. Пакеты в наших репозиториях идут только с тем, что доступно в системных репозиториях.
Я, например, вот так у себя в 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```Вроде кое-что есть: http://unit.nginx.org/docs-installation.html#configuring-php-modules
Под gentoo ручками что-то собирать?! o_O
Я удивлён.
Эххх, кто бы меня пнул в субботу/воскресенье — надо обязательно ебилд нарисовать, ибо хочется, однако! Благо есть куда запихать вместо всяких php-fpm-ов и прочих разных обёрток...
Нет, не задавались. Наоборот, радовались, что Nginx такой клёвый и лёгкий и не берёт на себя все задачи в мире, в отличие от Apache.
А с появлением докера запуск разных версий пхп и смешивание технологий в одном проекте чрезвычайно упростились. Зачем это всё сейчас в Nginx — непонятно.
Nginx такой клёвый и лёгкий
Unit ещё более клёвый и лёгкий. ;)
Так оно и не в Nginx — по сути они сделали свой *-FPM и с Nginx у них общего только компания-разработчик. Даже конфиг в виде, не самого удобного для этого дела, JSON.
Я понимаю еслиб они это реализовали в виде динамических модулей к Nginx — подгрузил в конфиге и все работает, правда стабильность самого веб-сервера будет уже под вопросом… :)
Это все, конечно, замечательно, но у нас уже есть, например, docker.
Не совсем понимаю, зачем такая фигня, учитывая, что, скорее всего, настройка дополнительных типов будет сложной.
Хм… в чем именно дорого, не подскажите? Если использовать его без изоляции по сети и использовать только хостовые volume, то оверхед должен быть минимальный, если верить исследователям percona.
Если вы не про производительность, то тем более странно. Вряд ли удобнее будет через nginx хостить кучу разных версий python проектов, чем просто docker контейнеры.
- Виртуализация VMWare как бы платная
- Виртуалки — это лишний оверхед. К тому же, очень большое количество используемых серверов уже виртуалки. Виртуалки в виртуалках — очень странно.
- Не понимаю, чем это будет отличатся от установки docker демона и накатывания готовой конфигурации? Проблема будет лишь в том, что, если вам нужно будет добавить какие-то дополнительные либы к python, то вы будете это делать собирая свой модуль к application серверу, если я правильно понял. Сейчас такой возможности нет.
Ну и + как вот тут отметили, реальная пользая такой штуки — систематизация. Как бы, через docker можно сделать так же, только вот плюшек больше. Включая запуск разных OS, окружений и прочего для проекта. Например, как при помощи nginx application можно будет запустить проекты, которые требует разные версии одной библиотеки?
Например, как при помощи nginx application можно будет запустить проекты, которые требует разные версии одной библиотеки?В статье выше люди запускают две разных версии PHP, каждая использует свою собственную libphp.so (которые в свою очередь могли быть собраны со своими зависимостями). Я запускал одновременно приложения на 3-х разных версиях PHP, 2-х версиях Python и Go. Вообще это ни чем не ограничено.
Магия и секретные технологии. =)
Возможно я плохо читаю.
Подскажите, пожалуйста, как тогда указать разные версии интерпретаторов для python? Мне же их все равно нужно будет собирать и подсовывать application, или я не прав?
Так же, libphp.so это отлично, а подменить, скажем, системную библиотеку, как я понимаю, не получится. Хотя это уж совсем редкий случай.
Во многих дистрибутивах сейчас как минимум две версии cpython, ветки 2 и ветки 3. Соответственно и пакеты для них мы будем собирать сами, либо это будут делать майнтейнеры дистрибутива.
А если вам нужен какой-то особенный cpython, которого нет в репозиториях, то вы же его собираете так или иначе. Просто соберите динамический модуль для юнита с ним и юнит сможет его загружать и использовать для запуска ваших приложений на пайтоне.
Простите, что вас отвлекаю, но вы немного не поняли мой вопрос. Как мне, например, использовать virtualenv в связке с nginx unit? Я просто просмотрел доку и не нашел ответа :(
- Есть почти бесплатный RHEV, есть бесплатный KVM и OpenNebula
- Какой оверхед? Где? Виртуалки в виртуалках? Я о таком не говорил.
- docker это отдельный контейнер со своими проблемами. Виртуалка более надежна. И как раз docker более похож на виртуалку в виртуалке, если виртуализация уже есть.
- Вот я не из большой компании, у меня почти все сервера vps. Какую технологию мне тут применить?
- Если вам не нравится docker, то почему бы не попробовать systemd-nspawn? Контейнеризация не виртуализация со своими проблемами, ну так их и в случае виртуалочек полно. Вот VMWare все еще не поддерживает нормально ядро Linux 4+ (по заверениям хостинга, с которым сотрудничают наши заказчики), как быть?
А ASP.NET Core?
И основное назначение сия творения — различные сервера приложений (именно где много проектов) на хостингах/девелопер серверах. Проблему наличия зоопарка интерпретаторов оно не решает, но пытается систематизировать и сделать конфигурабельным. так?
Пример с битриксом. Статику отдает nginx, редиректы в nginx. unit заменил только fpm.
Есть какие-то плюсы на серваках под 1 проект с 1 языком? Тот же битрикс, чтоб его.
uWSGI, просто к слову, умеет и ...
И я об этом же подумал. uWSGI прекрасно справляется с зоопарком разных языков, virtualenv-ов, настроек и прочего. К тому же имеет кучу очень полезных фич, типа кеширование, роуты, emperor, webdav, cheaper_busyness, статистика, слежение за памятью воркеров, логирование куда угодно и в каком угодно виде и т.д. Надеюсь что в unit реализуют хоть часть всех этих вкусностей.
В любом случае, удачи проекту. Будем следить за его развитием.
По поводу бенчмарков ответил выше.
Поправьте, пожалуйста, конфигурацию пакетных репо. Вот правильные варианты:
CentOS 7:
[unit]
name=unit repo
baseurl=http://nginx.org/packages/mainline/centos/7/$basearch/
gpgcheck=0
enabled=1Ubuntu 16.04:
deb http://nginx.org/packages/mainline/ubuntu/ xenial nginx
deb-src http://nginx.org/packages/mainline/ubuntu/ xenial nginxСпасибо!
зоопарк версий на одной системе. Устали от многочисленных конфигураций и сборок fpm с разными версиями? Теперь это может быть запущено в пределах одного приложения.
Если вам нужно было три разные версии пхп, то их всё равно надо будет собирать три разные, только вместо fpm sapi какое-то другое. Если вам нужно было чтобы они были по-разному настроены — то опять же эти разные настройки никуда не денутся если заменить fpm на что-то другое. Ну а объединить старт/стоп нескольких демонов в один скрипт никогда никакой проблемы не представляло (если это нужно). Так что совсем непонятно, что именно тут записано в качестве преимущества.
Никакой мороки, никакой усталости. Обновляется, работает почти само.
Здесь же пока выглядит просто страшновато, уж простите.
Очень интересно.
Сразу ловите feature request — возможность указать workers auto, по аналогии с nginx.
Я бы это даже по дефолту поставил.
Для приложений число процессов по числу ядер не лучший выбор, потому что приложения могут блокироваться в базе, memcache, и тому подобном. Для них нужно больше процессов. По умолчанию используется один процесс.
Ну это уже от языка/платформы зависит.Именно. Значения по умолчанию должны быть или удобны для 99% случаев использования, или же неудобными, но безопасными. Если на машине 32 процессора, зачем запускать 32 приложения по умолчанию? Кроме того, некоторые приложения, например, на Go, могут конфликтовать, если запущенно более одной копии. Поэтому для числа рабочих процессов выбран безопасный вариант.
приложения могут блокироваться в базе, memcache, и тому подобном
Могут, а могут и не втыкать. Это уже другая часть работы по оптимизации.
Мне кажется, если база не справляется, снижать нагрузку на неё за счет обрезания ядер — плохая идея.
Если к приложению идет много запросов, нужно повышать мощности, а не сдерживать.
А так получится, что приложение (кроме блокировок в базе), тормозится ещё и на самом сервере.
Я очень часто наблюдал, как на 24-32-56 ядерном сервере на 100% загружены только часть ядер изза настроек воркеров uwsgi.
Для них нужно больше процессов. По умолчанию используется один процесс.
Вот в этом и дело :)
Боюсь, многие ваши пользователи будут начинать с настроек по умолчанию.
И в первую очередь будет диалог с техподдержкой:
- приложение работает медленно.
- повысьте workers.
Если по умолчанию использовать все ядра, много людей будет счастливее.
там проблемы обычно с окружением, и решаются они с помощью virtualenv. что может нам предложить unit в этом случае? разные версии питона — ок, а разные окружения на одной версии питона? или все зависимости складывать в одно место?
и, кстати, в случае uwsgi, кроме кучи остальных плюшек там присутствует ряд способов общения между воркерами средствами самого uwsgi без своих велосипедов. в unit это планируется?
Из описания не увидел — а как-то планируется лимитировать CPU и память на приложение? или они всей толпой будут налегать на всё предоставленное?
Понятно что будет работать связка nginx + unit. Но это лишний зоопарк программ
Ожидание длиной в 15 лет. Nginx Application Server