Nginx *

Nginx — это веб-сервер, который решает десятки бизнес-задач, гибко настраивается, масштабируется и работает почти на всех ОС и платформах. Список функций, возможностей и решаемых проблем из коробки можно расписать в небольшой брошюре. Но порой, ряд бизнес-задач можно решить, только разработав собственные модули для nginx. Это модули, которые ориентированы на бизнес и содержат некоторую бизнес-логику, а не только обобщенное системное решение.



Вообще все в nginx — это модули, которые когда-то кем-то были написаны. Поэтому писать модули под nginx не только можно, но и нужно. Когда это необходимо делать и зачем, расскажет Василий Сошников (dedokOne) на примере нескольких кейсов.

Поговорим о причинах, которые побуждают писать модули на C, об архитектуре и ядре nginx, анатомии HTTP-модулей, о C-модулях, NJS, Lua и nginx.conf. Это важно знать не только тем, кто разрабатывает под nginx, но также тем, кто использует nginx-конфиги, Lua или другой язык внутри nginx.

Примечание: статья написана на основе доклада Василия Сошникова. Доклад постоянно модернизируется и обновляется. Информация в материале довольно техническая и, чтобы извлечь максимум пользы, читателям необходимо иметь опыт работы с кодом nginx на среднем уровне и выше.

Привет, Хабр! Предлагаю вашему вниманию перевод поста: Миграция с Nginx на Envoy Proxy.

Envoy — это высокопроизводительный распределенный прокси-сервер (написанный на C++), предназначенный для отдельных сервисов и приложений, также это коммуникационная шина и «universal data plane», разработанный для больших микросервисных архитектур «service mesh». При его создании были учтены решения проблем, которые возникали при разработке таких серверов, как NGINX, HAProxy, аппаратных балансировщиков нагрузки и облачных балансировщиков нагрузки. Envoy работает вместе с каждым приложением и абстрагирует сеть, предоставляя общие функции независимо от платформы. Когда весь служебный трафик в инфраструктуре проходит через сетку Envoy, становится легко визуализировать проблемные области с помощью согласованной наблюдаемости, настройки общей производительности и добавления основных функций в определённом месте.

Возможности

• Архитектура вне процесса: envoy — это автономный, высокопроизводительный сервер занимающий небольшой объем оперативной памяти. Он работает совместно с любым языком приложения или фреймворком.
• Поддержка http/2 и grpc: envoy имеет первоклассную поддержку http/2 и grpc для входящих и исходящих соединений. Это прозрачный прокси от http/1.1 до http/2.
• Расширенная балансировка нагрузки: envoy поддерживает расширенные функции балансировки нагрузки, включая автоматические повторные попытки, разрыв цепи, глобальное ограничение скорости, затенение запросов, локальную балансировку нагрузки зоны и т. д.
• API для управления конфигурацией: envoy предоставляет надежный API для динамического управления своей конфигурацией.
• Наблюдаемость: глубокая наблюдаемость трафика L7, встроенная поддержка распределенной трассировки и наблюдаемость mongodb, dynamodb и многих других приложений.

Пренеприятнейшая история случилась с одним моим знакомым. Но насколько она оказалась неприятной для Михаила, настолько же занимательной для меня.

Надо сказать, что приятель мой вполне себе UNIX-пользователь: может сам поставить систему, установить mysql, php и сделать простейшие настройки nginx.
И есть у него десяток-полтора сайтов посвященных строительным инструментам.

Один из таких сайтов, посвященный бензопилам, плотненько сидит в ТОПe поисковиков. Сайт этот — некоммерческий обзорник, но кому-то поперек горла и повадились его атаковать. То DDoS, то брутфорс, то комменты напишут непотребные и шлют абузы на хостинг и в РКН.
Неожиданно всё стихло и это затишье оказалось не к добру, а сайт начал постепенно покидать верхние строчки выдачи.



То была присказка, дальше сама админская байка.

Время близилось ко сну когда раздался звонок телефона: «Сань, ты не глянешь мой сервер? Мне кажется меня хакнули, доказать не могу, но ощущение не покидает уже третью неделю. Может мне просто пора лечиться от паранойи?»

Nemesida WAF Free — бесплатная версия Nemesida WAF, обеспечивающая базовую защиту веб-приложения от атак класса OWASP на основе сигнатурного анализа. Nemesida WAF Free имеет собственную базу сигнатур, выявляет атаки на веб-приложения при минимальном количестве ложных срабатываний, обновляется из Linux-репозитория, устанавливается и настраивается за несколько минут, не требует компиляции и может быть подключена к уже установленному NGINX версии 1.12.2 или выше.


Что может произойти, если не следить за безопасностью и не использовать WAF

Некоторое время назад мы анонсировали поддержку Nemesida WAF Free для NGINX Mainline и Plus версий (раньше поддерживалась только Stable ветка). Решив на этом не останавливаться, мы добавили во Free-версию функционал отправки выявленных атак в личный кабинет.

Современный веб практически немыслим без медиаконтента: смартфоны есть практически у каждой нашей бабушки, все сидят в соцсетях, и простои в обслуживании дорого обходятся компаниям. Вашему вниманию расшифровка рассказа компании Badoo о том, как она организовала отдачу фотографий с помощью аппаратного решения, с какими проблемами производительности столкнулась в процессе, чем они были вызваны, ну и как эти проблемы были решены с помощью софтового решения на основе Nginx, обеспечив при этом отказоустойчивость на всех уровнях (видео). Благодарим авторов рассказа Олега Sannis Ефимова и Александра Дымова, которые поделились своим опытом на конференции Uptime day 4.

— Начнем с небольшого введения о том, как мы храним и кэшируем фотографии. У нас есть слой, на котором мы их храним, и слой, где мы фотографии кэшируем. При этом, если мы хотим добиваться большого хитрейта и снижать нагрузку на стораджи, нам важно, чтобы каждая фотография отдельного пользователя лежала на одном кэширующем сервере. Иначе нам пришлось бы ставить во столько раз больше дисков, во сколько у нас больше серверов. Хитрейт у нас в районе 99%, то есть мы в 100 раз снижаем нагрузку на наши storage, и для того, чтобы это сделать, еще 10 лет назад, когда все это строилось, у нас было 50 серверов. Соответственно, для того, чтобы эти фотографии отдавать, нам нужно было по сути 50 внешних доменов, которые эти серверы обслуживают.

Естественно, сразу встал вопрос: а если у нас один сервер упадет, будет недоступен, какую часть трафика мы теряем? Мы посмотрели, что есть на рынке, и решили купить железку, чтобы она решила все наши проблемы. Выбор пал на решение компании F5-network (которая, кстати, не так давно купила NGINX, Inc): BIG-IP Local Traffic Manager.

Апдейт (2023): Проект Commento заброшен и больше не развивается. Я настоятельно рекомендую переходить на Comentario — мой форк, в котором переработано почти всё.

Примечание: это перевод моего поста (англ.), описывающий реализацию сервера комментариев, используемую на том же сайте, где находится оригинал.

TL;DR-версия: я разработал конфигурацию Commento-сервера, которая легко и просто развёртывается в полуавтоматическом режиме. Скопируйте себе этот репозиторий с GitHub и следуйте инструкциям в README.

Некоторое время назад мне неудержимо захотелось сменить Disqus — который является, пожалуй, самой распространённой системой для добавления комментариев к страницам — на свободный и открытый Commento.

Почему именно Commento?

Проблема Disqus, как и многих других «бесплатных» продуктов, в том, что продуктом в данном случае является пользователь — то есть вы. Помимо этого, Disqus «обогащает» каждую страницу, где он используется, мегабайтами скриптов и более чем сотней дополнительных HTTP-запросов.

Плюс к этому, бесплатная его версия показывает рекламу, от которой можно откупиться «всего лишь» за 9 долларов в месяц (план Plus). Уже только этого достаточно, чтобы захотелось найти что-нибудь получше.

В какой-то момент я наткнулся на этот пост и узнал о существовании свободного сервера комментариев под названием Commento. По счастливому совпадению, Commento как раз не так давно стал полностью открытым — раньше он выпускался в двух вариантах, бесплатном Community и коммерческом Enterprise. Спасибо его разработчику Adhityaa Chandrasekar.

Предыстория

Так уж случилось, что нужно мне было где-то хранить более 1.5тб данных, да еще и обеспечить возможность скачивания их обычными пользователями по прямой ссылке. Поскольку традиционно такие объемы памяти идут уже на VDS, стоимость аренды которых не слишком вкладывается в бюджет проекта из категории «от нечего делать», а из исходных данных у меня был VPS 400GB SSD, куда при всем желании 1.5тб картинок без lossless сжатия поместить не удастся.

В прошлом году мы выпустили Nemesida WAF Free — динамический модуль для NGINX, блокирующий атаки на веб-приложения. В отличие от коммерческой версии, основанной на работе машинного обучения, бесплатная версия анализирует запросы только сигнатурным методом.

Особенности релиза Nemesida WAF 4.0.129

До текущего релиза динамический модуль Nemesida WAF поддерживал только Nginx Stable 1.12, 1.14 и 1.16. В новом релизе добавлена поддержка Nginx Mainline, начиная с 1.17, и Nginx Plus, начиная с 1.15.10 (R18).

Зачем делать еще один WAF?

Для приготовления преобразования из HTML и URL в PDF и PS нам понадобится сам nginx, генератор htmldoc и плагин ngx_http_htmldoc_module. (Я дал ссылки на свои форки, т.к. делал некоторые изменения, которые пока не удалось пропихнуть в оригинальный репозитории. Можно также воспользоваться готовым образом.)

Используя nginx для балансировки HTTP трафика на уровне L7 есть возможность направить запрос клиента на следующий сервер приложений, если целевой не возвращает положительный ответ. Проба механизма пассивной проверки состояния работоспособности сервера приложений показало неоднозначность документации и специфичность работы алгоритмов исключения сервера из пула рабочих серверов.

В одной из наших предыдущих статей мы рассказывали про важность двухфакторной аутентификации на корпоративных порталах компаний. В прошлый раз мы продемонстрировали, как настроить безопасную аутентификацию в web-сервере IIS.

В комментариях нас просили написать инструкцию для самых распространенных web-серверов под Linux — nginx и Apache.

Вы просили — мы написали.

Для приготовления асинхронных уведомлений из PostgreSQL в websocket нам понадобится сам nginx и его плагины postgres, push-stream, set-misc. (Я дал ссылки на свои форки, т.к. делал некоторые изменения, которые пока не удалось пропихнуть в оригинальные репозитории. Можно также воспользоваться готовым образом.)

Для приготовления сервиса центральной авторизации нам понадобится сам nginx и его плагины encrypted-session, echo, headers-more, auth_request, eval, set-misc. (Я дал ссылки на свои форки, т.к. делал некоторые изменения, которые пока не удалось пропихнуть в оригинальные репозитории. Можно также воспользоваться готовым образом.)

Для приготовления авторизации с капчей нам понадобится сам nginx и его плагины encrypted-session, form-input, ctpp2, echo, ldap, headers-more, auth_request, set-misc. (Я дал ссылки на свои форки, т.к. делал некоторые изменения, которые пока не удалось пропихнуть в оригинальные репозитории. Можно также воспользоваться готовым образом.)

Для приготовления авторизации с капчей нам понадобится сам nginx и его плагины encrypted-session, form-input, ctpp2, echo, headers-more, auth_request, auth_basic, set-misc. (Я дал ссылки на свои форки, т.к. делал некоторые изменения, которые пока не удалось пропихнуть в оригинальные репозитории. Можно также воспользоваться готовым образом.)

Для приготовления авторизации через ЕСИА нам понадобится сам nginx и его плагины encrypted-session, headers-more, auth_request, uuid4, set-misc, echo, json, sign, jwt. (Я дал ссылки на свои форки, т.к. делал некоторые изменения, которые пока не удалось пропихнуть в оригинальные репозитории. Можно также воспользоваться готовым образом.)

Я — виндузятник и всячески увиливаю от окончательного перехода на Linux на своём PC не смотря на все его преимущества. Поэтому последние пару лет для создания локальных площадок под проекты использовал Docker for Windows. Не сказать что штука сверхстабильная, но существенных проблем не вызывала, пока на одном проекте на Laravel площадка не стала вести себя странно: часть запросов (и всегда разная часть) возвращались с ошибкой. Скрипт не мог открыть файл кэша.

Бесполезно потратив изрядное количество времени на поиск причины решил в данном случае отказаться от Docker и развернуть площадку под WSL в ручном режиме.

Привет!
Меня зовут Сергей, я работаю инфраструктурным инженером в команде API платформы tinkoff.ru.

В этой статье я расскажу о проблемах, с которыми сталкивалась наша команда при подготовке балансировщиков на основе Nginx для различных проектов. Также расскажу об инструменте, который позволил преодолеть большую часть из них.

Привет, друзья. В преддверии запуска курса «Backend разработчик на PHP», традиционно делимся с вами переводом полезного материала.

Программное обеспечение решает все больше и больше повседневных задач, при этом становясь все сложнее и сложнее. Как однажды сказал Марк Андрессен, оно поглощает мир.



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

В этой статье я расскажу, как использовать pinba совместно с clickhouse и grafana вместо pinba_engine и pinboard.

На php-проекте pinba — пожалуй единственный надёжный способ понять, что происходит с производительностью. Правда обычно pinba внедряется только тогда, когда уже наблюдаются проблемы и не понятно «где копать».

Часто никто понятия не имеет, сколько раз в секунду/минуту вызывается тот или иной скрипт и начинают оптимизировать «на ощупь», начиная с тех мест, что кажутся логичнее.

Кто-то анализирует логи nginx, а кто-то медленные запросы в бд.

Конечно pinba не была бы лишней, но есть несколько причин, почему она есть далеко не на каждом проекте.