The OpenNET Project / Index page

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

Выпуск сервера приложений NGINX Unit 1.2

07.06.2018 23:10

Доступен выпуск сервера приложений NGINX Unit 1.2, в рамках которого развивается решение для обеспечения запуска web-приложений на различных языках программирования (Python, PHP, Perl, Ruby и Go). Под управлением NGINX Unit может одновременно выполняться несколько приложений на разных языках программирования, параметры запуска которых можно изменять динамически без необходимости правки файлов конфигурации и перезапуска. Проект пока находится на стадии бета-тестирования и не рекомендован для промышленного использования. Код написан на языке Си и распространяется под лицензией Apache 2.0. С особенностями NGINX Unit можно познакомиться в анонсе прошлого выпуска.

В новой версии:

  • Добавлена возможность настройки переменных окружения для процессов приложений, запускаемых под управлением Unit.
    
            "env-example": {
                "type": "python",
                "path": "/www/django",
                "module": "wsgi",
    
                "environment": {
                    "DB_ENGINE": "django.db.backends.postgresql_psycopg2",
                    "DB_NAME": "mydb",
                    "DB_HOST": "127.0.0.1"
                }
            }
    
  • Для языка PHP добавлена возможность указания пути к php.ini и изменения индивидуальных настроек PHP.
    
           "opts-example": {
                "type": "php",
                "root": "/www/site",
                "script": "phpinfo.php",
    
                "options": {
                    "file": "/path/to/php.ini",
                    "admin": {
                        "memory_limit": "256M",
                        "variables_order": "EGPCS",
                        "short_open_tag": "1"
                    },
                    "user": {
                        "display_errors": "0"
                    }
                }
            },
    
    
  • Появилась возможность настройки аргументов запуска приложений на языке Go.
    
            "args-example": {
                "type": "go",
                "executable": "/path/to/compiled/go/binary",
                "arguments": ["arg1", "arg2", "arg3"]
            },
    
    


  1. Главная ссылка к новости (http://mailman.nginx.org/piper...)
  2. OpenNews: Выпуск nginx 1.15.0
  3. OpenNews: Выпуск сервера приложений NGINX Unit 1.1
  4. OpenNews: Релиз nginx 1.14.0
  5. OpenNews: Первый стабильный релиз сервера приложений NGINX Unit
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/48734-nginx
Ключевые слова: nginx, unit
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (29) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (2), 00:20, 08/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Объясните почему бы просто не запускать каждое приложение в докере?
     
     
  • 2.3, Грусть (?), 00:35, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Докер - это ещё одно недоразумение. Почему бы просто не запускать приложения?
     
     
  • 3.9, Аноним (2), 03:23, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что разные версии того же пхп могут конфликтовать
     
     
  • 4.13, combiner (?), 07:10, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кто мешает запускать php приложения на deb-based distro, с разными php-fpm одновременно?
     
  • 4.14, ryoken (ok), 07:36, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Потому что разные версии того же пхп могут конфликтовать

    Кстати, давно про дыры в пыхе тут новостей не было. Перешли на дыры сразу в процах :D

     
  • 4.20, XXX (??), 09:40, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Кто мешает запускать php приложения на gentoo-based distro, с разными php-fpm одновременно? (c)
     
  • 4.22, нах (?), 10:51, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не могут - если у вас руки не из задницы. pear/pecl/структура управляющих файлов в php сделаны еще реальными бородатыми программистами, которые - умели.
    Вот что вы не умеете ничего кроме apt install (а "приложение" написано на php 5.0.2) - это я легко поверю.

     
  • 2.4, Аноним (-), 00:39, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А при чём тут вообще Докер?
     
     
  • 3.11, Аноним (2), 03:24, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я так понимаю главное тут - изоляция, потому что остальное nginx итак вроде умеет.
    Ну и Docker/LXC/LXD отлично с изоляцией справляются.
     
     
  • 4.17, qrKot (?), 09:03, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Хреново докер с изоляцией справляется, если честно...
    Докер - он про деплой/доставку, изоляция не про докер.
     
     
  • 5.28, Аноним (-), 21:05, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    докер не виновен! это, ядро криво изолирует
     
  • 2.6, KonstantinB (ok), 01:07, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Например, не для каждого проекта оправдано дублировать каждое запущенное приложение несколькими инстансами с балансировкой.

    Если же запущен всего один инстанс приложения, с докером без даунтайма при обновлении не обойтись.

    Ну и не каждое приложение можно написать (переписать) в соответствии с методологией 12 factor. А без этого докер больше мешает, чем помогает, проще обойтись тем же LXC.

     
     
  • 3.10, freehck (ok), 03:24, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если же запущен всего один инстанс приложения, с докером без даунтайма при обновлении не обойтись.

    Это неправда. Обновление происходит так: мы поднимаем контейнер из нового образа, дожидаемся, пока он полностью прогрузится, и тогда уже гасим старый.

    По поводу остального согласен.

     
     
  • 4.12, KonstantinB (ok), 04:54, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Обновление происходит так: мы поднимаем контейнер из нового образа, дожидаемся, пока он полностью прогрузится, и тогда уже гасим старый.

    Не, ну так, конечно, можно, в стиле "fastcgi php до появления php-fpm".

    Но тут есть две проблемы.

    1) дроп соединений, ожидающих ответа от первого контейнера в момент переключения. Тут можно выкрутиться конструкцией вида "добавляем в конфиг балансировщика второй контейнер, метим первый как down, дожидаемся, пока первый закончит обработку всех соединений, прибиваем первый", но как-то сложновато получается.

    2) если приложение - древний монолит, могут возникнуть проблемы с конкурентным доступом к ресурсам из обоих контейнеров. Это, конечно, из разряда "не программируйте так", но если бы все хорошо программировали...

     
     
  • 5.21, Анонимус2 (?), 10:31, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >если приложение - древний монолит

    То unit ему тем более никак не поможет

     
     
  • 6.30, KonstantinB (ok), 02:37, 09/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Самому по себе - да.

    На практике же типичная подобная ситуация: есть, скажем, древний PHP-шный монолит из дерьма и палок, как-то работающий, но для развития непригодный, потому параллельно начинается разработка новых сервисов и постепенный перенос старой функциональности из монолита в код новых сервисов, которые, допустим, разрабатываются на python и go. Вот тут Unit оказывается очень удобен.

     
  • 5.33, freehck (ok), 09:17, 18/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> Обновление происходит так: мы поднимаем контейнер из нового образа, дожидаемся, пока он полностью прогрузится, и тогда уже гасим старый.
    > Не, ну так, конечно, можно, в стиле "fastcgi php до появления php-fpm".

    Да нет, тут тот же самый php-fpm, только он раскидан по нескольким контейнерам/машинам/нодам. В каждом контейнере, по идее, висит воркер, который дожидается соединений. И да, тот же php-fpm туда впихнуть -- да пожалуйста, было бы желание.

    > 1) дроп соединений, ожидающих ответа от первого контейнера в момент переключения. Тут
    > можно выкрутиться конструкцией вида "добавляем в конфиг балансировщика второй контейнер,
    > метим первый как down, дожидаемся, пока первый закончит обработку всех соединений,
    > прибиваем первый", но как-то сложновато получается.

    Нет, ну почему же. Дроп соединений делать не нужно. Процедуру вырубания контейнера надо описать корректно, чтобы он дожидался завершения текущих соединений и не принимал новых. По части "не принимал новых" -- тут конечно же надо балансировщик. Но исправление конфига -- опять же, чересчур. Не надо описывать воркеры в конфиге. Надо, чтобы балансировщик узнавал о воркерах через service discovery. Zookeeper/etcd в помощь.

    > 2) если приложение - древний монолит, могут возникнуть проблемы с конкурентным доступом
    > к ресурсам из обоих контейнеров. Это, конечно, из разряда "не программируйте
    > так", но если бы все хорошо программировали...

    Да, обычно приходится много чего переписать, чтобы обеспечить бесперебойную работу. Ну, что поделать. Есть игрушки "на коленке", когда нужно сделать быстро. А есть игрушки "на экспорт", когда нужно сделать надёжно.

     
  • 3.18, qrKot (?), 09:06, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Например, не для каждого проекта оправдано дублировать каждое запущенное приложение несколькими
    > инстансами с балансировкой.

    2 инстанса - оправдано для каждого, хотя бы в целях фейловера... Балансировка - уже не везде, согласен.

    > Если же запущен всего один инстанс приложения, с докером без даунтайма при
    > обновлении не обойтись.

    Вот это неправда ваша. Да и не докером единым, k8s есть еще тот же.

    > Ну и не каждое приложение можно написать (переписать) в соответствии с методологией
    > 12 factor.

    Каждое серверное - можно.

    > А без этого докер больше мешает, чем помогает, проще обойтись тем же LXC.

    А вот LXC - вообще НЕ средство доставки приложения.

     
  • 2.15, Аноним (-), 07:52, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    запускайте и теряйте данные наздоровье
     
  • 2.19, Аноним (-), 09:08, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Наверно потому что докер - хипстерское баловство? По-моему уже все наигрались с ним.
     
     
  • 3.23, нах (?), 10:53, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Наверно потому что докер - хипстерское баловство? По-моему уже все наигрались с
    > ним.

    куда ты [from] с подводной-то лодки денешься? (с ужасом глядя в docker ps на системе, установленной подрядчиками)

     
  • 3.25, Аноним (25), 16:09, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Деплой в течение минуты, ограничения ресурсов, изоляция хоть и не уровня полноценной виртуализации, зато и потребление ресурсов гораздо ниже. Что вы предлагаете в качестве альтернативны когда дело касается динамического старта/остановки большого количества инстансов?
     
     
  • 4.29, Аноним (-), 22:03, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Большое количество инстансов требуется очень редко. Там, где это требуется - пишутся свои in-house решения заточенные исключительно под собственные потребности компаний. И лишь в крайне узкой нише между этими двумя - и есть истинное призвание докера. Однако хипстота его использует вообще везде, даже на хоумпейджах. Один очень настойчиво пытался к нам на небольшой проект затащить потому что это, типа, в тренде. Тимлид посадил его разбирать легаси проект в качестве выправительной для мозгов меры.
     

  • 1.5, анон (?), 01:01, 08/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    не понял, он аналог uwsgi и gunicorn?
     
     
  • 2.7, KonstantinB (ok), 01:14, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > не понял, он аналог uwsgi и gunicorn?

    В каком-то смысле - да, только сразу для кучи разных языков, со своими райтаймами/библиотеками/SAPI (в зависимости от) для каждого из них.

    Технически работает через shared memory, что дает прирост производительности: не надо парсить никакие протоколы, просто меняемся указателями на структуры в памяти.

     
  • 2.8, Аноним (-), 01:44, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это совсем не аналог uwsgi и gunicorn.
     
  • 2.24, нах (?), 10:58, 08/06/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > не понял, он аналог uwsgi и gunicorn?

    скорее, попытка показать их авторам "как правильно". Вероятно, мертворожденная.

     
  • 2.32, denis0 (?), 09:00, 09/06/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    https://www.youtube.com/watch?v=GK6xAOVRTcg - видео со Стачки в Ульяновске в этом году. Релиз 1.0 случился где-то через неделю после этого видео.

    Идеи в Unit очень мощные.

    offtop: задним числом понял, зачем некоторые до сих пор пользуют Apache в качестве appserver - единообразное конфигурирование для разных ЯП.

     

  • 1.16, Ю.Т. (?), 07:55, 08/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Доступен (http://mailman.nginx.org/pipermail/unit/2018-June/000055.html) выпуск
    > сервера приложений NGINX Unit 1.2 (http://unit.nginx.org/), в рамках которого развивается

    На английской странице about "designed to run applications in multiple languages" на самом деле значит, что Unit это сам делает на разных/многих языках. Нужно хотя бы "applications written in multiple languages".

     
  • 1.26, Аноним (-), 18:59, 08/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А что это такое? Если что я не "специалист".
    Это система изоляции? Тогда как она может якобы поддерживать языки?
    При компиляции они хотят -dev файлы от языков, хмм.. это аналог операционной системы?
    Что-то типа Wine в очень широком смысле?
    Операционая система без излишеств и есть "сервер приложений". А это что?
     
  • 1.27, Аноним (-), 20:03, 08/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    аналог скорее uwsgi (так как uwsgi тоже поддерживает большое количество языков)
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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