NGINX — самый популярный веб-сервер в мире, используемый на абсолютном большинстве сайтов. Его выбирают в том числе для работы высоконагруженных ресурсов, так как он может обработать более чем десять тысяч соединений одновременно.
Подробности — в видео и текстовой расшифровке ниже.
ps -ef --forest | grep nginx
Мастер-процесс запускается от суперпользователя и выполняет операции, требующие повышения прав, такие как:
Воркер-процессы слушают два вида сокетов:
https://tproger.ru/events/net-webinar-2021/?utm_source=in_text
Другие два процесса управляют содержимым кэша на жестком диске:
При правильно настроенном NGINX каждый воркер-процесс способен обработать сотни тысяч cоединений одновременно.
# global context
user nginx; ## Default: nobody
worker_processes 5; ## Default: 1
worker_rlimit_nofile 8192;
access_log /var/log/nginx/access.log main;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
events {
worker_connections 4096; ## Default: 1024
}
http {
# common http settings
sendfile on;
tcp_nopush on;
tcp_nodelay on;
gzip on;
server {
listen 80;
server_name example.com;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
location / {
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_pass http://127.0.0.1:8081;
}
}
# include directive
include /etc/nginx/conf.d/*.conf;
}
Все настройки называются директивами и представляют собой пары key-value. Директива с фигурными скобками называется контекстом. Вот список основных контекстов:
Особого внимания требует директива include. Указанное значение для этой директивы — это регулярное выражение, которое описывает файлы в директории с расширением .conf. NGINX при старте найдёт все файлы, подходящие под регулярное выражение, и вставит их содержимое в то место, где указана директива include. Это даёт возможность разложить конфигурацию NGINX по отдельным файлам.
http {
# ...
server {
listen 80;
server_name example.com;
location / {
root /var/www/example;
}
location ~ \.(woff|woff2)$ {
root /var/www/example/fonts;
}
location ~ \.(gif|jpg|png)$ {
root /var/www/example/images;
}
}
}
Чтобы сделать reverse proxy, создаём такой же контекст server. В нём создаём один контекст location, в котором указываем директиву proxy_pass и URL, куда проксировать запросы. Теперь NGINX будет проксировать все запросы на указанный URL.
http {
# ...
server {
listen 80;
server_name domain.com;
location / {
proxy_pass http://app.domain.com;
}
}
}
Добавим балансировку в конфигурацию reverse proxy. Внутри контекста http создаём контекст upstream и указываем адреса наших приложений. Внутри контекста location указываем директиву proxy_pass со значением имени контекста upstream. Теперь NGINX будет распределять запросы по двум серверам.
http {
# ...
upstream backend {
server app1.domain.com;
server app2.domain.com;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend;
}
}
}
Стратегия балансировки по умолчанию является round-robin — равномерным распределением. Можно указать стратегию least_conn, при которой NGINX будет отправлять запросы серверу, у которого меньше активных подключений. Это полезно, если серверы не одинаковые по своей мощности.
Источник статьи: https://tproger.ru/articles/video-osnovy-nginx-dlja-nachinajushhih-za-200-sekund/
Подробности — в видео и текстовой расшифровке ниже.
Как устроен NGINX
NGINX построен на базе неблокирующей событийно-ориентированной архитектуры. У него есть один мастер-процесс, несколько воркер-процессов и два процесса, управляющих кэшем. Чтобы это увидеть, достаточно выполнить команду ps с ключами:ps -ef --forest | grep nginx
Мастер-процесс запускается от суперпользователя и выполняет операции, требующие повышения прав, такие как:
- чтение конфигурации,
- открытие портов,
- создание новых процессов.
- обрабатывают сетевые соединения,
- читают и пишут данные на диск,
- общаются с бэкэнд-серверами.
Воркер-процессы слушают два вида сокетов:
- listener — для событий новых клиентов (запросов на соединение),
- connection — для событий, которые требуют обработки.
https://tproger.ru/events/net-webinar-2021/?utm_source=in_text
Другие два процесса управляют содержимым кэша на жестком диске:
- загрузчик кэша загружает данные в оперативную память, после чего процесс завершается,
- менеджер кэша периодически удаляет объекты, чтобы поддерживать объем кэша в рамках заданных ограничений.
При правильно настроенном NGINX каждый воркер-процесс способен обработать сотни тысяч cоединений одновременно.
Основы конфигурации NGINX
Общий конфигурационный файл NGINX выглядит следующим образом:# global context
user nginx; ## Default: nobody
worker_processes 5; ## Default: 1
worker_rlimit_nofile 8192;
access_log /var/log/nginx/access.log main;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
events {
worker_connections 4096; ## Default: 1024
}
http {
# common http settings
sendfile on;
tcp_nopush on;
tcp_nodelay on;
gzip on;
server {
listen 80;
server_name example.com;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
location / {
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_pass http://127.0.0.1:8081;
}
}
# include directive
include /etc/nginx/conf.d/*.conf;
}
Все настройки называются директивами и представляют собой пары key-value. Директива с фигурными скобками называется контекстом. Вот список основных контекстов:
- global — общие настройки,
- events — настройки обработки событий воркер-процессами,
- http — настройки http- и https-соединений,
- server — настройки виртуальных серверов,
- location — настройки обработки и поиска идентификатора запроса.
Особого внимания требует директива include. Указанное значение для этой директивы — это регулярное выражение, которое описывает файлы в директории с расширением .conf. NGINX при старте найдёт все файлы, подходящие под регулярное выражение, и вставит их содержимое в то место, где указана директива include. Это даёт возможность разложить конфигурацию NGINX по отдельным файлам.
Конфигурации для разных случаев использования
NGINX обычно используется в трёх случаях:- в качестве reverse proxy для проксирования запросов в бекэнд,
- как балансировщик запросов между серверами бекэнда,
- для отдачи статического контента.
http {
# ...
server {
listen 80;
server_name example.com;
location / {
root /var/www/example;
}
location ~ \.(woff|woff2)$ {
root /var/www/example/fonts;
}
location ~ \.(gif|jpg|png)$ {
root /var/www/example/images;
}
}
}
Чтобы сделать reverse proxy, создаём такой же контекст server. В нём создаём один контекст location, в котором указываем директиву proxy_pass и URL, куда проксировать запросы. Теперь NGINX будет проксировать все запросы на указанный URL.
http {
# ...
server {
listen 80;
server_name domain.com;
location / {
proxy_pass http://app.domain.com;
}
}
}
Добавим балансировку в конфигурацию reverse proxy. Внутри контекста http создаём контекст upstream и указываем адреса наших приложений. Внутри контекста location указываем директиву proxy_pass со значением имени контекста upstream. Теперь NGINX будет распределять запросы по двум серверам.
http {
# ...
upstream backend {
server app1.domain.com;
server app2.domain.com;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend;
}
}
}
Стратегия балансировки по умолчанию является round-robin — равномерным распределением. Можно указать стратегию least_conn, при которой NGINX будет отправлять запросы серверу, у которого меньше активных подключений. Это полезно, если серверы не одинаковые по своей мощности.
Источник статьи: https://tproger.ru/articles/video-osnovy-nginx-dlja-nachinajushhih-za-200-sekund/