​​Веб сервер Nginx уже давно умеет писать логи в json формате. В настройке по умолчанию используются текстовые логи. Да и почти везде, где мне приходится видеть логи веб сервера, они в текстовом формате. Если ещё не используете json формат для логов, то предлагаю вам пересмотреть свои привычки и использовать. Это удобно и для ручного просмотра логов, и для парсинга в тех или иных системах.

Настроить json логи очень просто. Вот пример для привычного формата combined, только в json. Добавляем в основной конфиг в раздел http { }.

log_format json_combined escape=json
 '{'
  '"time_local":"$time_local",'
  '"remote_addr":"$remote_addr",'
  '"remote_user":"$remote_user",'
  '"request":"$request",'
  '"status": "$status",'
  '"body_bytes_sent":"$body_bytes_sent",'
  '"request_time":"$request_time",'
  '"http_referrer":"$http_referer",'
  '"http_user_agent":"$http_user_agent"'
 '}';

И дальше либо в общую настройку, либо в настройку логов виртуального хоста добавляем:

access_log /var/log/nginx/access.log json_combined;

Теперь, если отправить логи в ELK или Zabbix, их обработка будет упрощена, так как для json формата там есть готовые обработчики. А в консоли логи удобно смотреть с помощью jq. Смотрим весь лог:

# jq '.' access.log

Смотрим только список урлов, к которым были обращения:

# jq '.request' access.log

Выводим полные записи логов, где только 404 коды ответов:

# jq '. | select(.status=="404")' access.log

Теперь то же самое, только выводим не полные строки, а урл, где код ответа был 404:

# jq '. | select(.status=="404") | .request' access.log

Добавим сюда же информацию о времени запроса:

# jq '. | select(.status=="404") | .time_local,.request' access.log

Думаю, идею вы поняли. Json смотреть проще, быстрее и гибче, нежели грепать или обрабатывать утилитами типа sed, awk и т.д. Надо только немного изучить синтаксис jq. Если хотите получить значения без кавычек " ", то добавьте к jq ключ -r:

# jq -r '.request' access.log

Все переменные, которые вы можете использовать в логе, перечислены в документации к модулю ngx_http_core_module. Я обычно добавляю некоторые переменные к стандартным, а именно:

◽$request_length, $upstream_addr,
◽$upstream_status,
◽$upstream_response_time,
◽$upstream_connect_time,
◽$upstream_header_time,
◽$server_name,
◽$ssl_protocol,
◽$ssl_cipher.

#nginx #jq

​​Более двух лет назад я вам уже рассказывал про Nginx Proxy Manager. Это веб панель для управления Nginx в режиме proxy_pass. С той заметки прошло много времени, а панелька эта очень активно развивается. Недавно в одном из видео я увидел эту панель в работе. Автор её очень сильно нахваливал.

Посмотрел на неё ещё раз. Она с тех пор заматерела. Изменила адрес репозитория, собрала много звёзд на гитхабе (14,1k, было ~2k). Получила красивую документацию. При этом не обросла лишним функционалом, не стала платной. Автору явно нравится его детище. Постоянно видны исправления, выход новых версий.

Живёт всё в одном контейнере, если ваc устраивает хранить состояние панели в базе SQLite. В противном случае можете настроить хранение в MySQL. В документации автор предлагает docker-compose файл для запуска, но так как контейнер всего один, проще запустить напрямую через docker:

# docker run -d --restart unless-stopped \
-p 80:80 -p 81:81 -p 443:443 \
-v ./data:/data -v ./letsencrypt:/etc/letsencrypt \
jc21/nginx-proxy-manager:latest

Далее идёте на 81-й порт своего сервера и логинитесь под учёткой admin@example.com / changeme. Не забудьте сразу поменять, если он смотрит в интернет. Вся конфигурация и сертификаты будут храниться в созданных директориях, так что их удобно бэкапить.

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

⇨ Сайт / Исходники / Обзор / NPM vs Traefik

#nginx #webserver

​​Веб сервер Nginx поддерживает интеграцию с языком программирования Lua. Реализуется это с помощью специального модуля для Nginx. В стандартных пакетах с nginx чаще всего нет этого модуля. В Debian и Ubuntu его можно поставить с помощью пакета nginx-extras:
# apt install nginx-extras

Также существует веб сервер на основе Nginx и Lua — OpenResty . Он полностью совместим с Nginx и следует за его релизами. Отличает его только наличие дополнительных модулей для работы с Lua.

Чаще всего в Nginx Lua используют для борьбы с ddos атаками. Вот навороченный пример готового скрипта на lua для этого — Nginx-Lua-Anti-DDoS. Я его попробовал, работает нормально. И очень удобно. У него куча возможностей по блокировке тех или иных клиентов. С базовыми настройками он блокирует некоторых ботов, подсети некоторых хостеров и осуществляет защиту от ботов с помощью страницы заглушки на javascript (пример на картинке), которая добавляет зашифрованную куку. Потом редиректит на основную страницу и проверяет эту куку.

Не буду расписывать установку и настройку этого скрипта. Всё необходимое есть в репозитории. Я немного повозился, но всё настроил. Если вас донимают какие-то боты, попробуйте, должно помочь. Скрипт позволяет в одном месте работать со всеми ограничениями и настройками, что удобно. Если не нужен, можно очень быстро его отключить. Все настройки прокомментированы в самом скрипте.

По теме nginx и lua очень много всего гуглится, если искать по словам nginx lua antiddos. Вот ещё пару примеров:
⇨ LUA в nginx: слегка интеллектуальный firewall
⇨ Защита от DDoS на уровне веб-сервера

Кстати, CloudFlare как раз и осуществляет свою защиту на базе Lua с помощью веб сервера OpenResty. Или осуществлял. Сейчас может уже на что-то другое перешли. Так что если работаете с веб серверами и не используете Lua, обратите на него внимание. Очень многие вещи с его помощью делать удобно.

#nginx #webserver

​​Некоторое время назад я рассказывал про программу Vector, с помощью которой удобно управлять потоками данных. Сейчас покажу, как с её помощью отправить логи Nginx в сервис axiom.co, где бесплатно можно хранить и обрабатывать до 500 ГБ в месяц. Это отличная возможность быстро собрать дашборд для анализа логов веб сервера.

Сначала зарегистрируйтесь в axiom.co. Там не нужны ни кредитки, ни какая-то ещё информация, кроме email. Сразу получите аккаунт с очень солидными бесплатными лимитами. Там же создайте новый Dataset и к нему API ключ. Это условный аналог облака Elastic на минималках. Я собственно, про него и хотел рассказать, но решил сразу на конкретном примере. К тому же у вектора не очень очевидная документация, особенно в плане преобразований. В своё время долго разбирался, как там парсинг json и grok фильтры правильно настраивать и описывать в конфигах.

Установите Vector любым удобным способом из документации. Настройте логи Nginx в формате json. Это можно не делать, но тогда понадобится grok фильтр для обработки access лога, что дольше и сложнее, чем использование сразу json. Рисуем конфиг для Vector.

[sources.nginx_access_logs]
type     = "file"
include   = ["/var/log/nginx/access.log"]

[transforms.nginx_access_logs_parsed]
type = "remap"
inputs = ["nginx_access_logs"]
source = '''
. = parse_json!(.message)
'''

[sinks.axiom]
inputs = ["nginx_access_logs_parsed"]
type = "axiom"
token = "xaat-36c1ff8f-447f-454e-99fd-abe804aeebf3"
dataset = "webserver"

У Vector есть готовая интеграция с axiom, что я и указал в sinks. Теперь запускайте Vector и идите в axiom.co. На вкладке Streams увидите свои логи в режиме реального времени.

Теперь можно зайти в Dashboards и собрать любой дашборд на основе данных лога Nginx. Чем более насыщенный лог, что настраивается в конфиге Nginx, тем больше данных для визуализации. Я для тестового сервера собрал дашборд буквально за 10 минут. Смотрите во вложении к заметке.

Такая вот заметка-инструкция получилась. Vector я уже рекомендовал, теперь советую посмотреть на описанный сервис. Меня никто не просил его рекламировать. Он просто удобный и есть функциональный бесплатный тарифный план. В него включены также 3 оповещения. Например, можно настроить, что если у вас в минуту будет больше 10 500-х ошибок сервера, прилетит оповещение. Или что-то ещё. Там большие возможности для насыщения, аггегации и других манипуляций с данными. Разобраться проще, чем в ELK или OpenSearch.

Для любителей grok, как я, покажу пример transforms в Vector своего формата логов Nginx. Вот пример формата лога, который я обычно использую, где есть всё, что мне надо:

  log_format full   '$remote_addr - $host [$time_local] "$request" '
        'request_length=$request_length '
        'status=$status bytes_sent=$bytes_sent '
        'body_bytes_sent=$body_bytes_sent '
        'referer=$http_referer '
        'user_agent="$http_user_agent" '
        'upstream_status=$upstream_status '
        'request_time=$request_time '
        'upstream_response_time=$upstream_response_time '
        'upstream_connect_time=$upstream_connect_time '
        'upstream_header_time=$upstream_header_time';

Вот grok фильтр в Vector:

[transforms.nginx_access_logs_parsed]
type = "remap"
inputs = ["nginx_access_logs"]
source = '''
. = parse_grok!(.message, "%{IPORHOST:remote_ip} - %{DATA:virt_host} \\[%{HTTPDATE:access_time}\\] \"%{WORD:http_method} %{DATA:url} HTTP/%{NUMBER:http_version}\" request_length=%{INT:request_length} status=%{INT:status} bytes_sent=%{INT:bytes_sent} body_bytes_sent=%{NUMBER:body_bytes_sent} referer=%{DATA:referer} user_agent=\"%{DATA:user_agent}\" upstream_status=%{DATA:upstream_status} request_time=%{NUMBER:request_time} upstream_response_time=%{DATA:upstream_response_time} upstream_connect_time=%{DATA:upstream_connect_time} upstream_header_time=%{DATA:upstream_header_time}")
'''

#nginx #logs #devops

​​Если вам нужно заблокировать какую-то страну, чтобы ограничить доступ к вашим сервисам, например, с помощью iptables или nginx, потребуется список IP адресов по странам.

Я сам всегда использую вот эти списки:
⇨ https://www.ipdeny.com/ipblocks
Конкретно в скриптах забираю их по урлам. Например, для России:
⇨ https://www.ipdeny.com/ipblocks/data/countries/ru.zone
Это удобно, потому что списки уже готовы к использованию — одна строка, одно значение. Можно удобно интегрировать в скрипты. Например, вот так:

#!/bin/bash

# Удаляем список, если он уже есть
ipset -X whitelist
# Создаем новый список
ipset -N whitelist nethash

# Скачиваем файлы тех стран, что нас интересуют и сразу объединяем в единый список
wget -O netwhite http://www.ipdeny.com/ipblocks/data/countries/{ru,ua,kz,by,uz,md,kg,de,am,az,ge,ee,tj,lv}.zone

echo -n "Загружаем белый список в IPSET..."
# Читаем список сетей и построчно добавляем в ipset
list=$(cat netwhite)
for ipnet in $list
 do
 ipset -A whitelist $ipnet
 done
echo "Завершено"
# Выгружаем созданный список в файл для проверки состава
ipset -L whitelist > w-export

Тут я создаю список IP адресов для ipset, а потом использую его в iptables:

iptables -A INPUT -i $WAN -m set --match-set whitenet src -p tcp --dport 80 -j ACCEPT

Если в списке адресов более 1-2 тысяч значений, использовать ipset обязательно. Iptables начнёт отжирать очень много памяти, если загружать огромные списки в него напрямую.

Есть ещё вот такой сервис:
⇨ https://www.ip2location.com/free/visitor-blocker
Там можно сразу конфиг получить для конкретного сервиса: Apache, Nginx, правил Iptables и других. Даже правила в формате Mikrotik есть.

☝ Ссылки рекомендую в закладки забрать.

#iptables #nginx #security #script

​​На практике регулярно приходится собирать Nginx с дополнительными модулями. Чаще всего это модули brotli, vts или lua. У меня когда-то была статья для Centos по этой теме, но она уже неактуальна. Решил сделать мини-инструкцию по сборке своего пакета Nginx для Debian на примере добавления туда модуля статистки vts. А завтра отдельной публикацией покажу, как с его помощью очень быстро организовать мониторинг Nginx.

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

Устанавливаем необходимые зависимости, которые понадобятся для сборки Nginx и упаковки в deb пакет:
# apt install dpkg-dev devscripts quilte quivs wget dh-make build-essential \
git libpcre++-dev libssl-dev libgeoip-dev libxslt1-dev zlib1g-dev libpcre2-dev

Скачиваем файлы, которые нам понадобятся: исходники и настройки:
# mkdir build && cd build
# wget http://nginx.org/packages/debian/pool/nginx/n/nginx/nginx_1.24.0-1~bullseye.debian.tar.xz
# wget http://nginx.org/download/nginx-1.24.0.tar.gz

Распаковываем всё и удаляем архивы, чтобы не мешали:
# tar xvf nginx_1.24.0-1~bullseye.debian.tar.xz
# tar xzvf nginx-1.24.0.tar.gz
# rm -rf nginx_1.24.0-1~bullseye.debian.tar.xz nginx-1.24.0.tar.gz

Создаём директорию для модулей:
# mkdir debian/modules

Копируем туда исходники nginx-module-vts:
# cd debian/modules
# git clone https://github.com/vozlt/nginx-module-vts

Возвращаемся обратно в build и переносим директорию debian/ в папку с исходниками:
# cd ../../
# mv debian ./nginx-1.24.0
# cd nginx-1.24.0

Редактируем некоторые файлы. Начинаем с debian/changelog. Добавьте в начало по аналогии новую запись с описанием нового пакета. Примерно так:
nginx (1.24.0-1~bullseye) bullseye; urgency=low

 * 1.24.0-1
 * Add nginx-module-vts

 -- Serveradmin <root@serveradmin.ru> Fri, 18 Aug 2023 10:03:46 +0300

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

Далее вам может понадобиться файл debian/control, где можно добавить зависимости. В моём случае новых зависимостей не появится. А если вы, к примеру, захотите добавить модуль с lua, то там нужно будет пару пакетов в систему установить. Просто добавьте их в Build-Depends.

Открываем файл debian/rules и добавляем туда:
MODULESDIR = $(CURDIR)/debian/modules
Можете эту строку добавить сразу же после строки с BASEDIR. Далее ищем строки с ./configure и добавляем к ним в конец дополнительный параметр:
--add-module=$(MODULESDIR)/nginx-module-vts
Здесь же можете удалить лишние модули, которые вам точно не понадобятся.

Удаляем файл debian/source/format. Он не даст собрать пакет.
# rm -rf debian/source/format

Сохраняем файл и собираем архив с настройками пакета:
# dh_make --copyright gpl -s -e root@serveradmin.ru --createorig -y -p nginx_1.24.0
В директории build должен появиться файл nginx_1.24.0.orig.tar.xz.

Собираем пакет:
# dpkg-buildpackage -rfakeroot

В директории build должен появиться в том числе файл с пакетом nginx_1.24.0-1~bullseye_amd64.deb. Его можно установить и проверить:
# dpkg -i nginx_1.24.0-1~bullseye_amd64.deb

Проверяем, есть ли там наш модуль:
# nginx -V
В самом конце должно быть
--add-module=/root/build/nginx-1.24.0/debian/modules/nginx-module-vts

На этом всё. Таким образом можно собирать любые сборки Nginx под свои потребности и размещать их в своих репозиториях. Например, с помощью Nexus, aptly, apt-offline и т.д.

Заметка получилась полноценной инструкцией с информацией, которую я в интернете не нашёл в готовом виде. Пришлось написать самому.

#debian #nginx

​​Популярный вопрос к моим статьям и заметкам по настройке проксирования HTTP запросов с Nginx куда-то на backend. Нужно ли настраивать HTTPS и как вообще правильно это сделать. Поясню, о чём идёт речь.

Допустим, у вас есть какой-то сервер Nginx, работающий в режиме proxy_pass и раскидывающий соединения к разным доменам по разным серверам или контейнерам. Либо это один большой сайт с несколькими бэкендами. Очевидно, что соединение клиента с этим Nginx настроено по HTTPS. А от Nginx до остальных серверов нужно ли настраивать по HTTPS?

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

Исключение делаю тогда, когда проксируемое приложение или сервис начинают работать некорректно при такой схеме. Это бывает нередко. Приходится либо настройки сайта крутить, либо дополнительные заголовки добавлять, либо что-то ещё делать. Если простых способов решить проблемы нет, то приходится настраивать всю цепочку соединений по HTTPS.

Некоторые примеры подобных ошибок и их решения я публиковал на сайте (phpmyadmin, wordpress). Точно надо что-то делать с Bitrix, если проксируешь его по HTTP. Сейчас уже не помню, что именно. Не записывал. Каждый раз по месту разбираюсь.

А вы как считаете? Нужно ли в этом случае настраивать HTTPS, при условии, что запросы гуляют по нашей внутренней сети, которая считается доверенной? Если речь идёт про проксирование через сторонний сервис, тот же Cloudflare, или другую систему защиты от DDOS, то HTTPS я всегда настраиваю.

#nginx #webserver

​​Я вчера рассказал, как собрать Nginx с модулем статистики vts. Расскажу теперь, как его настроить и собрать метрики в систему мониторинга Prometheus.

Для настройки статистики вам достаточно добавить в основной файл конфигурации nginx.conf в секцию http:
vhost_traffic_status_zone;

И в любой виртуальных хост ещё один location. Я обычно в default добавляю:

server {
  listen    80;
  server_name localhost;
.........................
location /status {
vhost_traffic_status_display;
  vhost_traffic_status_display_format html;
}
..................

Теперь можно сходить по ip адресу сервера и посмотреть статистику прямо в браузере - http://10.20.1.56/status/. Сразу покажу ещё два важных и полезных урла: /status/format/json и /status/format/prometheus. По ним вы заберёте метрики в формате json или prometheus. Последняя ссылка нам будет нужна далее. Я покажу настройку мониторинга Nginx на примере Prometheus, так как это самый быстрый вариант. Имея все метрики в json формате, нетрудно и в Zabbix всё это закинуть через предобработку с помощью jsonpath, но времени побольше уйдёт.

Устанавливаем Prometheus. Нам нужен будет любой хост с Docker. Готовим конфиг, куда сразу добавим сервер с Nginx:
# mkdir prom_data && cd prom_data && touch prometheus.yaml

global:
 scrape_interval:   5s
 evaluation_interval: 5s

rule_files:

scrape_configs:
 - job_name: prometheus
  static_configs:
   - targets: ['localhost:9090']

 - job_name: nginx_vts
  metrics_path: '/status/format/prometheus'
  static_configs:
   - targets: ['10.20.1.56:80']

Это по сути стандартный конфиг, куда я добавил ещё один target nginx_vts. Запускаем Prometheus:
# docker run -p 9090:9090 -d --name=prom \
-v ~/prom_data/prometheus.yaml:/etc/prometheus/prometheus.yml \
prom/prometheus

Идём на ip адрес хоста и порт 9090, где запущен Prometheus. Убеждаемся, что он работает, а в разделе Status -> Targets наш Endpoint nginx_vts доступен. Можете взять метрики со страницы /status/format/prometheus и подёргать их в Prometheus. Разбирать работу с ним не буду, так как это отдельная история.

Теперь ставим Grafana, можно на этот же хост с Prometheus:
# docker run -p 3000:3000 -d --name=grafana grafana/grafana
Идём на ip адрес и порт 3000, видим интерфейс Графаны. Учётка по умолчанию admin / admin. Идём в раздел Administration -> Data sources и добавляем новый типа Prometheus. Из необходимых настроек достаточно указать только URL прома. В моём случае http://172.27.60.187:9090.

Теперь нам надо добавить готовый Dashboard для Nginx VTS. Их представлено штук 10 на сайте Grafana, но реально актуальный и работающий без доработки только один - https://grafana.com/grafana/dashboards/14824-nginx-vts-stats/. Соответственно, в разделе Dashboards Графаны нажимаем Import и указываем URL приведённого выше дашборда. Все основные метрики вы увидите на нём. Если надо добавить что-то ещё, то идёте на /status/format/prometheus, смотрите метрику и добавляете запрос с ней в Grafana.

Если с Prometheus не работали ранее, то подобное описание возможно не очень подробное, но в рамках заметки тему не раскрыть. Зато когда разберётесь и научитесь, настройка такого мониторинга будет занимать минут 10. Даже если в готовом дашборде что-то не будет работать, нетрудно подредактировать. Как Grafana, так и VTS модуль активно развиваются, поэтому старые дашборды в основном нерабочие. Но тут метрик не так много, так что не критично. Можно либо поправить, либо самому всё сделать.

На картинке всё не уместилось. Ниже ещё статистика по бэкендам будет. Примеры можно посмотреть в описании дашборда на сайте Grafana.

#nginx #мониторинг #prometheus #grafana

​​Многие, наверное, уже слышали, что некоторое количество бывших разработчиков Nginx создали форк и начали его развивать под названием Angie. Я видел эту новость давно, но не вникал в подробности. Сейчас решил разобраться и посмотреть, что в итоге получилось. Событие необычное.

Разработчики организовали ООО "Веб-Сервер", создали сайт и репозиторий нового веб сервера. Первое, что мне бросилось в глаза - сайт компании на тильде, где даже иконку не поменяли со стандартной тильдовской. Может это и не значит ничего, но лично мне кажется, что если компания решила заняться серьезной коммерческой деятельностью, то хотя бы иконку на сайте она бы сделала в соответствии со своим логотипом.

Вообще, Angie появился примерно год назад в виде open source проекта. А весной 2023 года появилась коммерческая версия Angie Pro. Он имеет сертификаты совместимости с отечественными операционными системами РЕД ОС, Astra Linux Special Edition и Альт Сервер 10. Авторы говорят про него: "Angie PRO – единственный коммерческий веб-сервер разработка которого локализована в России."

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

При этом никто не мешает вам уже сейчас начать использовать Angie. Он доступен на операционных системах Alma Linux 8 и 9 версий, Alpine 3.18, Centos 7, 8 и 9 версий, Debian 12 и Ubuntu 23.04. Для них подготовлены репозитории от разработчиков. Я установил на Debian 12:

# curl -o /etc/apt/trusted.gpg.d/angie-signing.gpg \
https://angie.software/keys/angie-signing.gpg
# echo "deb https://download.angie.software/angie/debian/ `lsb_release -cs` main" \
| tee /etc/apt/sources.list.d/angie.list > /dev/null
# apt update && apt install angie

По конфигам тот же самый Nginx, но уже видны некоторые различия в именованиях директорий. На сайте Angie заявлено, что им можно подменить Nginx без каких-либо правок конфигурации.

Судя по публичному репозиторию, работа над веб сервером активно ведётся. Как по мне, новость отличная. Веб сервер с полной локализацией в РФ лишним точно не будет. Тем более, что разработку начали не с нуля, а взяли готовый продукт, над которым работают его же бывшие разработчики.

Помимо обычного веб сервера, разработчики работают над Angie Ingress Controller (ANIC) для Kubernetes. Его, как Angie Pro, можно приобрести с услугой внедрения и технической поддержки.

#отечественное #nginx #webserver

​​После моей недавней заметки про Angie, в комментариях появился один из разработчиков этого продукта и дал более конкретную информацию. Так как комментарии читают не все, я хочу зафиксировать основную информацию отдельным сообщением.

1️⃣ Angie это не пересборка Nginx для перепродажи в России. Над развитием продукта работают разработчики. Изменения вносятся в том числе в open source версию и это будет продолжаться. Angie Pro не копия Nginx Plus. Это другой продукт.

2️⃣ Другой сайт будет. То, что сейчас на Тильде, это временно. Сейчас фокус на сам продукт, его код и другие организационные моменты.

3️⃣ У Angie есть свой Telegram канал - https://xn--r1a.website/angie_software.

4️⃣ На сайте после моей заметки появилась обзорная статья: Сходства и различия Angie и nginx. (nginx почему-то с маленькой буквы, а Angie с большой 😁) Основные моменты оттуда (что-то в сокращении):

🔹в Angie нет кода NGINX Plus, закрытой коммерческой версии nginx; более того, у нас нет цели сделать наш платный веб-сервер, Angie PRO, стопроцентной функциональной копией NGINX Plus

🔹Angie сознательно ориентируется на платформы, для которых “официальный” nginx будет собираться еще нескоро: это такие сертифицированные в России ОС, как ALT Linux, Astra Linux SE и РЕД ОС, а также процессоры “Байкал” и “Эльбрус”.

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

Последнее прокомментирую, так как это важно. Разработчики Angie решили сами собирать популярные динамические модули веб сервера, чтобы упростить жизнь пользователям. Недавно у меня была публикация, где я рассказывал, как собрать Nginx с нужными модулями. А здесь разработчики озаботились и решили эту проблему сами. Список готовых модулей можно посмотреть на сайте. Там всё наиболее популярное присутствует (brotli, lua, geoip и т.д.) Не нашёл только vts. Думаю, разработчикам имеет смысл обратить на него внимание тоже. Все модули собраны в пакеты и доступны из репозитория. Вообще, это существенный плюс в пользу того, чтобы поставить Angie вместо Nginx, если тебе нужен какой-то модуль.

🔹Следующий фактор, на который мы обращаем внимание в своей работе, — ускорение работы самого веб-сервера за счет устранения лишних задержек. Мы:
◽добавили API-интерфейс динамической конфигурации и средства адаптивной DNS-адресации;
◽реализовали механизм привязки пользовательских сессий к проксируемому серверу;
◽внедрили активные проверки работоспособности проксируемых серверов, уменьшающие вероятность отправки реального запроса на неработающий сервер;
◽создали возможность сегментировать прокси-кэш, тем самым более эффективно задействуя все ресурсы сервера.

🔹Еще одна область, в которой мы хотим добиться улучшений, — это гибкость и удобство настройки веб-сервера. Мы:
◽добавили для групп проксируемых серверов упомянутый выше API-интерфейс динамической конфигурации;
◽предоставили ряд других настроек, менее масштабных, но весьма полезных.

🔹Наконец, важным для нас аспектом развития Angie является мониторинг состояния самого веб-сервера и проксируемых серверов. Мы:
◽реализовали в API-интерфейсе возможность получения базовой информации о веб-сервере, а также статистики по всем основным аспектам его функционирования в популярных современных форматах;
◽внедрили уже упомянутые активные проверки проксируемых серверов, самостоятельно следящие за их работоспособностью;
◽добавили семейство настроек для сбора статистики по сессиям передачи данных и запросам разрешения адресов.

Спасибо за подробные комментарии и описание отличий. Все эти изменения выглядят очень привлекательно для эксплуатации. Наглядно видно развитие и фокус внимания на реальные потребности пользователей. Обязательно попробую этот веб сервер в деле.

#webserver #nginx #angie #отечественное