​​Ещё один способ организовать мониторинг Nginx - использовать prometheus-nginxlog-exporter. Принцип его действия следующий. В режиме реального времени анализируется лог Nginx. Распознанные метрики из него передаются в Prometheus.

Основная сложность этого способа - настроить соответствие лога nginx и шаблона экспортера. Я сказал "сложность" условно. Просто это единственное, что нужно учесть при настройке, остальное делается на автомате по инструкции. Реально никакой проблемы нет. Формат шаблона у nginxlog-exporter очень простой. Подогнать его под свой лог не проблема. Это не настройка grok фильтра, как у Logstash. Там придётся повозиться, прежде чем получится рабочий вариант.

В целом, использовать Nginxlog-exporter очень просто. Запустить можно сразу в Docker или установить из deb или rpm пакета. В качестве параметров запуска достаточно указать путь к конфигу службы и к логу Nginx. В репозитории есть все примеры.

Дальше всё как обычно. Метрики уходят в Prometheus, далее визуализация с помощью Grafana. В публичном доступе есть один актуальный дашборд, написанный конкретно под prometheus-nginxlog-exporter.

Исходники - https://github.com/martin-helmich/prometheus-nginxlog-exporter

#nginx #webserver

При настройке любой службы в Linux, которая пишет логи, надо обязательно следить за их ротацией. Типовая ситуация, когда логи забивают всё свободное место на диске, и сервак встаёт колом. Ротировать логи можно встроенной утилитой Linux - logrotate.

Для логов веб сайтов полезно включать ротацию не по заданному расписанию, а по размеру лог файла. Иногда случаются набеги ботов, которые могут раздуть логи до огромных размеров за несколько минут. Дождаться суточной ротации можно и не успеть. В этом случае полезно использовать следующий параметр logrotate:
size = 100M

Обычно люди ставят его и ожидают, что теперь логи будут автоматически ротироваться при достижении ими размера в 100 мегабайт. Ага, сейчас. Ничего подобного не произойдёт. По умолчанию logrotate запускается раз в сутки, поэтому он при всём желании не сможет следить за размером файла и ротировать его чаще, чем раз в сутки. Обычно за его запуск отвечает скрипт в директории /etc/cron.daily/logrotate.

Для того, чтобы logrotate мог проверять размер лог файла хотя бы раз в час, скрипт запуска надо перенести в директорию /etc/cron.hourly. А для более частой проверки, добавить его напрямую в cron с нужным интервалом запуска. Например, раз в 5 минут.

Допустим вы всё это сделали, но логи всё равно не будут ротироваться при достижении заданного размера. Понять, в чем же теперь проблема, не так просто. При запуске logrotate вы не увидите никаких ошибок. Он просто ничего не будет делать. Понять, в чём проблема, можно только при запуске в режиме отладки. Там вы увидите ошибку, если в этот день ротация уже была хотя бы раз.
destination /var/log/nginx/access.log.20220426.gz already exists, skipping rotation

Смысл тут в том, что logrotate сегодня уже произвел ротацию и создал архив лога с определенным именем и второй раз такой же файл он сделать не может. А маска имени файла при создании настроена в формате %Y%m%d. За эту маску отвечает параметр в /etc/logrotate.conf:
dateext

Самый простой вариант - это просто закомментировать этот параметр, тогда все архивы логов будут иметь следующую маску в файлах:
access.log.1.gz
access.log.2.gz
access.log.3.gz

Если же вам хочется сохранить исходный формат лога для всех файлов, а для тех, что ротируются по размеру, настроить другую маску имени, используйте дополнительный параметр:
dateformat -%Y-%m-%d_%H-%s

Формат имени архивного лога будет access.log.2022-04-26_15-1566819154.gz. Имена больше не будут дублироваться и logrotate сможет корректно запускать ротацию при достижении указанного размера файла.

Таким образом, чтобы настроить ротацию лог файла по достижении определенного размера, вам нужно:

1️⃣ Запускать через cron logrotate с достаточно высокой периодичностью, например раз в час или чаще.
2️⃣ Настроить маску файла для архива лога, чтобы она была уникальной в каждый момент запуска logrotate.

#logrotate #nginx #webserver

Предлагаю вашему вниманию некоторые изменения стандартного конфига Nginx, которые я лично выполняю. К каждому параметру сделаю небольшое пояснение.

▪ worker_connections 8192;
Количество соединений для одного рабочего процесса. Повышать следует в зависимости от производительности сервера, но дефолтные значения я в любом случае увеличиваю.

▪ worker_rlimit_nofile 65536;
Параметр указывает, сколько файловых дескрипторов будет использовать Nginx. На каждое соединение надо выделять по два дескриптора: один на соединение с клиентом, второй на открытие файла. Число соединений = worker_connections * worker_processes.

▪ pcre_jit on;
Использование PCRE JIT способно существенно ускорить обработку регулярных выражений.

▪ multi_accept on;
Позволяет рабочему процессу сразу принять все новые соединения. Иначе он их будет принимать по одному.

▪ sendfile on; 
Параметр активирует передачу данных между файловыми дескрипторами средствами ядра ОС. Это ускоряет процесс и экономит ресурсы.

▪ tcp_nopush on;
tcp_nodelay on;
Параметры ускоряют передачу данных HTTP запросов.

▪ reset_timedout_connection on;
Параметр разрешает сброс соединений по таймауту.

▪ server_tokens off;
Отключите server_tokens, чтобы nginx не показывал свою версию.

▪ ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
Отключите старые версии ssl, а можно и tls1, tls1.1. Сейчас по умолчанию поддерживаются версии tls 1.2 и 1.3. Остальные считаются устаревшими.

▪ log_format
Я обычно добавляю дополнительные поля в стандартный формат логов. Как минимум rt=$request_time и ut=$upstream_response_time. Это позволяет мониторить время ответа бэкендов. Отклонение от стандартных логов приводит к тому, что их перестают парсить стандартные шаблоны различного софта. Так что изменяйте на свой страх и риск. Я это делаю там, где потом и шаблоны редактирую сам.

▪ client_max_body_size 10m;
Задаёт максимально допустимый размер тела запроса клиента. Дефолтное значение в 1m часто недостаточно.

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

📌 В завершении несколько полезных ссылок на мои материалы по теме Nginx:
- Подробная установка и настройка Nginx с примерами
- Автоматическое тестирование конфигурации Nginx
- Правильный redirect 301 для SEO в Nginx
- Nginx в качестве балансировщика нагрузки
- Проксирование запросов в nginx с помощью proxy_pass
- Сборка rpm пакета nginx с дополнительными модулями

 📌 Другие полезные ссылки:
- Генерация конфигов Nginx от DigitalOcen
- SSL Configuration Generator
- Проверка конфигурации Nginx

Пост достоин того, чтобы отправиться в закладки.

#nginx

​​🛡 Хочу поделиться с вами продуктом на базе Nginx, который мне понравился своей простотой и удобством. Речь пойдёт про Bunkerweb, который реализует в том числе функционал WAF (Web Application Firewall). Это собранный Docker контейнер с Nginx внутри и кучей дополнительного функционала для обеспечения безопасности.

Bunkerweb может работать как непосредственно локальный веб сервер, так и в режиме reverse proxy. Большая часть функционала реализована штатными средствами Nginx и модулями к нему. В качестве WAF используется ModSecurity, для защиты от ботов интеграция с различными каптчами.

📌 Для настройки есть мастер создания конфигурации. Оценить функционал и основные возможности проще всего через него, а не через просмотр описания или доков. Там сразу понятно, что он умеет и как настраивается. Перечислю основные фишки:
◽ есть встроенный веб интерфейс для управления (видео с демонстрацией)
◽ поддержка плагинов (уже есть интеграции с CrowdSec, ClamAV, Discord, Slack, VirusTotal)
◽ WAF на базе ModSecurity и набора правил OWASP
◽ распознавание ботов, их блокировка или показ каптчи
◽ блок ip по странам или внешним списками
◽ поддержка сертификатов let's encrypt

Весь функционал подробно описан в документации. Запускается Bunkerweb в Docker, Kubernetes, локально с ручной установкой или через Ansible. Доступны, по сути, все возможные способы, кому что ближе и удобнее.

Проект оставил очень хорошее впечатление. Он хорошо документирован, описан, понятно сделан, продуман. Мне показалось, что это хорошее решение не только с точки зрения безопасности, но и просто установки и управления Nginx. Можно через конструктор собрать набор опций, запустить Bunkerweb, а потом посмотреть в конфиге, как всё это реализовано. Так как всё собрано на базе open source продуктов, разобраться не трудно. При желании, можно что-то в свои наработки утащить.

Можно рассматривать этот продукт как панель управления для Nginx с базовым набором правил безопасности. Это если его просто с дефолтными настройками запустить. А дальше уже при желании можно наращивать функционал.

Сайт - https://docs.bunkerweb.io
Исходники - https://github.com/bunkerity/bunkerweb
Demo - https://demo.bunkerweb.io/

#waf #security #nginx

​​Недавно попал в любопытную панель управления веб серверами. Интерфейс явно напоминал о том, что где-то я его уже видел. Довольно быстро через поиск понял, в чём тут дело. Уже давно я писал про веб панель для управления haproxy - haproxy-wi. Проект с тех пор активно развивается, сменил имя, нарастил функционал и обзавёлся платной версией.

Теперь он называется Roxy-WI. У него, судя по всему, русскоязычные разработчики. Как минимум от двоих есть целая серия статей на хабре про этот продукт (тут и тут). К сожалению, с появлением платной версии, исчезли готовые пакеты для автоматической установки. Это не является какой-то большой проблемой, потому что по своей сути это обычное веб приложение, написанное на Python. Работает на базе Apache. В репозитории есть все конфиги, так что их просто нужно будет вручную разложить по нужным местам и самому установить зависимости. Подробная инструкция прилагается.

Roxy-WI умеет управлять настройками HAProxy, Apache, Nginx, Keepalived, Grafana, Prometheus, а так же HAProxy и Nginx exporters от него. Это такое комплексное решение по установке (указанные программы он умеет устанавливать самостоятельно, подключаясь по SSH) и управлению веб или прокси серверами.

Помимо непосредственно настройки, в Roxy-WI можно просматривать логи, настраивать WAF (Web Application Firewall), следить за сервисами с помощью мониторинга и оповещений. Есть интеграция с Fail2Ban.

Продукт функциональный и интересный. Если у вас задача поднять прокси сервер под HAProxy и для вас это не профильное направление, то можете воспользоваться панелью. Там есть в том числе и генератор конфигов под разные задачи.

Посмотреть, как всё это выглядит на практике, можно в ютубе на канале продукта:
⇨ https://www.youtube.com/@roxy-wi2201/videos
Там много примеров того или иного функционала. Или воспользоваться публичным демо:
⇨ https://demo.roxy-wi.org
Учётка - admin / admin. Панелька реально приятно и удобно смотрится. Оцените, как выглядит просмотр логов или редактор конфигов.

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

⇨ Сайт / Исходники

#webserver #nginx #haproxy

​​На днях писал про CIS. Решил не откладывать задачу и проработать документ с рекомендациями по Nginx. Делюсь с вами краткой выжимкой. Я буду брать более ли менее актуальные рекомендации для среднетиповых веб серверов. Например, отключать все лишние модули и делать свою сборку в обход готовых пакетов я не вижу для себя смыла.

📌Проверяем наличие настройки autoindex. В большинстве случаев она не нужна. С её помощью работает автоматический обзор содержимого директорий, если в них напрямую зайти, минуя конкретный или индексный файл.
# egrep -i '^\s*autoindex\s+' /etc/nginx/nginx.conf 
# egrep -i '^\s*autoindex\s+' /etc/nginx/conf.d/*
# egrep -i '^\s*autoindex\s+' /etc/nginx/sites-available/*
Не должно быть настройки autoindex on. Если увидите, отключите.

📌Обращения на несуществующие домены или по ip адресу лучше сразу отклонять. По умолчанию отдаётся приветственная страница. Проверить можно так:
# curl -k -v https://127.0.0.1 -H 'Host: invalid.host.com'
Если в ответ показывает приветственную страницу или что-то отличное от 404, то надо добавить в самую первую секцию server следующие настройки:
server { 
return 404;
}
Можно просто удалить конфиг с дефолтным хостом, а приведённый код добавить в основной nginx.conf. Тогда это точно будет первая секция server. В остальных секциях server везде должны быть явно указаны server_name.

📌Параметр keep-alive timeout имеет смысл сделать 10 секунд или меньше. По умолчанию он не указан и им управляет подключающийся.
keepalive_timeout 10;
То же самое имеет смысл сделать для send_timeout.
send_timeout 10;

Скрываем версию сервера параметром server_tokens. Проверяем так:
# curl -I 127.0.0.1 | grep -i server
Отключаем:
server {
...
server_tokens    off;
... 
}

📌Дефолтные страницы index.html и error page лучше отредактировать, удалив всё лишнее. Обычно они хранятся в директориях /usr/share/nginx/html или /var/www/html.

📌Запрещаем доступ к скрытым файлам и директориям, начинающимся с точки. Для этого в добавляем в самое начало виртуального хоста location:
location ~ /\. { deny all; return 404; }
Если нужно исключение, например для директории .well-known, которую использует let's encrypt для выпуска сертификатов, то добавьте его выше предыдущего правила.
location ~ /\.well-known\/acme-challenge { allow all; }

📌Скрываем proxy headers. Добавляем в location:
location /docs {
....
proxy_hide_header X-Powered-By; 
proxy_hide_header Server;
.... 
}

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

📌Настраиваем передачу реального IP адреса клиента в режиме работы Nginx в качестве прокси.
server {
...
location / {
proxy_pass 127.0.0.1:8080);
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
}
}

📌Ограничиваем версию TLS только актуальными 1.2 и 1.3. Если используется режим проксирования, то надо убедиться, что эти версии совпадают на прокси и на сервере. Если не уверены, что все ваши клиенты используют современные версии TLS, то оставьте поддержку более старых, но это не рекомендуется. Настройка для секции http в nginx.conf
ssl_protocols TLSv1.2 TLSv1.3;

📌Настраиваем ssl_ciphers. Список нужно уточнять, вот пример из документа CIS:
ssl_ciphers ALL:!EXP:!NULL:!ADH:!LOW:!SSLv2:!SSLv3:!MD5:!RC4;

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

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

#cis #nginx #security

​​Обработал несколько материалов на тему Nginx и подготовил универсальный конфиг с общими параметрами и некоторыми примерами настроек для виртуального хоста. Перед применением конфиг обязательно правится под ваш сервер. Нужно сделать некоторые подготовительные действия, чтобы на нём завестись. Как минимум, получить сертификаты, создать нужные директории, сгенерировать dhparam.pem, какие-то пути подправить и т.д.

✅ https://pastebin.com/dHscS0Vi

Это компиляция из моих же настроек в постах про Nginx (1, 2). Настройки TLS частично подсмотрел в генераторе от Mozilla:
⇨ https://ssl-config.mozilla.org/

Также кое что посмотрел в генераторе конфигов от Digital Ocean:
⇨ https://www.digitalocean.com/community/tools/nginx

Проверил всё это дело на nginx playground:
⇨ https://nginx-playground.wizardzines.com

А также с помощью анализатора конфигов Nginx от Яндекса gixy:
⇨ https://github.com/yandex/gixy

Настройки TLS проверил тут:
⇨ https://www.ssllabs.com/ssltest

Параметры моего конфига поддерживают работу TLS 1.0 и 1.1. За это дают большой штраф. Можете отключить эти протоколы и соответствующие шифры, но тогда, к примеру, отвалятся все старые андроиды версии 4 и ниже. Смотрите сами, нужна ли вам поддержка максимального числа оборудования, или важнее соответствие современным протоколам безопасности.

Конфиг получился не сферическим конём в вакууме, а рабочим вариантом. Я сам постоянно его использую, поэтому обновил свой рабочий шаблон, которым сам буду пользоваться.

📌 В завершении несколько полезных ссылок на мои материалы по теме Nginx:
◽ Подробная установка и настройка Nginx с примерами
◽ Автоматическое тестирование конфигурации Nginx
◽ Правильный redirect 301 для SEO в Nginx
◽ Nginx в качестве балансировщика нагрузки
◽ Проксирование запросов в nginx с помощью proxy_pass
◽ Сборка rpm пакета nginx с дополнительными модулями

#nginx #webserver

Ещё один пример защиты веб сервера с помощью fail2ban. На этот раз пример будет более универсальный, который защитит не только от брута, но и от любых множественных подключений к серверу.

Для этого нам понадобятся модули nginx limit_req и limit_conn. С их помощью можно ограничить скорость обработки запросов с одного IP адреса. Для этого в основной конфигурации nginx, в разделе http, нужно добавить одну или несколько зон с максимальной скоростью обработки запросов или количеством числа соединений с одного IP. Я обычно использую несколько зон, чаще всего четыре. Одна для общего ограничения соединений, вторая для статики, третья для легких динамических запросов (обычные php страницы), четвёртая для тяжёлых динамических запросов (аутентификация, поиск, формирование большого каталога и т.д.).

Выглядят настройки примерно так:

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_req_zone $binary_remote_addr zone=lim_50r:10m rate=50r/s;
limit_req_zone $binary_remote_addr zone=lim_10r:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=lim_3r:10m rate=3r/s;

Зону лучше называть по разрешённому лимиту, чтобы проще было использовать в настройках. Далее идём в конфиг виртуального хоста и там расставляем зоны в общей настройке server и разных locations. Примерно так:

server {
...
limit_conn perip 100;
...

# поиск
location /?s= {
limit_req zone=lim_3r burst=5 nodelay;
...
}

# динамика
location ~ \.php$ {
limit_req zone=lim_10r burst=15 nodelay;
...
}

# всё остальное
location / {
limit_req zone=lim_50r burst=65 nodelay;
...
}
}

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

Сработанные ограничения будут отображаться в error.log nginx. Его мы и будем проверять с помощью fail2ban. Для этого добавляем в директорию /etc/fail2ban/filter.d два конфига.

nginx-limit-conn.conf:
[Definition]
failregex = ^\s*\[[a-z]+\] \d+#\d+: \*\d+ limiting connections by zone.*client: <HOST>
ignoreregex =

nginx-limit-req.conf:
[Definition]
ngx_limit_req_zones = [^"]+
failregex = ^\s*\[[a-z]+\] \d+#\d+: \*\d+ limiting requests, excess: [\d\.]+ by zone "(?:%(ngx_limit_req_zones)s)", client: <HOST>,
ignoreregex = 
datepattern = {^LN-BEG}

И в /etc/fail2ban/jail.d два файла конфигурации:

nginx-limit-conn.conf
[nginx-limit-conn]
enabled = true
filter = nginx-limit-conn
port = http
action = iptables-multiport[name=ConnLimit, port="http,https", protocol=tcp]
logpath = /web/sites/*/logs/error.log
bantime = 3600
maxretry = 20

nginx-limit-req.conf
[nginx-limit-req]
enabled = true
filter = nginx-limit-req
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]
logpath = /web/sites/*/logs/error.log
bantime = 3600
maxretry = 10

Теперь нарушители лимитов будут отправляться в бан. При этом не так критично разрастание логов, так как error лог редко растёт быстро, даже если вас ддосят. Но всё равно не нужно забывать про его ротацию.

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

Есть более простой в плане нагрузки способ блокировать тех, кто открывает слишком много соединений. Использовать системную информацию о подключениях, например, с помощью netstat и если превышен лимит, отправлять IP в бан. Я не очень люблю этот способ и редко использую, так как нет гибкой настройки по сайтам, урлам и т.д. Его стоит использовать, если вас ддосят и вам надо максимально быстро и дёшево по ресурсам блокировать атакующих. Иногда это помогает, если ддос не очень сильный и провайдер вас не отключает. Если интересно посмотреть эту реализацию, то напишите в комментах, я расскажу с примером.

#security #fail2ban #webserver #nginx

​​На днях в комментариях подсказали полезный ресурс для проверки настроек безопасности в заголовках веб сервера — securityheaders.com. Для теста проверил свой сайт, получилась неутешительная картинка. Многие полезные с точки зрения безопасности заголовки не настроены. Стал разбираться.

Ключевым заголовком в плане обеспечения безопасности является CSP (Content Security Policy). С его помощью можно указать, с каких доменов может загружаться контент при просмотре сайта. Значение этого заголовка передаётся браузеру. Если он видит, что какие-то скрипты или прочие объекты пытаются загрузится с домена, который не разрешён в CSP, то блокирует их. Подобная защита, к примеру, помогает от XSS (cross site scripting) атак.

На деле оказалось, что конкретно мне настроить CSP будет очень непросто. Сначала бодро взялся за написание правил, потом приуныл. У меня крутится реклама от Яндекса, счётчики от Яндекс Метрики и Google Analytics. Чтобы все их корректно разрешить, надо прилично заморочиться, чтобы ничего не упустить. Вот пример настроек для метрики и рекламной сети. Ошибку можно сразу не заметить, а это приведёт к некорректному сбору статистики или ошибок в ней. А у кого-то ещё и шрифты внешние грузятся, библиотеки. Надо всё аккуратно проверять и настраивать.

Пока отложил вопрос. Конкретно для моего блога это некритично, но если у вас коммерческий сайт, то рекомендую заморочить и всё аккуратно настроить. По остальным заголовкам в сервисе есть описание, можно настроить. Но они уже не так важны и настраиваются проще.

У меня в итоге получилось вот так:

add_header X-Frame-Options "SAMEORIGIN";
add_header Strict-Transport-Security max-age=15768000;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "origin-when-cross-origin";
add_header Permissions-Policy "geolocation=(),midi=(),sync-xhr=(),\
microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=*,payment=()";

#nginx #webserver

​​▶️ В интернете масса статей и видео по настройке одного из самых популярных веб серверов Nginx. Разработчики в какой-то момент озаботились тем, чтобы самим выпустить канонические руководства, по которым стоит настраивать их веб сервер. Эти руководства они поддерживают и по мере необходимости обновляют.

Если вы отдаёте предпочтение информации от вендора, то для поиска инструкций разумнее обратиться на его официальный канал. К тому же все основные темы они вынесли в отдельный плейлист:

⇨ https://youtube.com/playlist?list=PLGz_X9w9raXf748bzuGOV6XJv7q3wLxhZ

🎓 Список тем из него:

◽How to define and publish APIs using NGINX Controller
◽How to Set Quotas with NGINX Plus
◽How to Set Up SSL with NGINX
◽How to Serve Static Content
◽How to Install NGINX on Debian and Ubuntu
◽How to create an API Dev Portal using NGINX Controller
◽Key Files, Commands, and Directories with NGINX
◽How to Install NGINX on CentOS and Red Hat
◽How to Install NGINX Amplify on Linux
◽NGINX Unit: From Zero to Lift Off
◽Dynamic SSL Key Management with NGINX
◽Getting Started with NGINX Service Mesh
◽NGINX as an API Gateway
◽How to Configure NGINX Plus as a WAF Using NGINX App Protect
◽NGINX App Protect Denial of Service (DoS) Overview
◽Configure NGINX as a Reverse Proxy
◽How to Streamline API Operations with API Connectivity Manager

Все видео на английском. Если не знаете его, можно спокойно всё понять через переводчик в режиме реального времени от Яндекса, или с английскими субтитрами. Часть тем актуальна для только версии Plus.

#nginx #видео #обучение