Более двух лет назад я вам уже рассказывал про Nginx Proxy Manager. Это веб панель для управления Nginx в режиме proxy_pass. С той заметки прошло много времени, а панелька эта очень активно развивается. Недавно в одном из видео я увидел эту панель в работе. Автор её очень сильно нахваливал.
Посмотрел на неё ещё раз. Она с тех пор заматерела. Изменила адрес репозитория, собрала много звёзд на гитхабе (14,1k, было ~2k). Получила красивую документацию. При этом не обросла лишним функционалом, не стала платной. Автору явно нравится его детище. Постоянно видны исправления, выход новых версий.
Живёт всё в одном контейнере, если ваc устраивает хранить состояние панели в базе SQLite. В противном случае можете настроить хранение в MySQL. В документации автор предлагает docker-compose файл для запуска, но так как контейнер всего один, проще запустить напрямую через docker:
Далее идёте на 81-й порт своего сервера и логинитесь под учёткой admin@example.com / changeme. Не забудьте сразу поменять, если он смотрит в интернет. Вся конфигурация и сертификаты будут храниться в созданных директориях, так что их удобно бэкапить.
Это хобби-проект одного разработчика, так что в прод такое ставить не стоит. А себе домой или для тестов вполне сойдёт. Приятный продукт с красивым веб интерфейсом, который решает одну конкретную задачу. И делает это хорошо. Рекомендую, если вам нужна подобная функциональность.
⇨ Сайт / Исходники / Обзор / NPM vs Traefik
#nginx #webserver
Посмотрел на неё ещё раз. Она с тех пор заматерела. Изменила адрес репозитория, собрала много звёзд на гитхабе (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
👍72👎2
Веб сервер Nginx поддерживает интеграцию с языком программирования Lua. Реализуется это с помощью специального модуля для Nginx. В стандартных пакетах с nginx чаще всего нет этого модуля. В Debian и Ubuntu его можно поставить с помощью пакета 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
# 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
👍71👎1
Некоторое время назад я рассказывал про программу Vector, с помощью которой удобно управлять потоками данных. Сейчас покажу, как с её помощью отправить логи Nginx в сервис axiom.co, где бесплатно можно хранить и обрабатывать до 500 ГБ в месяц. Это отличная возможность быстро собрать дашборд для анализа логов веб сервера.
Сначала зарегистрируйтесь в axiom.co. Там не нужны ни кредитки, ни какая-то ещё информация, кроме email. Сразу получите аккаунт с очень солидными бесплатными лимитами. Там же создайте новый Dataset и к нему API ключ. Это условный аналог облака Elastic на минималках. Я собственно, про него и хотел рассказать, но решил сразу на конкретном примере. К тому же у вектора не очень очевидная документация, особенно в плане преобразований. В своё время долго разбирался, как там парсинг json и grok фильтры правильно настраивать и описывать в конфигах.
Установите Vector любым удобным способом из документации. Настройте логи Nginx в формате json. Это можно не делать, но тогда понадобится grok фильтр для обработки access лога, что дольше и сложнее, чем использование сразу json. Рисуем конфиг для Vector.
У 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
Сначала зарегистрируйтесь в 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
👍63👎2
Если вам нужно заблокировать какую-то страну, чтобы ограничить доступ к вашим сервисам, например, с помощью iptables или nginx, потребуется список IP адресов по странам.
Я сам всегда использую вот эти списки:
⇨ https://www.ipdeny.com/ipblocks
Конкретно в скриптах забираю их по урлам. Например, для России:
⇨ https://www.ipdeny.com/ipblocks/data/countries/ru.zone
Это удобно, потому что списки уже готовы к использованию — одна строка, одно значение. Можно удобно интегрировать в скрипты. Например, вот так:
Тут я создаю список IP адресов для ipset, а потом использую его в iptables:
Если в списке адресов более 1-2 тысяч значений, использовать ipset обязательно. Iptables начнёт отжирать очень много памяти, если загружать огромные списки в него напрямую.
Есть ещё вот такой сервис:
⇨ https://www.ip2location.com/free/visitor-blocker
Там можно сразу конфиг получить для конкретного сервиса: Apache, Nginx, правил Iptables и других. Даже правила в формате Mikrotik есть.
☝ Ссылки рекомендую в закладки забрать.
#iptables #nginx #security #script
Я сам всегда использую вот эти списки:
⇨ 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}.zoneecho -n "Загружаем белый список в IPSET..."# Читаем список сетей и построчно добавляем в ipsetlist=$(cat netwhite)for ipnet in $list do ipset -A whitelist $ipnet doneecho "Завершено"# Выгружаем созданный список в файл для проверки состава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
👍141👎5
На практике регулярно приходится собирать Nginx с дополнительными модулями. Чаще всего это модули brotli, vts или lua. У меня когда-то была статья для Centos по этой теме, но она уже неактуальна. Решил сделать мини-инструкцию по сборке своего пакета Nginx для Debian на примере добавления туда модуля статистки vts. А завтра отдельной публикацией покажу, как с его помощью очень быстро организовать мониторинг Nginx.
Выполнять сборку следует на отдельной машине, а не на рабочем сервере, чтобы не засорять его лишними пакетами. Я буду использовать небольшой читинг, а не полноценную сбоку пакета, которая не очень проста. Возьму готовые файлы настроек для упаковки в Debian 11 из официального репозитория Nginx. Распакую их, немного изменю настройки и запакую с ними свой пакет.
Устанавливаем необходимые зависимости, которые понадобятся для сборки Nginx и упаковки в deb пакет:
Скачиваем файлы, которые нам понадобятся: исходники и настройки:
Распаковываем всё и удаляем архивы, чтобы не мешали:
Создаём директорию для модулей:
Копируем туда исходники nginx-module-vts:
Возвращаемся обратно в build и переносим директорию debian/ в папку с исходниками:
Редактируем некоторые файлы. Начинаем с
Важно следить за всеми отступами и пробелами. Если просто скопируете отсюда, то будут ошибки. Копируйте строки из исходного файла и меняйте их.
Далее вам может понадобиться файл
Открываем файл
Можете эту строку добавить сразу же после строки с BASEDIR. Далее ищем строки с ./configure и добавляем к ним в конец дополнительный параметр:
Здесь же можете удалить лишние модули, которые вам точно не понадобятся.
Удаляем файл
Сохраняем файл и собираем архив с настройками пакета:
В директории build должен появиться файл
Собираем пакет:
В директории build должен появиться в том числе файл с пакетом
Проверяем, есть ли там наш модуль:
В самом конце должно быть
На этом всё. Таким образом можно собирать любые сборки Nginx под свои потребности и размещать их в своих репозиториях. Например, с помощью Nexus, aptly, apt-offline и т.д.
Заметка получилась полноценной инструкцией с информацией, которую я в интернете не нашёл в готовом виде. Пришлось написать самому.
#debian #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
👍90👎1
Популярный вопрос к моим статьям и заметкам по настройке проксирования HTTP запросов с Nginx куда-то на backend. Нужно ли настраивать HTTPS и как вообще правильно это сделать. Поясню, о чём идёт речь.
Допустим, у вас есть какой-то сервер Nginx, работающий в режиме proxy_pass и раскидывающий соединения к разным доменам по разным серверам или контейнерам. Либо это один большой сайт с несколькими бэкендами. Очевидно, что соединение клиента с этим Nginx настроено по HTTPS. А от Nginx до остальных серверов нужно ли настраивать по HTTPS?
В общем случае я такие соединения пускаю по HTTP. Не вижу смысла использовать в этом случае шифрование, которое усложняет настройку, потому что надо сертификаты передавать на все сервера. Так оно ещё и ресурсы дополнительные тратит. На небольших нагрузках это не особо заметно, а вот на тысячах запросах в секунду будет заметно.
Исключение делаю тогда, когда проксируемое приложение или сервис начинают работать некорректно при такой схеме. Это бывает нередко. Приходится либо настройки сайта крутить, либо дополнительные заголовки добавлять, либо что-то ещё делать. Если простых способов решить проблемы нет, то приходится настраивать всю цепочку соединений по HTTPS.
Некоторые примеры подобных ошибок и их решения я публиковал на сайте (phpmyadmin, wordpress). Точно надо что-то делать с Bitrix, если проксируешь его по HTTP. Сейчас уже не помню, что именно. Не записывал. Каждый раз по месту разбираюсь.
А вы как считаете? Нужно ли в этом случае настраивать HTTPS, при условии, что запросы гуляют по нашей внутренней сети, которая считается доверенной? Если речь идёт про проксирование через сторонний сервис, тот же Cloudflare, или другую систему защиты от DDOS, то HTTPS я всегда настраиваю.
#nginx #webserver
Допустим, у вас есть какой-то сервер Nginx, работающий в режиме proxy_pass и раскидывающий соединения к разным доменам по разным серверам или контейнерам. Либо это один большой сайт с несколькими бэкендами. Очевидно, что соединение клиента с этим Nginx настроено по HTTPS. А от Nginx до остальных серверов нужно ли настраивать по HTTPS?
В общем случае я такие соединения пускаю по HTTP. Не вижу смысла использовать в этом случае шифрование, которое усложняет настройку, потому что надо сертификаты передавать на все сервера. Так оно ещё и ресурсы дополнительные тратит. На небольших нагрузках это не особо заметно, а вот на тысячах запросах в секунду будет заметно.
Исключение делаю тогда, когда проксируемое приложение или сервис начинают работать некорректно при такой схеме. Это бывает нередко. Приходится либо настройки сайта крутить, либо дополнительные заголовки добавлять, либо что-то ещё делать. Если простых способов решить проблемы нет, то приходится настраивать всю цепочку соединений по HTTPS.
Некоторые примеры подобных ошибок и их решения я публиковал на сайте (phpmyadmin, wordpress). Точно надо что-то делать с Bitrix, если проксируешь его по HTTP. Сейчас уже не помню, что именно. Не записывал. Каждый раз по месту разбираюсь.
А вы как считаете? Нужно ли в этом случае настраивать HTTPS, при условии, что запросы гуляют по нашей внутренней сети, которая считается доверенной? Если речь идёт про проксирование через сторонний сервис, тот же Cloudflare, или другую систему защиты от DDOS, то HTTPS я всегда настраиваю.
#nginx #webserver
👍54👎3
Я вчера рассказал, как собрать Nginx с модулем статистики vts. Расскажу теперь, как его настроить и собрать метрики в систему мониторинга Prometheus.
Для настройки статистики вам достаточно добавить в основной файл конфигурации
И в любой виртуальных хост ещё один location. Я обычно в default добавляю:
Теперь можно сходить по ip адресу сервера и посмотреть статистику прямо в браузере - http://10.20.1.56/status/. Сразу покажу ещё два важных и полезных урла: /status/format/json и /status/format/prometheus. По ним вы заберёте метрики в формате json или prometheus. Последняя ссылка нам будет нужна далее. Я покажу настройку мониторинга Nginx на примере Prometheus, так как это самый быстрый вариант. Имея все метрики в json формате, нетрудно и в Zabbix всё это закинуть через предобработку с помощью jsonpath, но времени побольше уйдёт.
Устанавливаем Prometheus. Нам нужен будет любой хост с Docker. Готовим конфиг, куда сразу добавим сервер с Nginx:
Это по сути стандартный конфиг, куда я добавил ещё один target nginx_vts. Запускаем Prometheus:
Идём на ip адрес хоста и порт 9090, где запущен Prometheus. Убеждаемся, что он работает, а в разделе Status -> Targets наш Endpoint nginx_vts доступен. Можете взять метрики со страницы /status/format/prometheus и подёргать их в Prometheus. Разбирать работу с ним не буду, так как это отдельная история.
Теперь ставим Grafana, можно на этот же хост с Prometheus:
Идём на 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.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.yamlglobal: scrape_interval: 5s evaluation_interval: 5srule_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
👍68👎1