Форк nginx без маразма: встречаем angie

 Оказывается, существует форк nginx: angie

Суть проблемы: nginx (почти) остановился в развитии, вкладывая основные силы в nginx plus, и масса нужных вещей, таких как предварительный опрос апстримов, толковая работа балансировки, статистика не в 3 строчки, нативные экспортеры в тот же node_exporter - извольте платить (есть несколько вариантов типа VTS, но разработчикам не нравится что их жадность обходят и не рекомендуют такое). 

ЦЕНА. Тут они вообще поехали крышей, "Стоимость Nginx Plus составляет от $2500 до $5000" - в год. На каждый сервер. пример (учесть что это за 2 года). Даже западные мастодонты типа оракла более адекватные. Вообще никому не советую брать плюс. Если выкинуть поддержку 24/7 - цена этой лицензии баксов 100 максимум, тогда можно рассмотреть.

Но. Теперь можно просто перейти на angie, и сразу видим

• Экспорт статистики в формате Prometheus с настраиваемыми шаблонами.

• Визуальная консоль мониторинга Console Light для наблюдения за сервером через браузер. Познакомиться с онлайн-примером: https://console.angie.software/

То есть минус VTS, полностью

• Режим привязки сессий, при котором все запросы в рамках одной сессии будут направляться на один и тот же проксируемый сервер.

• Механизм плавного ввода проксируемого сервера в работу после сбоя с помощью опции slow_start директивы server.

То есть уже большой кусок плюса - есть. Да, это далеко не всё (смотрим сайт про Энджи про), но именно мне перекинуты очень нужные вещи. При этом если открыть раздел динамические модули, есть и инструкция по переходу с nginx, и настройка prometheus и grafana.

К большому удивлению, даже vts есть из коробки, только непонятно зачем - это по сути экспортер prometheus.

nginx, fastcgi_pass и правильная настройка

 Если работаем через сокет, какой блок часто можно встретить?

    location ~ \.php$ {

        fastcgi_pass unix:/var/run/php-docker/php8.2-fpm.sock;

        fastcgi_index index.php;

        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;

        include fastcgi_params;

    }

Но есть нюанс: $realpath_root в данном случае сломан, вероятно потому что там должен быть реальный путь, но там пусто, файлы же в докере.. 

https://nginx.org/en/docs/http/ngx_http_core_module.html#variables

$realpath_root

an absolute pathname corresponding to the root or alias directive’s value for the current request, with all symbolic links resolved to real paths

Вариант - вписывать туда путь явно или через вспомогательную переменную. Хотя с $document_root тоже работает, если где-то выше выставлен root

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Но читаемость всё-равно будет не очень: всё-таки ожидается, что root локальный. Можно придумать свою переменную типа

set $root_in_docker /srv/.../ ;

и потом 

fastcgi_param SCRIPT_FILENAME $root_in_docker$fastcgi_script_name;

только не забыть потом

root $root_in_docker;

а то показывает дефолтную nginx страницу. Хотя и так не очень правильно, но - работает

Довольно полное описание для nginx vts

 https://nginx-extras.getpagespeed.com/modules/vts/

Пересборка nginx для поддержки модуля vts

https://dragonflybsd.blogspot.com/2019/03/nginx-prometheus-dashboard-grafana.html

 Вводные: есть сервер с ubuntu 16.04, которому нужно добавить модуль vts, стоит nginx=1.17.10

Решаем задачу.

Запускаем контейнер с нужной версией

docker run -ti --rm --name ubuntu16 ubuntu:16.04

Подготовка

apt update

apt install -y build-essential wget git sudo vim curl

# для удобства

export VERSION=1.17.10

cd /usr/local/src/

1) вариант через пакеты

Чем может грозить точка в конце доменного имени

Чем может грозить точка в конце доменного имени

Точку можно убрать такой конструкцией в блоке server:

if ($http_host ~ "\.$") { return 301 $scheme://$host$request_uri; }

И сразу замечание: если проверять конструкцию через curl, редиректа не будет.. потому что курл режет точку. А вот wget - нет. Бонусом - если нужно несколько редиректов сделать, вгет их сам сделает.

Бонус: часто есть желание вырезать несколько слэшей подряд, для этого нужны такие конструкции:

merge_slashes off;

if ($request_uri ~ "^(.*)/+$") { rewrite ^/(.*)/$ /$1 permanent; }

nginx redirect с исключениями

 Типовой редирект в nginx (нужен например для сео, чтобы одна страница не открывалась по двум урлам)

rewrite ^/(.*)/$ /$1 permanent;

Но иногда нужно пропустить отдельные пути, например /api/...

Оказывается, можно это сделать красиво и элегантно

rewrite ^(/(?!api/).*)/$ $1 permanent;

(но чаще слэши добавляются, читать про browsing context)

nginx-vts и актуализация

 Продолжение к

https://dragonflybsd.blogspot.com/2019/02/nginx.html

https://dragonflybsd.blogspot.com/2019/03/nginx-prometheus-dashboard-grafana.html

Сам vts так и заброшен, при этом на данный момент есть 332 форка, так что проект нужен людям.

https://github.com/vozlt/nginx-module-vts/network/members

 Лучше подобрать живую замену и переключиться.

Итак. Диагностика.

Запрашиваем

curl http://localhost/status/format/json

Если ответ 501 Not Implemented - или модуль не подключен, или не активирован в настройках.

То есть убеждаемся, что:

1) модуль собран и подключен

2) настройки примерно как в доке https://github.com/vozlt/nginx-module-vts#synopsis (в частности, может быть закомментирован vhost_traffic_status_zone)

Также, при наличии прометея и nginx-vts-exporter, можно запросить статистику

# curl 127.0.0.1:9913/metrics

Если вывод только такой

# HELP nginx_vts_exporter_build_info A metric with a constant '1' value labeled by version, revision, branch, and goversion from which nginx_vts_exporter was built.

# TYPE nginx_vts_exporter_build_info gauge

nginx_vts_exporter_build_info{branch="HEAD",goversion="go1.10",revision="8aa2881c7050d9b28f2312d7ce99d93458611d04",version="0.10.3"} 1

то опять же, статистика не отдаётся, при этом в его логах будет fetchHTTP failed HTTP status 501

nginx json logs

log_format json_combined escape=json '{ "created_at": "$msec", '

            '"remote_addr": "$remote_addr", '

            '"remote_user": "$remote_user", '

            '"request": "$request", '

            '"status": $status, '

            '"bytes_sent": $bytes_sent, '

            '"request_length": $request_length, '

            '"request_time": $request_time, '

            '"http_referrer": "$http_referer", '

            '"http_x_forwarded_for": "$http_x_forwarded_for", '

            '"http_user_agent": "$http_user_agent" }';

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

nginx ldap auth

Самый простой вариант ограничения доступа - через файл с паролями, как-то так

location / {

auth_basic "Restricted Area";

auth_basic_user_file auth/htpasswd;

proxy_pass ... }

Но порой требуется интеграция с ldap. Есть несколько вариантов

1. https://github.com/nginxinc/nginx-ldap-auth - отдельный сервис, можно запустить в докере, обращение к сервису идёт по http
2. Внешние модули:
   https://github.com/kvspb/nginx-auth-ldap
   https://github.com/sto/ngx_http_auth_pam_module
3. Штатный модуль http://nginx.org/en/docs/http/ngx_http_auth_request_module.html, но общение с ldap надо реализовать самому

Плюсы и минусы каждого подхода вполне понятны. Модуль - надо собирать под ту же версию, а если оно не умеет динамическим модулем то потом собирать пакет и выкатывать нашу сборку. Нужно отслеживать процесс обновления пакетов, чтобы не поставилась другая версия (решается через опцию Requires в spec файле).

Соберём пакет по п.1, при этом обязательно актвировать модуль ngx_http_auth_request_module (включено в официальных сборках), спека в комплекте
https://github.com/nginxinc/nginx-ldap-auth/tree/master/rpm

Мониторим nginx статистику (коды ответов итд) через prometheus, подключаем dashboard в grafana

Базовый (не Plus) nginx выдаёт крайне скупую статистику - сколько коннектов сейчас, сколько обработано. Чтобы получать больше информации, нужно или парсить access логи, или ставить модуль vts - их есть 2 вида
1) https://github.com/vozlt/nginx-module-vts
собирается динамическим модулем для nginx, причём версии nginx и модуля должны совпадать

2) https://github.com/knyar/nginx-lua-prometheus
требует lua, то есть или нужен nginx plus или openresty

Поставим первый модуль и подключим к нему экспортер vts в json
https://github.com/hnlq715/nginx-vts-exporter

UP: больше не нужно, nginx-vts научился экспортировать prometheus и json сам. Просто пишем server например на порт 9913 "как было" и всё. И там сразу

    location /metrics {
        vhost_traffic_status_display;
        vhost_traffic_status_display_format prometheus;
        vhost_traffic_status_bypass_stats on;
    }

Сборку и установку динамического модуля опустим (подробнее есть тут), только проверим что по адресу http://localhost/status есть отдача статистики модуля (а чтобы она появилась, читаем тут).
Теперь подключаем экспортер, и по адресу http://localhost:9913/metrics смотрим что появилась информация.
А теперь само подключение дашборда.
http://docs.grafana.org/reference/export_import/#importing-a-dashboard
Читаем как подключать, там достаточно просто id вставить и заполнить data source (prometheus), брать например тут
Nginx VTS Stats

Теперь переходим на http://(server):3000/dashboard/import и в Grafana.com Dashboard вставляем нужный нам id.

PS
Обращаю внимание, есть такой шлак
https://github.com/nginxinc/nginx-prometheus-exporter
Почему шлак? Потому что для чистого nginx он просто экспортирует stub_status, тот самый мизер.

Расширенная статистика nginx

Есть такой пакет, nginx-module-vts, даёт много полезной информации. Есть ссылка на офсайте в разделе NGINX 3rd Party Modules.
Но последний коммит был 30 июня 2018 и с тех пор автор не отвечает.

Есть другой модуль, nginx-lua-prometheus. Под debian есть инструкция через установку libnginx-mod-http-lua, но centos тут в пролёте, так что собираем первый.

ansible: официальный nginx role

https://www.nginx.com/blog/announcing-unified-ansible-role-nginx-nginx-plus/

(старая версия: https://www.nginx.com/blog/official-ansible-galaxy-nginx-roles-out-now/ )
Но это достаточно простая роль, из типового -- там нет upstream для раскидывания запросов на несколько бэкендов.

Как вариант, за основу можно тогда взять
https://github.com/geerlingguy/ansible-role-nginx

apache 2.4, nginx и 127.0.0.1 в логах

В старых версиях apache при проксировании запросов через nginx в логах апача светился 127.0.0.1, помогала установка mod_rpaf(2) или mod_realip. Но в 2.4 эти модули уже не нужны: в сам пакет входит mod_remoteip, и штатно активируется в /etc/httpd/conf.modules.d/00-base.conf
Но.. в логах всё-равно 127.0.0.1. Для полной настройки нужно создать файл /etc/httpd/conf.d/mod_remoteip.conf с содержимым

RemoteIPHeader X-Forwarded-For

RemoteIPInternalProxy 127.0.0.1/8

после этого в /etc/httpd/conf/httpd.conf ищем LogFormat и заменяем %h на %a (подробности в документации)

И не забыть выставить X-Forwarded-For со стороны nginx, разумеется.

Проверяем что нет ошибок
apachectl -S
и перечитываем

service httpd graceful

И чуть линков

https://trick77.com/apache2-2-4-logging-remote-ip-address-using-mod_remoteip/

https://talk.plesk.com/threads/bug-in-apache-2-4-centos-7-mod_remoteip.336737/

https://github.com/gnif/mod_rpaf/issues/27

https://serverfault.com/questions/616422/apache-mod-remoteip-and-access-logs

nginx gzip основные content-type

gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;

debian 7: сборка nginx в пакет

/etc/apt/sources.list.d/nginx.list:
deb http://nginx.org/packages/mainline/debian/ wheezy nginx
deb-src http://nginx.org/packages/mainline/debian/ wheezy nginx

сборка
cd /usr/src
apt-get source nginx && apt-get install build-dep nignx
cd nginx-(version)
cd debian
nano rules
правим правила configure
nano changelogs
добавить запись о новой версии (или просто поставить пакет на холд, чтобы его не обновило потом)
cd ../../
apt-get source -b nginx или из из папки исходников debuild -uc -us

nginx и обработка POST параметров

Есть набор переменных, $arg_* и массив $args, но туда попадают только переменные из строки запроса (прежде всего это будут GET запросы, но и у POST могут быть). А что делать, если надо обработать POST запросы? Зачем? Например, есть некий софт, который запрашивает файл через post, надо получить имя и отдать его с диска. Только ради этого писать обёртку на любом языке, которая требует ресурсов, обслуживания, обновлений, проверки что оно всегда работает итд? А если эта прослойка не успела ещё запуститься или просто упала, а файл уже запросили? Всего-то дел, получить имя из запроса...
Увы, штатного метода нет, но благодаря модулям со сторонними языками это реализуемо, правда пока найдено только 2 метода.

nginx+pootle

Pootle - это система на базе django, помогающая с переводом .po файлов на разные языки, в том числе отслеживание изменений.
Поскольку это питон, желательно использовать uWSGI и nginx.

nginx proxy_cache

syntax: proxy_cache [зона|off]
default: off
context: http, server, location

Директива задаёт зону для кэширования. Одна и та же зона может использоваться в нескольких местах. Параметр "off" запрещает кэширование, унаследованное с предыдущего уровня конфигурации.

proxy_cache_key
Ключ, по которому считается адрес кэшированной страницы

proxy_cache_path
где лежит кэш страниц

proxy_ignore_headers
Какие заголовки игнорировать, например Expires Cache-Control Set-Cookie

proxy_cache_use_stale
Когда доставать данные из кэша, например таймаут, 502 итд

Могут пригодиться proxy_hide_header, proxy_cache_bypass, proxy_no_cache

Но кэширование это только половина проблемы, кэши ещё надо чистить. В частности, есть proxy_cache_purge
Прозрачное кэширование в nginx для всех и каждого
Кеширующий прокси-сервер на nginx. Хитрая конфигурация
nginx + apache. Кеширование

Весьма полезная дока об особенностях

Подводные камни при использовании кэширования в nginx

http://wpebooks.com/wp-content/uploads/2011/11/network-nginx-proxy-cache-purge.pdf

apache, nginx: ограничение видов запросов

В apache через .htaccess, Limit и LimitExcept

Например

Only one Order directive per .htaccess file -- The last one overrides the previous ones.<br /> Similarly, any conflict between <limit> containers will result in the last one that applies being used.<br /> <br /> There is no need to enclose the Deny from's in a <limit> container, so I'm not sure why you're doing that. For example, PUTs and DELETEs will be allowed from your listed IP addresses with the code as-posted.<br /> <br /> Also, see <limitexcept>, which may be useful to you.<br /> <br /> I'd suggest:<br /> <br /> # Allow all to fetch robots.txt and custom 403 error page<br /> SetEnvIf Request_URI "^/(robots\.txt¦my_custom_403_page\.html)$" allow-it<br /> #<br /> Order Deny,Allow<br /> #<br /> # Allow all to fetch robots.txt and custom 403 error page<br /> <limit GET><br /> Allow from env=allow-it<br /> </Limit><br /> #<br /> # Deny all methods except for GET, HEAD, and POST (HEAD is implied by GET -- see documentation)<br /> <limitexcept GET POST><br /> Deny from all<br /> </LimitExcept><br /> #<br /> # Deny from various country's IP address ranges<br /> Deny from 41.204.224.0/19<br /> Deny from 41.205.160.0/19<br /> ...<br /> Deny from 213.166.160.0/19<br /> Deny from 213.181.64.0/19<br /> <br /> Replace the broken pipe character in the SetEnvIf directive above with a solid pipe character before use; Posting on this forum modifies the pipe characters.

http://www.webmasterworld.com/apache/3537686.htm
http://board.phpbuilder.com/showthread.php?10367096-.htaccess-configuration-(limit-get-allow-deny)-and-lt-Limit-GET-HEAD-POST-gt

nginx
синтаксис: limit_except метод ... { ... }
контекст: location
Ограничивает HTTP-методы, доступные внутри location. Параметр метод может быть одним из GET, HEAD, POST, PUT, DELETE, MKCOL, COPY, MOVE, OPTIONS, PROPFIND, PROPPATCH, LOCK, UNLOCK или PATCH. Если разрешён метод GET, то метод HEAD также будет разрешён. Доступ к остальным методам может быть ограничен при помощи директив модулей ngx_http_access_module и ngx_http_auth_basic_module:

limit_except GET {
    allow 192.168.1.0/32;
    deny  all;
}
Обратите внимание, что данное ограничение действует для всех методов, кроме GET и HEAD.
http://nginx.org/ru/docs/http/ngx_http_core_module.html

nginx: limit_req для POST

Штатно нельзя поставить ограничение на конкретный метод типа POST, только через Ж, увы.
Если просто написать
        location /login/ {
                if ($request_method = POST) {
                        limit_req zone=login; #burst=1;
                }

то при nginx -t будет ошибка
nginx: [emerg] "limit_req" directive is not allowed here in /etc/nginx/nginx.conf:48

Вариант через error_page

     if( $request_method = "POST")

     {

         return 402;

     }

     error_page 402 = @post;

   }

   location @post

   {

      limit_req ...

   }

http://mailman.nginx.org/pipermail/nginx-ru/2009-May/024672.html

Вариант через map
http://nginx.org/ru/docs/http/ngx_http_map_module.html
Основан на том, что если $is_post пуст, то ограничение не применится.

limit_req_zone $is_post zone=login:1m rate=1r/s;

map $request_method $is_post {
    POST $binary_remote_addr;
}

server {
...

limit_req zone=login; 

}

как-то так (пока не тестировалось, вечером постараюсь).