Когда весело - время летит. Да так, что сложно поверить: NGINX’у уже 18. Если оглянуться - сообщество и компания достигли вместе многого. Недавно мы прошли важную веху - на момент написания этой статьи 55.6% всех вебсайтов работают на NGINX (либо на нашем ПО, либо на продуктах, построенных поверх NGINX). Мы также веб-сервер №1 по доле рынка, и очень горды этим, и благодарны вам, сообществу NGINX, за этот потрясающий вотум доверия.
Мы также всё больше и больше понимаем, что ПО с открытыми исходниками продолжает менять мир. Всё больший и больший процент приложений создаётся с использованием открытого ПО. От терминалов и новостей Bloomberg до Washington Post, Slack, Airbnb, Instagram и Spotify - тысячи наиболее известных мировых брендов и компаний в работе своих веб-сайтов полагаются на NGINX Open Source. В моей собственной жизни - между Zoom для рабочих созвонов и Netflix вечерами - я, вероятно, провожу 80% своего дня, используя приложения, созданные поверх NGINX.
NGINX является только одной частью успеха открытых исходников. Мы не смогли бы построить цифровой мир — и, дополнительно, контролировать и управлять миром физическим — без всех удивительных проектов с открытыми исходниками, от Kubernetes и контейнеров до Python и PyTorch, от WordPress до Postgres и Node.js. Открытые исходники изменили способ нашей работы. На Github больше 73 миллионов разработчиков, которые сообща влили более 170 миллионов запросов на слияние. Огромный процент этих PR относится к репозиториям с открытыми лицензиями.
Мы взволнованы тем, что NGINX сыграл такую фундаментальную роль в становлении и успехе открытых исходников, и собираемся как продолжить поддержку, так и отблагодарить. В то же время нам нужно поразмышлять над своей работой с открытыми исходниками и адаптироваться к продолжающемуся развитию движения. Бизнес‑модели компаний, зарабатывающих на открытых исходниках, стали временами противоречивыми. Именно поэтому мы в NGINX всегда старались быть предельно понятными насчёт того, что является открытыми исходниками, а что доступно платно. Помимо прочего, это означает вообще никогда не пытаться выставлять счета за функциональность или возможности, которые мы включили в общедоступные, с открытыми исходниками, версии нашего ПО.
Открытое ПО быстро развивается. NGINX - тоже
Сейчас мы осознаём, что нам требуется крепко подумать над нашими обязательствами относительно открытого ПО, предоставляя больше ценности и возможностей в наших открытых продуктах, и да, также и улучшить нашу игру на коммерческой стороне. Мы просто не можем продолжать выставлять счета за то же, что и раньше, потому что мир изменился — некоторые функции, включенные только в наши коммерческие продукты, сейчас уже являются обязательным минимумом для разработчиков открытого ПО. Мы также знаем, что безопасность открытых исходников в центре внимания разработчиков. Из‑за этого наши проекты с открытыми исходниками должны быть так же безопасны, как и наши коммерческие продукты.
Мы также должны принять реальность. Внутри у нас была привычка говорить, что открытые исходники <здесь автор не уточняет, но по смыслу фразы речь об общедоступной версии Nginx — прим. перев.> не были на самом деле готовы к продакшну, потому что им не хватало функций или масштабируемости. Мир доказал, что мы уже какое‑то время ошибаемся в этом утверждении: многие тысячи организаций используют версию NGINX с открытыми исходниками в продакшн‑окружениях. И это хорошо, потому что показывает, насколько сильно они верят в наши версии с открытыми исходниками. Мы можем полагаться на это.
На самом деле мы постоянно делаем это <полагаемся — прим. перев.> в наших основных продуктах. Тем, кто считает, что Nginx уже перерос себя, скажу, что вы наблюдали за нами невнимательно:
В NGINX Open Source мы продолжаем добавлять новые функции, и поддерживаем ещё больше ОС. Две функции, критичные для безопасности веб‑приложений и трафика, HTTP3 и QUIC, выйдут в следующей версии.
Тихий, но невероятно новаторский уголок вселенной NGINX — NGINX JavaScript (njs), который позволяет разработчикам интегрировать код JavaScript в модель обработки событий модулей NGINX HTTP and TCP/UDP (Stream), и расширять синтаксис конфигурации NGINX реализацией сложных вещей. Наши пользователи сделали удивительные штуки — от инновационной очистки кэша и манипуляций с заголовками до поддержки более расширенных протоколов типа MQTTv5.
Наш универсальный сервер веб‑приложений, NGINX Unit, был задуман оригинальным автором NGINX Open Source, Игорем Сысоевым, и продолжает развиваться. Unit занимает важное место в нашем видении современных приложений и современного стека, который выходит далеко за пределы нашей консцентрации на data plane и безопасности. По мере того, как мы разрабатываем Unit, мы переобдумываем, как нужно проектировать архитектуру приложений для развивающегося веба — с дополнительными бесшовными интеграциями для облаков, разработанными для распределенных и высокодинамичных приложений.
Эталонная архитектура современных приложений
Мы хотим продолжать экспериментировать и продвигать способы помощи нашим основным клиентам — разработчикам более эффективно и легко разворачивать современные приложения. В позапрошлом году <в оригинале от 2022г. — «в прошлом» — прим.перев.> на Sprint 2.0 мы объявили эталонную архитектуру современных приложений NGINX (MARA), и я счастлив сказать, что недавно она вышла в. общий доступ под версий 1.0.0. MARA — это тщательно подобранный набор инструментов, включая Kubernetes, которые мы объединили, чтобы упростить развертывание инфраструктуры и архитектуры приложений в виде кода. Несколькими кликами вы можете настроить и развернуть эталонную архитектуру MARA, которая интегрирована со всем, что потребуется для создания готового к продакшну и облакам окружения — безопасность, логирование, сеть, сервер приложений, настройка, YaML‑управление и так далее.
MARA является модульной архитектурой, и это — намеренно. Вы можете выбрать свой собственный путь и разработать из существующих модулей персональную эталонную архитектуру, которая действительно может запускать приложения. Сообщество поддержало нашу идею, и мы начали сотрудничать над MARA c несколькими инновационными технологическими компаниями. Sumo Logic добавили свои обработчики логов к MARA, а Pulumi добавили модули для автоматизации и оркестрации рабочих процессов. Мы надеемся, что с MARA любой разработчик может получить полное окружение Kubernetes в работающем состоянии за минуты, полностью со всем поддерживающими частями, безопасное и готовое для развертывания приложения. Это только один пример того, как, я думаю, мы можем направить нашу общую энергию на продвижение большой инициативы в индустрии.
Будущее NGINX: модернизируй, оптимизируй, расширяй
Ежегодно на NGINX Sprint, нашей виртуальной конференции пользователей, мы даём новые обещания на грядущий год. В этом году ничего не меняется. Наши обещания на ближайшие 12 месяцев можно выразить в трёх словах: модернизируй, оптимизируй, и расширяй. Мы намереваемся убедить в том, что это не просто пустые слова от бизнеса; у нас есть значительные программы для каждого и мы хотим, чтобы вы проверяли выполнение наших обещаний.
Обещание № 1: Модернизировать наш подход, присутствие, и управление сообществом
Очевидно, мы быстро модернизируем наш код и знакомим с новыми продуктами и проектами. Но модернизация касается не только кода — она охватывает управление кодом, прозрачность в принятии решений и то, как мы позиционируем себя в сообществе. В то время как — исторически — кодовая база NGINX Open Source работала на системе контроля версий Mercurial, мы понимаем, что мир открытых исходников сейчас живёт на GitHub. Далее все проекты NGINX будут зарождаться и размещаться на GitHub, потому что именно там работают сообщества открытых исходников и разработчиков.
Мы также собираемся осовременить то, как мы направляем и управляем проектами NGINX. Мы обещаем быть более открытыми к contributions, более прозрачными в нашем служении, и более доступными для сообщества. Мы будем следовать всем ожидаемым соглашениям современной работы с открытыми исходниками и перестроим наше присутствие на GitHub, добавим Кодексы Поведения ко всем нашим продуктам и обратим пристальное внимание на обратную связь от сообщества. Как часть этого обещания модернизации, мы добавляем канал Slack NGINX Community. Мы приведём в канал наших собственных экспертов для ответов на ваши вопросы. И вы — сообщество — также будете помогать друг другу в инструменте для обмена сообщениями, который вы уже используете для ежедневной работы.
Обещание #2: оптимизировать наш опыт разработчика
Разработчики являются нашими основными пользователями. Они собирают и создают приложения, которые сделали нас теми, кто мы есть. Нашим принципом всегда была простота использования NGINX. И это в основном правда — NGINX не требует для установки, запуска и настройки целых дней. Тем не менее, мы можем сделать лучше. Мы можем ускорить «время до ценности», которое разработчики тратят на наши продукты, сделав «кривую изучения» короче, а процесс настройки — легче. Под «ценностью» я имею в виду развёртывание кода, который делает что‑то действительно ценное, в продакшне, точка. Мы собираемся исправить наш опыт разработчика, упростив установку, улучшив документацию и добавив охвата и весомости нашим форумам сообщества.
Мы также собираемся выпустить новое предложение SaaS, которое будет нативно интегрироваться с NGINX Open Source, и поможет вам сделать его полезным и ценным за секунды. Не будет регистрации, ворот, платного доступа. Это SaaS будет бесплатным в использовании — всегда.
В дополнение, мы осознаём, что многие критичные функции, которые разработчики рассматривают как обязательный минимум, находятся на неправильной стороне платного доступа — не в NGINX Open Source, а в NGINX Plus. Например, поиск сервисов через DNS является базовым для современных приложений. Наше обещание — сделать эти критичные функции бесплатными, добавив их в NGINX Open Source. Мы ещё не приняли решение по всем функциям, которые переедут, и хотим исходные данные от вас. Расскажите нам, как оптимизировать ваш опыт разработчика. Мы слушаем.
Обещание № 3: Расширить мощь и возможности NGINX
Как бы ни был популярен NGINX сегодня, мы знаем, что нам нужно продолжать совершенствоваться, если мы хотим оставаться хотя бы такими же актуальными через десять лет. Наша амбициозная цель заключается в следующем: мы хотим создать полный стек приложений NGINX и поддержку возможностей для управления и эксплуатации современных приложений в масштабе.
На сегодняшний момент NGINX в основном используется как транспорт данных уровня 7. Но разработчики должны создать много вспомогательных конструкций вокруг NGINX, чтобы заставить его работать. Вам нужно добавить автоматизацию и возможности CI/CD, настроить корректное логирование, добавить аутентификацию и управление сертификатами, и так далее. Мы хотим сделать намного лучшее расширение NGINX, где каждое большое требование к тестированию и развёртыванию приложения будет удовлетворяться одним и более высококачественными компонентами с открытыми исходниками, которые бесшовно интегрируются с NGINX. Короче говоря, мы хотим предоставить ценность на каждом слое стека, и сделать это бесплатно. Например, если вы используете NGINX Open Source или NGINX Plus в качестве шлюза API, мы хотим убедиться в том, что у вас есть всё необходимое для управления и масштабирования этого варианта использования — импорт API, обнаружение сервисов, файрвол, политики правил и безопасность — всё доступное как высококачественные варианты с открытыми исходникам.
Подводя итог, наша мечта — построить экосистему вокруг NGINX, которая распространяется в каждую грань управления и развёртывания приложения. MARA — первый шаг в построении этой экосистемы, и мы хотим продолжить привлечение партнёров. Моя цель — увидеть в конце 2022 у предварительно подключенного приложения полный запуск за минуты и работу в окружении NGINX, оборудованного полным комплектом возможностей — распределённый трейсинг, логирование, автомасштабирование, безопасность, хуки CI/CD — и все готовы выполнить свою работу.
Представляем Kubernetes API Gateway, новый Amplify и NGINX Agent
Мы подтверждаем, что будем придерживаться обещанного. И вот три авансовых взноса по моим трем обещаниям.
Ранее в этом году мы запустили NGINX Kubernetes Gateway, основанный на эталонной архитектуре Kubernetes API Gateway SIG. Это модернизирует нашу продуктовую линейку и позволяет нам идти в ногу с продолжающимся развитием облачных решений. NGINX Kubernetes Gateway — что‑то вроде оливковой ветви, которую мы протягиваем сообществу <похоже, имеется в виду оливковая ветвь как символ мира — прим. перев.> Мы понимаем, что всё запуталось, когда мы создали Ingress controller for Kubernetes — и платный, и с открытыми исходниками, и оба отличались от решения Ingress сообщества (также основанного на Nginx). Широкий выбор запутал сообщество, и поставил нас в неудобное положение.
Достаточно ясно, что Gateway API собирается занять место ingress‑контроллера в архитектуре Kubernetes. Так что мы изменяем свой подход и сделаем NGINX Kubernetes Gateway — который будет предлагаться только как продукт с открытыми исходниками — точкой сосредоточения наших усилий по части сети для Kubernetes (в ногу с развивающимся стандартом). Он будет и интегрироваться, и расширяться другими продуктами NGINX, и оптимизирует опыт разработчика для Kubernetes.Несколько лет назад мы запустили NGINX Amplify, SaaS‑предложение мониторинга и телеметрии для групп NGINX. На самом деле мы не особо его афишировали. Но тысячи разработчиков нашли его, и всё ещё используют его по сей день. Amplify был и останется бесплатным. Как часть нашего обещания модернизации, мы добавляем к Amplify множество новых возможностей. Мы нацелены на то, чтобы сделать его вашим надёжным «вторым пилотом», способным поддержать, наблюдать и управлять продуктами NGINX в масштабе в реальном времени. Amplify будет не только мониторить ваши экземпляры NGINX, но поможет вам настроить, применить скрипты и устранить неполадки в развёртываниях NGINX.
Мы запускаем NGINX Agent, легковесное приложение, которые вы развернёте рядом с экземплярами NGINX Open Source. В него войдут те функции, которые ранее предлагались только в коммерческих продуктах, например — API динамической конфигурации. С NGINX Agent вы сможете использовать NGINX Open Source в большем количестве случаев и с намного большей гибкостью. Он также включит в себя намного больше тонких настроек, которые вы сможете использовать для расширения ваших приложений и инфраструктуры. Agent поможет вам принять более элегантные решения об управлении, развёртывании и настройке NGINX. Мы старательно работаем над NGINX Agent — поглядывайте на блог, который появится в следующую пару месяцев, в ожидании объявления доступности <Nginx Agent — прим.перев.>!
Глядя вперед
Я надеюсь, что через год вы спросите меня про эти обязательства. Если я не смогу отчитаться о реальном прогрессе — требуйте это с меня. И, пожалуйста, поймите — мы заинтересованы и готовы говорить с вами со всеми. Вы — наша лучшая дорожная карта продукта. Пожалуйста, пройдите наш ежегодный опрос. Приходите в канал nginxcommunity в Slack и скажите нам, что вы думаете. Комментируйте и присылайте пулл‑запросы в проекты в нашем репо на GitHub.
Будет великолепный год, лучший, чем когда‑либо. Мы с нетерпением хотим услышать вас, и, пожалуйста, полагайтесь на то, что услышите больше от нас. Помогите нам помочь вам.
Послесловие переводчика
Дата выхода оригинальной статьи - 23 августа 2022 года. Я на статью наткнулся случайно, и текст прямо вдохновил начать перевод, потом споткнулся о какую-то заковыристую конструкцию и бросил. Недавно доделал. Подумал, что лучше выложить с опозданием на 10 месяцев, чем не выкладывать вовсе.
NGINX - зарегистрированная торговая марка F5, Inc.
Комментарии (20)
hVostt
02.07.2023 21:10+4Будем честными. На момент выхода, в своё время у Nginx-а просто не было альтернатив. Он и сейчас очень хорош. Но многих критичных функций в Open Source просто нет, или даются с большими усилиями. Благо теперь есть достойные альтернативы.
mrobespierre
02.07.2023 21:10+2Будем честными? Ну давайте, будем. Lighty уже был. Да и Апачи можно настроить аля nginx, потерять условных 90% функциональности (оно всё равно почти никому не нужно), но и получить условных 70-80% скорости nginx (да-да, так можно, просто почти никто не умеет). Так что альтернативы были. Просто nginx чуточку лучше.
Что до тэйка "многих критичных функций в Open Source просто нет, или даются с большими усилиями" я бы послушал поподробнее. Апачи обгнояет по функционалу известные мне проприетарные веб-серверы даже не намного, а "на круги".
SignFinder
02.07.2023 21:10+2Очень странно, что в разговоре про современные альтернативы вы предлагаете сравнение с Apache :-)
Я пожалуй соглашусь с @hVostt - nginx сейчас в роли догоняющего, ибо nginx был хорош как front-end и так как именно он светится снаружи - то там и набежало 55% всех веб серверов.
А стандартом для полноценного front+backend nginx IMHO так и не стал.
А сейчас "мир изменился" и сейчас действительно есть альтернативы. Caddy, traefik и т.п. вовсю теснят nginx в K8S, периодически всплывает информация о миграции с nginx сервисов в больших компаниях.
mrobespierre
02.07.2023 21:10+1Очень странно, что в разговоре про современные альтернативы вы предлагаете сравнение с Apache :-)
Нет, не странно. Если вы прочтёте 2-ое предложение hVostt, а потом ещё раз, то поймете, что я оспаривал тезис про софт 15-летней давности.
Что до Caddy и Traefik они open source т.ч. вы не соглашаетесь с hVostt, а наоборот, оспариваете его утверждение:
Но многих критичных функций в Open Source просто нет, или даются с большими усилиями. Благо теперь есть достойные альтернативы.
mayorovp
02.07.2023 21:10+1Вы вырвали утверждение из контекста.
Но многих критичных функций в Open Source [Nginx] просто нет, или даются с большими усилиями. Благо теперь есть достойные [Open Source] альтернативы.
SignFinder
02.07.2023 21:10+1Тоже прочитал эту фразу как "nginx opensource по сравнению с коммерческим nginx plus".
saboteur_kiev
02.07.2023 21:10Подозреваю, что Игорь не просто так вышел из дела. Как минимум одним из аргументов были проблемы с яндексом
DiSha
02.07.2023 21:10+3Вроде как с Рамблером. Или что то пропустил и с ними тоже были проблемы?
saboteur_kiev
02.07.2023 21:10а, рамблер. Я путаю. мне все время кажется что там везде один владелец, или скоро будет
Nurked
02.07.2023 21:10+2А чё на этой вашей картинке делает логотип Федоры? Тут все бурлят что они слились.
Лично я для бэкенда перестал использовать вообще хоть что-то. Голанг отлично и без серверов справляется. Но у меня случай частный. Так что за всех говорить не буду.
flancer
02.07.2023 21:10-2А nginx уже научился проксировать (upstream) HTTP/2 траффик? Не gRPC, а именно HTTP/2. Полтора года назад у него это не получалось. Приходилось сидеть на apache.
mayorovp
02.07.2023 21:10+1Сидеть на apache из-за HTTP/2 — это сильно придумано. Проще голый сервер приложений выставить наружу, современные по-быстрее апача будут на медленных соединениях. А вообще, traefik разве настолько недавно появился что полтора года назад его не было?
flancer
02.07.2023 21:10Ну, я на Apache сел, как только слез с IIS'а - привык уже. А пересесть на nginx поводов не находилось - .htaccess очень удобная вещь, когда тебе не надо в перформанс играться. certbot, опять же, с apache'м, как с родным, работает. Есть у него свои плюсы в моих глазах.
Я тут посмотрел, что такое traefik - может он и был полтора года назад, но я в своём комменте говорил о том, что nginx не поддерживал HTTP/2 в upstream. В том числе и в гугловском облаке. У них nginx перед nodejs приложениями стоял (стоит?).
mayorovp
02.07.2023 21:10certbot и с nginx работает, а у traefik он вообще встроенный.
Вся необходимая конфигурация для получения сертификатов[entryPoints.websecure] http.tls.certResolver = "le" [certificatesResolvers.le.acme] email = "..." storage = "/etc/traefik/acme.json" httpChallenge.entryPoint = "web"
Mimik_fc7
02.07.2023 21:10Когда квик вкрутите, не забудьте добавить и поддержку connection upgrade, мне пришлось знатно попотеть раскапывая вашу логику и вкручивая квик на вебсокеты
mayorovp
02.07.2023 21:10А разве метод UPGRADE для "старших" версий HTTP в принципе возможен?
Когда я последний раз изучал этот вопрос — вебсокеты требовали HTTP не старше 1.1, и было предложение по использованию метода CONNECT в более старших версиях протокола.
achekalin
Amplify не сказать чтобы совсем легковесная штука (с учетом, что работает она агентом по сбору и отправке статистики).
Agent так и не реализован.
Год почти прошел, но движения, на мой пристрастный взгляд, в стане open-source-ного Nginx стало не больше, а меньше.
tnt4brain Автор
Справедливости ради - https://github.com/nginx/agent.