Релиз NGINX 1.6 и 1.7. Особенности версионирования

http://nginx.com/blog/nginx-1-6-1-7-released/
  • Перевод
Вчера, 24 апреля, был анонсирован релиз NGINX 1.6 и 1.7. Эта статья объясняет, как планируются релизы NGINX и значение этого изменения нумерации версий.

NGINX 1.6 отделился от текущей основной (mainline) ветки 1.5, а последняя была перенумерована в 1.7. Это ежегодное событие, когда берется текущая основная ветка с новой функциональностью и от нее ответвляется новая стабильная (stable) ветка. Разработка активно продолжается на уже перенумерованной основной ветке.

image

Версия 1.4 более не поддерживается. Основная ветвь 1.5 была форкнута для создания стабильной 1.6 и перенумерована в 1.7.

В терминологии NGINX «стабильная» означает, что новые возможности не будут добавляться. Иными словами, набор функций остается стабильным и только исправления серьезных багов попадают в эти версии.

Разработка новых фич и исправление всех багов происходит на основной ветке, но критические багфиксы при этом попадают в стабильную ветвь. Процесс выпуска релизов привязан ко времени, так что можно ожидать очередные релизы в основной ветке примерно раз в месяц, с исключениями, когда это необходимо. За последний год, в основной ветке появилась поддержка SPDY 3.1, аутентификация с помощью подзапросов, TLS session tickets, поддержка IPv6 в DNS-резолвере, поддержка протокола PROXY, а также была интегрирована поддержка SSL-соединений для протокола uwsgi. Помимо этого были расширены возможности по логированию ошибок, добавлена ревалидация кэша, поддержка SMTP pipelining, новые опции буферизации для FastCGI, улучшена поддержка стриминга mp4, а также обработка byte-range запросов для стриминга и кэширования.

Стоит обратить внимание, что «стабильная» не означает бо́льшую надежность и меньшее количество багов. На самом деле основная ветка рассматривается как более надежная, поскольку только критические исправления попадают в стабильную ветвь. Изменения в стабильной ветке не должны затронуть сторонние модули, чего нельзя сказать об основной ветке, где новая функциональность может сказаться на работоспособности стороннего кода.

Так какую же версию выбрать?


Рекомендуется использовать основную ветку NGINX всё время. Но можно использовать стабильную, если вас беспокоят возможные проблемы от нововведений, такие как несовместимость со сторонними модулями или баги в новой функциональности.

Если вы подключили официальный репозиторий NGINX (стабильную или основную ветку), то при следующем обновлении будет загружена последняя 1.6 или 1.7 сборка соответсвенно.

Если вы устанавливали NGINX из стороннего репозитория, то у вас (вероятно) нет контроля над тем, какая версия будет развернута, и репозиторий может не идти в ногу с выходом новых версий в одной из веток. По возможности, рекомендуется устанавливать NGINX из официального репозитория (на сайте nginx.org), где все сборки проходят внутренние тесты на регрессии и обновляются с выходом новых версий из официального источника.

Вы можете выполнить nginx -V, чтобы узнать номер версии вашей сборки:
user@host:~$ nginx -v
nginx version: nginx/1.5.12

А что там про NGINX Plus?


NGINX Plus – это поддерживаемая на коммерческой основе версия NGINX с расширенными возможностями (многие из которых используют новую архитектуру в разделяемой памяти, специфичную для Plus-версии). NGINX Plus следует версиям в основной ветке NGINX и обычно имеет трехмесячный цикл релиза. Новая функциональность в основной ветке добавляется в Plus, затем выпускается после прохождения процесса интеграционного тестирования и проверки в бою в условиях NGINX F/OSS версий:
image

NGINX Plus выпускается на основе mainline версий и обладает расширенной функциональностью

Внутренняя нумерация версий NGINX Plus соответсвует релизу в основной ветке, с которой NGINX Plus был синхронизирован.

Официальный блог на английском языке: nginx.com/blog


Внимание! Nginx Team проводит очередной опрос сообщества, чтобы лучше определить стратегию развития. Не упустите возможность высказать свое мнение: mailman.nginx.org/pipermail/nginx/2014-April/043282.html
Upd: Опрос завершен. Всем, кто принял участие, огромное спасибо.
Поделиться публикацией

Комментарии 40

    +7
    В тегах:
    всем обновляться

    Пятница же о_О
      +1
      Посмотрел я на плюсатую версию, и так и не понял, чем оно лучше, чем haproxy.
        +12
        Вспоминается старый анекдот:
        — Nginx Plus лучше чем haproxy.
        — Чем лучше то?
        — Чем haproxy.

        Совсем разные продукты же.
          +2
          Я не про nginx, а про его плюсовую часть. Что дает nginx+ по сравнению с комбинацией nginx и haproxy?
            +8
            Как минимум, вместо двух разных компонентов вы получаете один с отличной поддержкой. Плюс — это не только расширенные возможности балансировки, это ещё видео-стриминг, мониторинг, очень гибко настраиваемые асинхронные хэлсчеки и много других вкусностей, количество которых возрастает каждые 3 месяца.

            Но и одно из самых важных приемуществ — это конечно поддержка. Никто не скрывает, что можно взять бесплатную версию nginx, собрать его с кучей сторонних модулей и полученный комбайн возможно даже будет в какой-то спепени сопоставим по функциональности с коммерческой версией. Но если вы не хотите головной боли на вечер пятницы, проще взять плюс.
              +3
              Вы говорите как энтерпрайз-продавец. Уже? Так быстро слили nginx? Мдя.

              Вы так говорите «поддержка», как будто это кому-то когда-то помогло в критической ситуации.

              Итак, представим себе, маленький сайтик, ферма фронтэндов штук 30, выдают свои 15G в режиме proxy_pass и в ус не дуют. Вечер пятницы. Мониторинг присылает warning — latency начинает расти. К моменту, когда админ дошёл до рабочего места, critical, половина фронтэндов не отвечают.

              Сценарий
              а) Админ покряхтев идёт на сервера, сношается ночь с пятницы на субботу и обнаруживает, что это баг nginx'а, который возникает при определённой комбинации libssl и liblzma, причём при условии, что сертификат истекает менее чем через 2 месяца, а нагрузка на сервер превышает 30 запросов в секунду, и проявляется через 2 часа после начала работы.

              Альтернативно:
              б) Админ открывает тикет вида «у нас nginx'ы перестают работать самопроизвольно» и ночь с пятницы на вторник переписывается с саппортом, отвечая на идиотские, но очень важные вопросы.

              И?
                +3
                И проблема решается в течение времени, прописанном в SLA (зависит от конкретного контракта), но обычно гораздо быстрее. =)

                Встречный вопрос, а что если в случае «а» админ не может устранить проблему (опыта не хватает или проблема нетривиальна и требует хорошего знания, как внутренностей nginx, так и ядра операционной системы, а кроме того развернутый тестовый стенд для выявления и отработки различных ситуаций), а тут праздники на носу, пик продаж, нельзя терять клиентов?
                  +7
                  О, боже, мне сейчас рассказывают про решение проблем в течение SLA. Вы реально выпустите патч в течение 4 часов с момента заведения кейса? Можно я вам не поверю?
                    +3
                    Можете не верить конечно, это ваше право. Но хочу заметить, что мы ежедневно решаем различные проблемы наших клиентов, иной раз и не связанные напрямую с nginx, в то время, как для штатного админа — это зачастую нештатная ситуация.

                    Мы не занимаемся разовыми продажами, у нас подписка и мы очень заинтересованы чтобы её продлевали.
                      0
                      Это чудесно, но вы же дольше переписываться туда-сюда будете, чем эти четыре часа.
                        +4
                        Если предусмотрено контрактом, то вопросы могут решаться и по скайпу, в отдельных случаях можем и доступ на сервер попросить. Всё это решаемые вопросы.

                        Учитывайте ещё соотношение цены и качества, как уже было упомянуто в топике, это должно быть дорогой админ, плюс он должен не скучать.
                          +2
                          Ну, это уже убедительно :-)
                            +18
                            И всё же, позвольте небольшой disclaimer:
                            show
                            Тут со мной спорить начали, будто я что-то продать пытаюсь. Я даже и близко не продажник, я код разрабатываю, в чем не трудно убедиться посмотрев историю коммитов в nginx. Я не знаю деталей контрактов и прочего, я саппорт вижу только изнутри, как это работает. И готов его защищать, поскольку вижу, что он работает отлично, можно даже сказать, что это одна из тех вещей, которую было бы не стыдно порекомендовать лучшему другу.

                            Статья в первую очередь о версионировании. Перевел её для хабра, чтобы больше людей понимало, что у нас там с версиями происходит, плюс лишний раз призвать людей принять участие в опросе. Прошу не воспринимать как рекламу.
                            .
                  +12
                  нефиговый админ однако если с такой засадой сам за одну ночь разобрался. Думаю он стоит дороже чем nginx plus. ;)
                    +1
                    При этом такой админ в компании, а не за её пределами (я намекаю, что для бизнеса аутсорсинг компетенции — путь в никуда обычно).
                      +1
                      Именно так, всем плохо.
          +2
          … многие из которых используют новую архитектуру в разделяемой памяти, специфичную для Plus-версии
          — а вот это очень печально. Основная проблема внутренней архитектуры nginx, сильно ограничивающая возможности сторонних модулей и вынуждающая использовать страшные хаки для сихронизации между воркерами, получается, решена только в закрытой версии. Это уже не open core-модель, это какой-то half-open core.
            +2
            Основная проблема, ограничивающая возможности сторонних модулей в том, что для написания любых модулей к высокопроизводительному серверу надо быть очень и очень квалифицированным программистом, понимающим как писать код под асинхронный демон на С.

            Таких людей чрезвычайно мало и их стоимость во много раз больше, чем стоимость платных версий софта.
              +2
              Не надо быть очень квалифицированным программистом, чтобы понимать как писать код под асинхронный демон на C. Написать свой собственный примитивный http-сервер на C с использованием какой-нибудь libev вполне реально за день, а без libev под epoll и kqueue за пару-тройку дней. Другое дело, что знать архитектуру nginx, все подводные камни и понимать как наиболее эффективно решить ту или иную задачу в рамках этого сервера, для этого надо иметь немалый практический опыт.

              Но symbix говорил не об этом, а о том, что в plus-версии используется архитектура, недоступная в открытой версии, а именно, использование разделяемой памяти. И в некоторых задачах, когда надо «шарить» данные между воркерами, это действительно проблема. К примеру, вы хотите использовать гео-базу на 100Мб. Без раделяемой памяти каждый из воркеров будет отъедать эти 100Мб. А если данных больше? Или вам нужно синхронизировать какие-нибудь счётчики между воркерами и вместо того, чтобы использовать разделяемую память, вы используете redis.
                0
                Вообще, от nginx я ожидаю использования COW использования памяти. Разве не так работает? Плюс, какая-никакая, но общая память между ворукерами там есть, shared_mem. Тот же nginx_lua предоставляет доступ к нему.
                  –4
                  И чего?

                  Если вам нужна разделяемая память, то у вас в принципе нет и не может быть никаких проблем оплатить лицензию на nginx+

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

                  Так что всё вполне нормально: поиграть можно с опенсорсом, а когда понадобится что-то больше, то либо пилите сами, либо делайте по-человечески и берите лицензию.

                  Есть, правда, известная проблема: админы и программисты очень не любят эскалировать до начальства возможность сэкономить деньги покупкой лицензии на софт, в который уже вложены сотни и тысячи человеко-часов работы и отладки. Куда как интереснее ковыряться самому.
                    +1
                    Если я не ошибаюсь, исходники nginx plus не предоставляются. Насколько я понимаю, это одна из причин, по которой CloudFlare пилит свой форк — уж у них-то денег точно достаточно на сколько угодно лицензий.
                      –3
                      «Если я не ошибаюсь» — а вы пытались списываться?

                      Или как всегда — в интернетах прочитал.

                      Ну и ещё раз вопрос: сколько вы накоммитили в nginx что бы что-то заявлять?
                  0
                  Ну вы же понимаете, что итоговая стоимость зависит от количества инсталляций, наличия внутренней специфики и еще массы факторов.

                  Да и я не о том совсем. Я совершенно не против такой модели, и я рад, что Игорь и его коллеги наконец имеют возможность получить достойное вознаграждение за годы труда. Просто все надо называть своими словами. Это — не open core.
                  –1
                  вынуждающая использовать страшные хаки для сихронизации между воркерами
                  Улыбнуло…
                  Не то чтобы я такие страшные хаки не видел — видел и не мало. Но, большая часть этих «хаков» была от незнания, непонимания и т.д.
                  Например в одном внутренне-корпоративном модуле (умная такая negotiate keep-alive аутентификация с девочками и бильярдом с ролями и группами) видел такое, что волосы дыбом. А все потому, что авторы в глаза не видели ring buffer, да и сорцы других стандартных модулей или поленились пролистать или не поняли ни черта, отсюда и кривой велосипед со всеми вытекающими — в результате IIS бегал быстрее того nginx.

                  Т.ч. не надо про проблемы внутренней архитектуры nginx, все в порятке там с этим. Иногда нужно просто RTFM и учить мат-часть.
                    +1
                    Расскажите как сделать инкрементный счётчик, который могли бы использовать все воркеры, один для всех? Без костылей?
                      +1
                      Запросто, вариантов штук пять на вскидку, ну например:
                      для счетчика, с чем нибудь типа фильтра по сессии, IP, keepalive conn-ID от nginx и т.д., делаем через sendevent к background-thread, который уже считает и инкрементит (один на всех). Вы когда-нибудь асинхронный логгер писали? Тот же принцип, хотя бы ринг буфер например (N writer / 1 reader). А для чтения воркерами синхронизация не нужна — простой шаред-массив (если разрешен dirty read).

                      Хотя лучше бы уточнить ТЗ ;)
                      Слово костыль, кстати, применяется некоторыми людьми по разному. Вот если у энжин нет например стандарной возможности реализовать такой, вами задуманый, счетчик — то что вы сами напишете — это все костыль?
                      Вопрос: Когда, по вашему, костыль превращается в модуль или API, если вы используеете 50% от энжин (отстальное самописное)?
                      А может 99%?

                      Вот я могу вашу задачу реализовать так: беру multithreaded lua, нет лучше Tcl и пишу в конфиге nginx, что-то вида:
                      exec_tcl "thread::send -async [tsv::get background-worker bg1] [list incr_cntr CU1 users $remote_addr]";
                      

                      а в location FastCGI например, что-то вида:
                      set_by_tcl $c "tsv::get CU1 users";
                      fastcgi_param X_USER_CNTR $c;
                      

                      Это у меня костыль? Я про использование луа или тикля…

                      К сведенью, накидал ради интереса такое на коленке, привожу результаты замеров скорости (за 5 секунд стрес-теста). Это чтобы сразу закрыть тему скорости (а то постоянно спорят) — я тогда спрашиваю сможет ваш ПХП (питон, любимое подставить) отдать 1 354 224 запросов в секунду:
                      Запись: 0.738 ms/#, 6774784 #, 1354224.44 #/sec
                      Чтение: 0.482 ms/#, 10387456 #, 2076465.01 #/sec
                      

                      Повторю вопрос про костыль: что должен делать nginx, а что можно переложить на другие плечи и где он начинается ваш костыль?
                        0
                        Да, надо сразу ставить задачу полностью. Когда писал про счётчик, думал об учёте ограничений в своём рекламном движке, т.е. когда несколько процессов одновременно используют одни и те же данные: показ состоялся, счётчик инкрементировали (атомарно). При этом все процессы используют этот же счётчик для контроля. Если использовать в этом случае shared memory, речь будет идти не о миллионах, а о сотнях миллионов операций в секунду.
                          0
                          Мио или 100 мио, здесь вторично — это как воткнуть еще 100 процессоров, но оставить ту же майнбоард с медлючими мостами, памятью, и особливо старым жестким диском и 10мбит сетью. Сравнимо, имхо… Вопрос по теме вы проигнорировали?
                            0
                            Если «Мио или 100 мио, здесь вторично», тогда к чему «я тогда спрашиваю сможет ваш ПХП (питон, любимое подставить) отдать 1 354 224 запросов в секунду»? Зачем вам nginx, если для вас не важно 2 порядка по скорости?

                            Какой конкретно вопрос я проигнорировал?
                              0
                              Вторично — не есть не важно.
                              Важнее имо, чтобы энжин не «просел», т.е. работал дальше асинхронно и шустро. Или у вас задача стояла только ваш счетчик отдавать?

                              А вопрос имелся ввиду — про косяк.
                                +1
                                Если использовать ваш метод, об атомарности использования счётчика можно забыть. На каждый запрос к одному из воркеру придётся всем остальным воркерам рассылать эти «инкременты». Таких счётчиков в рамках одного запроса может быть несколько. В результате большую часть времени nginx будет заниматься обработкой запросов для поддержания счётчиков. Это и есть костыль, потому как с shared memory достаточно сделать __sync_fetch_and_add, просто, быстро, атомарно.

                                Далее, про «косяк». На всей странице есть только одно слово «косяк» и оно в комментарии, на который я отвечаю. После моего комментария таких слов будет 3.

                                Что вы мне пытаетесь доказать? Что nginx прекрасный продукт? Я ещё 7 лет назад, когда писал свой первый демон на C для обработки запросов рекламной сети, досконально изучил архитектуру и реализацию nginx и я преклоняюсь перед Сысоевым как программистом, потому как код прекрасен и перфекционист внутри меня ликовал, не часто увидишь такой качественный, вылизанный код.

                                Изначально шла речь о том, что для синхронизации между воркерами приходится использовать костыли, от которых можно было бы избавиться, если была разделяемая память. Вы усомнились, я предложил задачу, вы предложили костыль, щедро посыпая это рассуждениями о том, как некоторые используют nginx, странными алегориями про железо и под конец не можете внятно объяснить какой именно вопрос я проигнорировал. Я не вижу смысла в продолжении этого диалога.
                                  +1
                                  Да диалог вероятно безсмысленнен…
                                  Если использовать ваш метод, об атомарности использования счётчика можно забыть.
                                  Чо это вдруг?!
                                  Это и есть костыль, потому как с shared memory достаточно сделать __sync_fetch_and_add, просто, быстро, атомарно.
                                  А после перезагрузки считать его по новой? Вы ваш счетчик точно никуда больше не пишете? (db, gdbm, file etc.).

                                  Вы бы ветку еще раз проглядели… Разговор шел про «страшные хаки», вы же влезли в ветку с элементарнейшим примером (который сами же решили в одну атомарную функцию), который решается «без косяков» минимум 20-ю способами.
                                  Когда вам акуратно намекнули, что де это здесь не обсуждается и этот пример вообще не для nginx (просто у него другие функции) — вы полезли в бутылку…

                                  Изначально шла речь о том, что для синхронизации между воркерами приходится использовать костыли
                                  Еще раз спрошу: А почему это вообще должно быть задачей nginx? НЕ надо синхронизировать его воркеры. Точка. Это ассинхронный сервер, и оставте его таким. Положите рядом другой сервис (с привязкой к nginx хоть на shared mem, хоть на scgi), который все что вам нужно синхронно умеет делать. Все.

                                  Я ещё 7 лет назад, когда писал свой первый демон на C для обработки запросов рекламной сети, досконально изучил архитектуру и реализацию nginx и я преклоняюсь перед Сысоевым как программистом, потому как код прекрасен и перфекционист внутри меня ликовал, не часто увидишь такой качественный, вылизанный код.
                                  Это тут вообще для чего? Ну я свой первый демон лет 20-ть назад писал… Меряться будем?

                      +1
                      Проблема необходимой квалификации действительно существует, и своими силами реализовать синхронизацию между воркерами можно (не на уровне модуля — так на уровне патчей). Но я не об этом. Действительно, «страшные хаки» часто получаются от незнания, но для того, чтобы воспользоваться готовым API, почитав исходники стандартных модулей, знаний нужно меньше, чем для реализации с нуля с погружением в deep internals. Проблема во внутренней архитектуре не в том, что там что-то сделано неправильно. Нет. То, что сделано — сделано хорошо, но штатных способов совместного использования памяти или синхронизации между воркерами там просто-напросто нет. Собственно, это «аукается» и в стандартных модулях — нормальные, консистентные способы управления proxy_cache отсутствуют.

                      Изначально, при создании Nginx Inc., было заявлено о модели open-core. Я, может быть, неверно понимаю этот термин, но shared memory API я уверенно отношу к core. Теперь же создается впечатление, что не только дополнительные модули, но и все улучшения core api пойдут в коммерческую версию, и никакого nginx 2 не будет, что печально.
                        0
                        нет, вы неверно понимаете этот термин.

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

                        Вопрос как всегда очень простой: сколько сейчас ваших строк кода в nginx, что бы рассуждать о печально/не печально? Что вы вложили в проект, что бы что-то требовать взамен? Опенсорс — это не халява, это всего лишь открытые исходники.
                          +1
                          Насколько я в курсе, исходники nginx-plus не предоставляются. Свои модули в виде shared objects подключить тоже нельзя. Так что, даже если я куплю лицензию, это мне никак не поможет в разработке своих модулей, которым нужно shared memory api.
                            0
                            Т.е. ещё раз: вы ничего не коммитили в nginx, платить деньги не хотите, но у вас огромная куча претензий к nginx.

                            Это обычный паразитизм. Вам никто ничего не должен.
                              0
                              Это где же я заявлял, что мне кто-то чего-то должен?
                    –2
                    Если говорить про NGINX Plus, то можно вспомнить и китайский Tengine )
                    Тоже с дополнительными фичами на базе nginx, но бесплатный.
                      0
                      Хм, что не так с Tengine, что и здесь, и в карму минусы идут? %)
                      Сам не ставил его еще, но судя по описанию неплохая вещь… Разрабатывается и крутится на Taobao и еще некоторых крупных сайтах (если память не изменяет, даже на каком-то проекте mail.ru его видел)

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое