Веб-серверы

Apache

Для обеспечения работы веб-сервера используются следующие программные средства:

Apache HTTP-сервер – веб-сервер с открытым исходным кодом;
PHP – скриптовый язык программирования, созданный для генерации HTML-страниц на веб-сервере и работы с БД;
MySQL – свободная система управления базами данных (СУБД);
PhpMyAdmin – инструмент для визуальной работы с БД MySQL.

Установка Apache

Для установки веб-сервера Apache из консоли нужно установить один пакет, который по зависимостям установит еще порядка 40 пакетов, необходимых для нормальной и полноценной работы сервера.

Основные команды для работы с веб-сервером Apache:

установка пакетов с Apache:

sudo dnf install apache-base

запуск сервера Apache:

sudo systemctl start httpd

добавление сервера Apache в автозапуск при старте Системы:

sudo systemctl enable httpd

остановка сервера:

sudo systemctl stop httpd

После каких-либо изменений в конфигурационных файлах сервер следует перезапустить:

sudo systemctl restart httpd

Установка PHP

Для работы с PHP нужно установить всего 3 пакета, выполнив команду:

sudo dnf install php php-mysql apache-mod_php

Установка MySQL

Для установки MySQL-сервера нужно выполнить команду:

sudo dnf install mysql-server

Запуск сервера MySQL:

sudo systemctl start mysqld

Включение запуска сервера при загрузке компьютера:

sudo systemctl enable mysqld

Перезапуск сервера:

sudo systemctl restart mysqld

Установка PhpMyAdmin

Перед установкой PhpMyAdmin необходимо проверить корректность предыдущих установок и настроек.

Для безопасности работы с БД MySQL нужно поменять пароль администратора:

mysqladmin -u root password новый_пароль

Сначала необходимо запустить сервера в правильной последовательности:

sudo systemctl start mysqld
sudo systemctl start httpd

Теперь можно проверить работоспособность локального сервера, для чего набрать в адресной строке браузера адрес http://localhost/.

Если все прошло удачно, то страница браузера будет отображать сообщение с текстом об успешной работе (рисунок 21).

Рисунок 21 – Окно браузера при успешной установке сервера

Затем нужно проверить работу PHP, для этого в папке /var/www/html создать файл info.php с одной строчкой:

<?php phpinfo(); ?>

Теперь можно проверить работоспособность PHP на локальном сервере, набрав в адресной строке браузера адрес http://localhost/info.php. Окно браузера должно выглядеть так, как показано ниже (рисунок 22).

Рисунок 22 – Проверка работоспособности PHP

Далее следует прокрутить эту страницу ниже и убедиться в работоспособности MySQL. В разделе MySQL должен быть установлен статус Enabled (рисунок 23).

Рисунок 23 – Проверка статуса MySQL

После всех проверок установленных программных средств можно установить PhpMyAdmin командой:

sudo dnf install phpmyadmin

Затем необходимо заменить содержимое установленного по умолчанию файла /etc/httpd/conf/webapps.d/phpmyadmin.conf на следующее:

Alias /phpmyadmin /usr/share/phpmyadmin
<Directory /usr/share/phpmyadmin>
Options none
AllowOverride Limit
Require all granted
</Directory>

Чтобы проверить работу PhpMyAdmin, нужно набрать в адресной строке браузера адрес http://localhost/phpmyadmin/.

Если все сделано правильно, то в браузере появится примерное содержание, как ниже (рисунок 24).

Рисунок 24 – Окно входа в PhpMyAdmin

Веб-сервер Nginx

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

Возможности сервера Nginx:

обработка статических запросов, индексных файлов; автоматическое формирование списка файлов в директориях; кеширование дескрипторов открытых файлов;
высокопроизводительное обратное проксирование с возможностью кеширования; поддержка балансировки нагрузки и механизмов отказоустойчивости;
поддержка FastCGI, uwsgi, SCGI и memcached-серверов с кешированием, возможностью распределения нагрузки и организации отказоустойчивости;
модульная архитектура, включая фильтры обработки контента (сжатие gzip, поддержка byte-ranges, chunked-ответов, XSLT-фильтров, SSI-фильтров, преобразование изображений);
параллельная обработка подзапросов внутри одной страницы через SSI-фильтр с возможностью передачи запросов к сторонним FastCGI- или прокси-серверам;
поддержка SSL и расширения TLS SNI;
конфигурация виртуальных серверов по имени хоста или IP-адресу;
поддержка keep-alive- и pipelined-соединений;
гибкая система конфигурации;
возможность изменения настроек и обновления исполняемого файла без прерывания обслуживания клиентов;
настройка форматов журналов, буферизация и ротация логов;
отображение специальных страниц ошибок (3xx–5xx);
модуль rewrite с поддержкой регулярных выражений для перенаправлений;
ограничение доступа по IP-адресам, HTTP Basic-аутентификация;
проверка заголовка HTTP referer;
поддержка методов HTTP: PUT, DELETE, MKCOL, COPY, MOVE;
потоковая передача мультимедиа (FLV и MP4);
ограничение скорости ответов и числа одновременных подключений;
встроенная поддержка Perl-скриптов.

Nginx может использоваться как прокси-сервер для почтовых протоколов с проверкой пользователей через внешний HTTP-сервер аутентификации. Поддерживаются протоколы POP3, IMAP и SMTP с методами авторизации USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5. Также реализована поддержка SSL, STARTTLS и STLS для организации защищённых соединений при работе с почтовыми сервисами.

Архитектура Nginx построена на модели одного главного и нескольких рабочих процессов, где рабочие процессы запускаются под непривилегированным пользователем. Для обработки большого количества одновременных соединений используются высокопроизводительные механизмы событий, включая kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7+), event ports (Solaris 10), select и poll.

В Nginx поддерживаются дополнительные функции событийных моделей, например: EV_CLEAR, EV_DISABLE, NOTE_LOWAT, EV_EOF и другие; реализована поддержка механизмов передачи файлов (sendfile, sendfile64, sendfilev), асинхронного ввода-вывода (AIO) и режимов DIRECTIO; кроме того, возможно применение accept-фильтров (FreeBSD 4.1+, NetBSD 5.0+) и TCP_DEFER_ACCEPT (Linux 2.4+).

Сервер Nginx демонстрирует низкое потребление памяти (порядка 2,5 МБ на 10000 неактивных keep-alive-соединений) и минимизацию операций копирования данных при передаче запросов, что обеспечивает его высокую производительность и масштабируемость.

Официальный сайт проекта: https://nginx.org/ru/.

Установка и структура файлов Nginx

Для установки веб-сервера Nginx необходимо выполнить следующую команду:

sudo dnf install nginx

После установки требуется запустить сервис Nginx:

sudo systemctl start nginx.service

Чтобы обеспечить автоматический запуск сервиса Nginx при старте ОС, необходимо выполнить команду:

sudo systemctl enable nginx.service

Структура файлов и директорий Nginx включает в себя:

Каталог веб-контента /usr/share/nginx/html. Данная директория содержит веб-контент, доступный по умолчанию сразу после установки Nginx. В неё входит демонстрационная страница, которую выводит установленный по умолчанию веб-сервер. При необходимости размещения собственного контента или веб-приложений следует отредактировать конфигурацию и указать другую директорию.
Каталоги конфигураций сервера:
- /etc/nginx/ – основной каталог, содержащий все файлы конфигурации Nginx;
- /etc/nginx/nginx.conf – главный конфигурационный файл, определяющий глобальные параметры работы веб-сервера. Для изменения параметров, применяемых ко всем виртуальным хостам, необходимо вносить правки именно в этот файл;
- /etc/nginx/conf.d/ – каталог, содержащий конфигурационные файлы для отдельных виртуальных хостов. Рекомендуется создавать для каждого сайта отдельный конфигурационный файл с расширением .conf, совпадающий по названию с доменным именем, например example.ru.conf;
Каталоги журналов работы:
- /var/log/nginx/access.log – все запросы к веб-серверу фиксируются в данном файле, если в конфигурации Nginx не указано иное;
- /var/log/nginx/error.log – все ошибки и сообщения о сбоях работы веб-сервера регистрируются в этом журнале.

Настройка Nginx

Основным конфигурационным файлом Nginx является /etc/nginx/nginx.conf. При необходимости изменения настроек следует открыть данный файл и внести требуемые параметры.

После запуска сервиса Nginx рекомендуется проверить его работоспособность, открыв веб-браузер и введя адрес:

http://<IP-адрес>

где <IP-адрес> — это адрес сервера, на котором запущен Nginx.

Ниже приведён пример базовой конфигурации /etc/nginx/nginx.conf по умолчанию:

#user  nobody;
worker_processes  1;
#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;
#pid        logs/nginx.pid;
events {
worker_connections  1024;
}
http {
include       mime.types;
default_type  application/octet-stream;
#log_format  main  '$remote_addr - $remote_user\ [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer"\ '
'"$http_user_agent"\ "$http_x_forwarded_for"';
#access_log  logs/access.log  main;
sendfile        on;
#tcp_nopush     on;
#keepalive_timeout  0;
keepalive_timeout  65;
#gzip  on;
server {
listen       80;
server_name  localhost;
#charset koi8-r;
#access_log  logs/host.access.log  main;
location / {
root   html;
index  index.html index.htm;
}
#error_page  404              /404.html;
redirect server error pages to the static page\ /50x.html
#
error_page   500 502 503 504  /50x.html;
location = /50x.html {
root   html;
}
proxy the PHP scripts to Apache listening on\ 127.0.0.1:80
#
#location ~ \.php$ {
proxy_pass   http://127.0.0.1;
#}
pass the PHP scripts to FastCGI server listening on\ 127.0.0.1:9000
#
#location ~ \.php$ {
root           html;
fastcgi_pass   127.0.0.1:9000;
fastcgi_index  index.php;
fastcgi_param  SCRIPT_FILENAME\  /scripts$fastcgi_script_name;
include        fastcgi_params;
#}
deny access to .htaccess files, if Apache's\ document root
concurs with nginx's one
#
#location ~ /\.ht {
deny  all;
#}
}
another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
listen       8000;
listen       somename:8080;
server_name  somename  alias  another.alias;
location / {
root   html;
index  index.html index.htm;
}
#}
HTTPS server
#
#server {
listen       443 ssl;
server_name  localhost;
ssl_certificate      cert.pem;
ssl_certificate_key  cert.key;
ssl_session_cache    shared:SSL:1m;
ssl_session_timeout  5m;
ssl_ciphers  HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers  on;
location / {
root   html;
index  index.html index.htm;
}
#}
}

Примечания по параметрам конфигурации:

user — определяет пользователя, от имени которого запускается процесс Nginx. В дистрибутиве ОС данный параметр закомментирован, поскольку сервер запускается под пользователем nginx по умолчанию;
listen — задаёт порт, на котором принимает соединения сервер (например, 80 для HTTP);
server_name — определяет имя сервера; по умолчанию используется localhost;
location / — определяет обработку запросов к корневому адресу сайта;
root — путь к каталогу, из которого осуществляется выдача файлов сайта;
index — список файлов, которые будут открываться по умолчанию при отсутствии указания конкретного имени файла в запросе.

Настройка виртуальных хостов

Для организации обслуживания нескольких сайтов (виртуальных хостов) рекомендуется выполнять следующие шаги (рассмотрен простой пример для двух сайтов):

подготовить структуру каталогов. В каталоге /var/www рекомендуется создать отдельные подкаталоги для каждого сайта, а внутри — директории html для хранения файлов сайта. Например:

mkdir -p /var/www/rosaserver1/html
mkdir -p /var/www/rosaserver2/html

установить владельца каталогов для текущего пользователя с использованием переменной окружения $USER:

chown -R $USER:$USER /var/www/rosaserver1/html
chown -R $USER:$USER /var/www/rosaserver2/html

для проверки корректности настройки рекомендуется создать простые страницы. Для редактирования содержимого первого сайта открыть файл командой:

nano /var/www/rosaserver1/html/index.html

добавить в файл следующий код:

<html>
<head>
<title>Welcome to RosaServer1!</title>
</head>
<body>
Success! The RosaServer1 block is working!
</body>
</html>

для редактирования содержимого второго сайта открыть файл командой:

nano /var/www/rosaserver2/html/index.html

добавить в файл следующий код:

<html>
<head>
<title>Welcome to RosaServer2!</title>
</head>
<body>
Success! The RosaServer2 block is working!
</body>
</html>

файлы необходимо сохранить и закрыть.

Организация структуры виртуальных хостов

Для хранения конфигураций виртуальных хостов требуется создать директории:

sudo mkdir /etc/nginx/sites-available
sudo mkdir /etc/nginx/sites-enabled

После этого необходимо указать в конфигурационном файле Nginx, что активные блоки server находятся в каталоге sites-enabled. Для этого следует открыть файл /etc/nginx/nginx.conf и в конце блока "http {}" добавить:

include /etc/nginx/sites-enabled/*.conf;

Создание файлов конфигурации виртуальных хостов

В качестве шаблона может быть использован файл /etc/nginx/conf.d/virtual.conf. Рекомендуется скопировать его в каталог sites-available для каждого сайта:

cp /etc/nginx/conf.d/virtual.conf /etc/nginx/sites-available/rosaserver1.conf
cp /etc/nginx/conf.d/virtual.conf /etc/nginx/sites-available/rosaserver2.conf

После копирования необходимо открыть соответствующие файлы и отредактировать их. Например, для первого сайта:

sudo nano /etc/nginx/sites-available/rosaserver1.conf

Пример содержимого файла:

server {
listen       80;
server_name  rosaserver1;
location / {
root   /var/www/rosaserver1/html;
index  index.html index.htm;
}
}

Для второго сайта аналогично, изменяя параметры server_name и root:

server {
listen       80;
server_name  rosaserver2;
location / {
root   /var/www/rosaserver2/html;
index  index.html index.htm;
}
}

Файлы необходимо сохранить и закрыть.

Включение виртуальных хостов

Для активации виртуальных хостов требуется создать символические ссылки из каталога sites-available в sites-enabled:

ln -s /etc/nginx/sites-available/rosaserver1.conf /etc/nginx/sites-enabled/rosaserver1.conf
ln -s /etc/nginx/sites-available/rosaserver2.conf /etc/nginx/sites-enabled/rosaserver2.conf

Необходимо выполнить перезапуск сервиса Nginx, чтобы применить новые настройки:

sudo systemctl restart nginx.service

Чтобы проверить работу виртуальных хостов, рекомендуется открыть веб-браузер и проверить доступность созданных сайтов по адресам:

http://rosaserver1/
http://rosaserver2/

При корректной настройке должны отобразиться созданные ранее демонстрационные страницы.

Настройка HTTPS/TLS в Nginx

Поддержка защищённых соединений с использованием протоколов SSL/TLS является одной из важнейших функций веб-сервера Nginx. Реализация HTTPS позволяет обеспечить конфиденциальность и целостность данных при обмене между пользователем и сервером.

Nginx предоставляет гибкие возможности для настройки TLS, включая выбор версий протокола, шифров, поддержку OCSP Stapling и других расширений безопасности.

Для тестовых целей или при отсутствии центра сертификации может использоваться самоподписанный сертификат. Для его создания необходимо выполнить следующую команду:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout /etc/ssl/private/server.key \
-out /etc/ssl/certs/server.crt

В результате будет создан сертификат server.crt и соответствующий ему закрытый ключ server.key. Необходимо обеспечить надёжные права доступа к закрытому ключу, например:

chmod 600 /etc/ssl/private/server.key

Пример базовой конфигурации TLS в Nginx:

server {
listen              443 ssl;
server_name         example.local;
ssl_certificate     /etc/ssl/certs/server.crt;
ssl_certificate_key /etc/ssl/private/server.key;
ssl_protocols       TLSv1.2 TLSv1.3;
ssl_ciphers         HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
ssl_session_cache   shared:SSL:10m;
ssl_session_timeout 10m;
location / {
root   /var/www/html;
index  index.html index.htm;
}
}

где:

ssl_protocols — перечень протоколов, разрешённых для использования. В целях безопасности рекомендуется ограничиться TLSv1.2 и TLSv1.3;
ssl_ciphers — определяет допустимые наборы шифров. Рекомендуется использовать HIGH с исключением слабых алгоритмов, например HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers — включает приоритет серверных шифров при согласовании алгоритма между клиентом и сервером;
ssl_session_cache — определяет параметры кеширования сессий TLS, что уменьшает время повторных подключений;
ssl_session_timeout — задаёт время жизни кешированной сессии.

После изменения конфигурации необходимо выполнить проверку синтаксиса командой:

sudo nginx -t

и перезапустить сервис для применения изменений:

sudo systemctl reload nginx

Настройка обратного проксирования в Nginx

Веб-сервер Nginx нередко используется не только для раздачи статического контента, но и в качестве высокопроизводительного обратного прокси-сервера (reverse proxy), который перенаправляет запросы на другие приложения, например: Apache, Tomcat, Node.js или другие веб-сервисы. Такой подход позволяет централизовать обработку SSL, уменьшить нагрузку на сервер приложений, реализовать балансировку нагрузки и повысить отказоустойчивость.

Пример, при котором Nginx принимает запросы на порт 80 и перенаправляет их на внутренний сервер Apache, работающий на порту 8080:

server {
listen       80;
server_name  example.local;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For\ $proxy_add_x_forwarded_for;
}
}

В данной конфигурации:

все запросы отправляются на 127.0.0.1:8080 (Apache);
передаются заголовки с исходным IP-адресом пользователя и именем хоста для правильной обработки логики приложения;
сохраняется возможность ведения журналов с реальными IP пользователей.

Директива proxy_pass указывает, куда именно будет перенаправляться запрос. Поддерживается схема http://, https:// или даже unix:/path/to/socket.

Например, следующая команда означает, что все запросы из данного блока location перенаправляются на указанный адрес:

proxy_pass http://backend-app:8000;

При наличии нескольких серверов приложений можно использовать блок upstream для балансировки запросов, например:

upstream backend {
server 192.168.1.10;
server 192.168.1.11;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}

В этом примере Nginx будет распределять запросы по серверам 192.168.1.10 и 192.168.1.11 по умолчанию методом round-robin.

Для более сложных сценариев доступны опции sticky-сессий, настройки fail_timeout и другие механизмы управления доступностью бэкендов.

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

proxy_connect_timeout       5s;
proxy_send_timeout         30s;
proxy_read_timeout         30s;
send_timeout               30s;

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

После внесения изменений необходимо проверить корректность конфигурации с помощью команды:

sudo nginx -t

и перезапустить веб-сервер:

sudo systemctl reload nginx

Механизмы защиты Nginx

Для повышения уровня безопасности веб-сервера Nginx рекомендуется применять ряд механизмов, которые помогут защитить сервис от перегрузок, злоупотреблений и атак типа DoS. К таким механизмам относятся:

Ограничение числа одновременных подключений и скорости:
- Настройка ограничения числа подключений:

limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_conn addr 20;

Настройка ограничения скорости запросов:

limit_req_zone $binary_remote_addr zone=req_zone:10m\ rate=5r/s;
limit_req zone=req_zone burst=10 nodelay;

Такая конфигурация позволит производить не более 20 одновременных соединений с одного IP-адреса, а также не более 5 запросов в секунду.

Защита от слишком больших запросов, которые могут вызвать отказ сервиса. Рекомендуется задать максимальный размер тела запроса:

client_max_body_size 2m;

Значение может быть указано в мегабайтах или килобайтах в зависимости от предполагаемой нагрузки.

Интеграция с внешними инструментами фильтрации, такими как fail2ban.

Fail2ban — это утилита, позволяющая отслеживать в журналах сервера подозрительные попытки входа или злоупотребления и автоматически блокировать IP-адреса злоумышленников через брандмауэр.

Для защиты Nginx обычно используется фильтр, анализирующий ошибки в файле журнала. Для установки и настройки фильтра необходимо выполнить следующие действия:

установить пакет fail2ban;
создать фильтр, например /etc/fail2ban/filter.d/nginx-http-auth.conf, с выражениями для поиска атак;
настроить jail (правило) в /etc/fail2ban/jail.local, например:

[nginx-http-auth]
enabled  = true
filter   = nginx-http-auth
port     = http,https
logpath  = /var/log/nginx/error.log
maxretry = 5
findtime = 600
bantime  = 3600

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

В комплексе с настройками fail2ban стоит использовать внутренние директивы Nginx, которые позволяют реализовать базовую защиту от DoS-атак:

limit_conn ограничивает число одновременных соединений на одного клиента;
limit_req ограничивает частоту запросов.

Они могут комбинироваться, создавая эффективный барьер против перегрузок сервиса и злоупотреблений.

После внесения изменений рекомендуется проверить корректность конфигурации:

sudo nginx -t

и применить её:

sudo systemctl reload nginx

Логирование и анализ в Nginx

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

Рекомендуется выполнить комплексную настройку логирования по следующим этапам:

Настройка формата access.log. По умолчанию журнал запросов access.log ведётся с базовым форматом, который может быть расширен под конкретные требования. Для этого в конфигурации определяется директива log_format:

log_format main '$remote_addr - $remote_user [$time_local]\ "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

Эта конструкция позволит фиксировать IP-адрес клиента, дату, строку запроса, статус ответа, реферер и заголовки агента.

Использование пользовательских форматов журналирования (custom log format). Если требуется регистрировать дополнительные данные, например время ответа или значения cookie, можно добавить их в шаблон log_format:

log_format custom '$remote_addr [$time_local] "$request" '
'status=$status bytes=$body_bytes_sent '
'rt=$request_time cookie="$http_cookie"';

После чего необходимо указать данный формат в директиве access_log:

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

Ротация логов с использованием logrotate. Для автоматического ограничения размера журналов и предотвращения переполнения файловой системы используется система logrotate. В дистрибутивах ОС конфигурация логирования nginx обычно хранится в файле /etc/logrotate.d/nginx. Пример типичной настройки:

/var/log/nginx/*.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
create 0640 nginx adm
sharedscripts
postrotate
sudo systemctl reload nginx.service > /dev/null 2>&1 || true
endscript
}

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

В примере типичной настройки:

daily — выполняется ротация журналов ежедневно;
rotate 7 — хранить 7 предыдущих архивных копий;
compress — при ротации старые файлы сжимаются с помощью gzip;
delaycompress — откладывает сжатие на один цикл ротации, чтобы не сжимать самый новый архив сразу;
postrotate ... endscript — блок команд, который выполняется после ротации; в данном случае перезапускает конфигурацию сервиса Nginx для корректного использования нового файла журнала.

Интеграция с централизованной системой журналирования. При необходимости можно перенаправить журналы Nginx в syslog или системный журнал journald. Для этого в конфигурации сервера указывается:

access_log syslog:server=unix:/dev/log,facility=local7,tag=nginx_access;
error_log syslog:server=unix:/dev/log,facility=local7,tag=nginx_error warn;

Резервное копирование и восстановление Nginx

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

Рекомендуется выполнять следующие действия:

Определить критически важные файлы и каталоги для резервного копирования. В резервные копии должны обязательно включаться:

основной файл конфигурации /etc/nginx/nginx.conf;
все файлы виртуальных хостов, расположенные в каталогах /etc/nginx/conf.d/, /etc/nginx/sites-available/ и /etc/nginx/sites-enabled/;
пользовательские SSL-сертификаты и ключи в /etc/ssl/certs/ и /etc/ssl/private/;
при необходимости скрипты и шаблоны мониторинга или логирования, интегрированные с Nginx.

Создавать сжатую копию конфигурации и сертификатов не реже одного раза в неделю с сохранением нескольких предыдущих версий архива, используя команду:

sudo tar czf /backup/nginx-config-$(date +%Y%m%d).tar.gz /etc/nginx /etc/ssl

Такой архив может храниться на отдельном сервере резервного копирования, в том числе с применением средств шифрования при передаче или хранении.

Для восстановления после сбоя необходимо выполнить:

распаковку резервного архива в стандартные каталоги:

sudo tar xzf nginx-config-20250620.tar.gz -C /

проверку корректности прав доступа и владельцев файлов;
проверку конфигурации веб-сервера командой:

sudo nginx -t

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

sudo systemctl reload nginx

При использовании системы управления версиями (например, Git) возможно организовать дополнительный контроль изменений и отслеживать историю правок в конфигурационных файлах.

Обновление и управление версиями Nginx

Для контроля актуальности установленной версии рекомендуется:

проверять текущую версию командой nginx -v;
при необходимости уточнять доступные обновления в репозитории с помощью:

dnf info nginx

Процесс обновления Nginx выполняется стандартным менеджером пакетов dnf:

sudo dnf update nginx

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

sudo nginx -s reload

Этот вариант позволяет без прерывания обслуживания клиентов применить новую конфигурацию или загрузить обновлённый бинарный файл.

Веб-сервер Angie

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

Angie включает все возможности версии Nginx 1.25.3 и расширяет их рядом дополнительных функций, среди которых:

Поддержка HTTP/3 как для клиентских соединений, так и для соединений с проксируемыми серверами с возможностью раздельного использования различных протоколов (HTTP/1.x, HTTP/2, HTTP/3) на разных направлениях.
Упрощение конфигурации за счёт возможности в директиве location задавать несколько строк сопоставления и объединять блоки с одинаковыми настройками.
Получение базовой информации о веб-сервере, его конфигурации, а также статистики по клиентским соединениям, проксируемым серверам, зонам разделяемой памяти и другим параметрам через REST-подобный API-интерфейс в формате JSON.
Возможность экспорта метрик и статистики в формате Prometheus с гибкими шаблонами.
Интеграция с визуальной консолью мониторинга Console Light, доступной через веб-браузер (онлайн-пример консоли доступен по адресу: ).
Автоматическое обновление списка проксируемых серверов по доменным именам, включая возможность получения данных из DNS-записей SRV.
Режим привязки сессий, позволяющий направлять все запросы в рамках одной сессии на один и тот же проксируемый сервер.
Реализация плавного ввода проксируемого сервера после сбоя с использованием опции slow_start директивы server.
Ограничение скорости отдачи MP4-файлов с учётом их битрейта, что снижает нагрузку на сеть.
Поддержка директивы mqtt_preread в модуле stream, расширяющая возможности балансировки и аутентификации по протоколу MQTT.
Наличие готовых бинарных пакетов для интеграции со многими сторонними модулями.

Официальный сайт проекта.

Установка Angie

Для установки веб-сервера Angie необходимо выполнить следующие действия:

установитьпакет Angie из репозитория:

sudo dnf install angie

запустить сервис веб-сервера:

sudo systemctl start angie.service

включить автоматический запуск при загрузке:

sudo systemctl enable angie.service

Настройка и управление веб-сервером Angie

По умолчанию структура каталогов Angie совпадает с Nginx:

/usr/share/angie/html — директория веб-контента;
/etc/angie/ — основной каталог конфигурации;
/etc/angie/angie.conf — главный конфигурационный файл;
/etc/angie/conf.d/ — каталог для виртуальных хостов;
/var/log/angie/access.log — журнал запросов;
/var/log/angie/error.log — журнал ошибок.

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

После установки рекомендуется проверить работу веб-сервера. Для этого следует открыть браузер и перейти по адресу сервера (например, http://<IP-адрес>). При корректном запуске будет отображена стандартная страница Angie.

Основным конфигурационным файлом Angie является /etc/angie/angie.conf. В этом файле задаются глобальные параметры работы сервера.

Рекомендуется придерживаться следующего подхода:

все изменения в глобальных настройках вносить в angie.conf;
файлы конфигурации отдельных виртуальных хостов хранить в каталоге /etc/angie/conf.d/;
при большом числе сайтов структурировать конфигурацию с помощью отдельных директорий sites-available и sites-enabled аналогично практике Nginx.

Для активации виртуальных хостов может быть добавлена директива include /etc/angie/sites-enabled/*.conf; в блок "http {}" основного конфигурационного файла.

Ниже приведён пример минимальной конфигурации виртуального хоста для Angie:

server {
listen       80;
server_name  example.local;
location / {
root   /var/www/example.local/html;
index  index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/angie/html;
}
}

В приведённой конфигурации задаётся имя сервера, корневая директория сайта и базовая обработка ошибок.

После изменения конфигурационных файлов необходимо произвести проверку корректности синтаксиса:

sudo angie -t

В случае отсутствия ошибок конфигурацию рекомендуется загрузить без прерывания активных соединений:

sudo systemctl reload angie.service

Дополнительные функции Angie

Angie расширяет традиционные функции Nginx следующими механизмами, которые могут быть востребованы при настройке:

slow_start — позволяет плавно вводить проксируемый сервер в работу после сбоя. Настраивается в блоке upstream:

upstream backend {
server 192.168.1.100;
server 192.168.1.101;
slow_start 30s;
}

В данном примере повторное включение сервера будет происходить в течение 30 секунд с постепенным увеличением доли запросов.

mqtt_preread — директива для протокола MQTT, применяемая в модуле stream:

stream {
mqtt_preread on;
server {
listen 1883;
proxy_pass mqtt_backend;
}
}

mqtt_preread используется для расширенной аутентификации и балансировки MQTT-соединений.

HTTP/3 — поддержка нового протокола включается в секции listen:

server {
listen 443 quic reuseport;
http3 on;
ssl_certificate /etc/ssl/certs/server.crt;
ssl_certificate_key /etc/ssl/private/server.key;
...
}

Здесь параметр quic включает использование UDP и HTTP/3, при этом по-прежнему возможен fallback на HTTP/1.x или HTTP/2.

Мониторинг и API

Angie предоставляет REST-подобный API для получения данных о состоянии сервера, текущей конфигурации, статистике по зонам разделяемой памяти, соединениям и проксируемым серверам.

В ответах API используется формат JSON, что позволяет легко интегрировать Angie с системами мониторинга. Также поддерживается экспорт метрик Prometheus с гибкой настройкой шаблонов.

Для удобного визуального контроля может использоваться консоль Console Light. Её работа не требует дополнительной установки — необходимо лишь активировать соответствующий блок в конфигурации и открыть веб-интерфейс по адресу сервера.

Настройка HTTPS/TLS в Angie

Angie поддерживает все основные механизмы TLS/SSL, применяемые в современных веб-серверах. При этом полностью сохраняется совместимость с синтаксисом Nginx.

Для включения защищённых соединений необходимо выполнить следующие шаги:

сгенерировать ключ и сертификат (например, с помощью openssl);
разместить их в защищённой директории, доступной только пользователю, от имени которого работает Angie;
описать соответствующую секцию server с параметрами listen и ssl_certificate.

Пример минимальной конфигурации HTTPS:

server {
listen              443 ssl;
server_name         example.local;
ssl_certificate     /etc/ssl/certs/server.crt;
ssl_certificate_key /etc/ssl/private/server.key;
ssl_protocols       TLSv1.2 TLSv1.3;
ssl_ciphers         HIGH:!aNULL:!MD5;
location / {
root /var/www/example.local/html;
index index.html index.htm;
}
}

В данном примере задаются:

сертификат сервера (ssl_certificate);
закрытый ключ (ssl_certificate_key);
допустимые протоколы tls (рекомендуется ограничить tlsv1.2 и tlsv1.3);
набор безопасных шифров (ssl_ciphers).

Рекомендуется придерживаться следующих принципов для безопасной настройки веб-сервера:

сертификаты и ключи следует хранить в директории с ограниченными правами доступа;
не использовать ssl-протоколы ниже tlsv1.2;
при работе с публичными центрами сертификации (ca) важно настроить ocsp stapling для повышения надёжности;
желательно активировать параметр ssl_prefer_server_ciphers on, чтобы сервер контролировал выбор шифра.

После внесения всех изменений в конфигурационные файлы необходимо выполнить проверку синтаксиса:

sudo angie -t

После проверки необходимо перезапустить службу без обрыва соединений:

sudo systemctl reload angie.service

Настройка обратного проксирования в Angie

Веб-сервер Angie, как и Nginx, может использоваться в качестве обратного прокси (reverse proxy) для передачи запросов к другим серверам приложений, например: Apache, Tomcat, Node.js и др. Данный механизм позволяет централизовать обработку SSL, балансировать нагрузку и распределять трафик.

Для настройки обратного проксирования необходимо создать блок server, в котором используется директива proxy_pass. Ниже приведён минимальный пример:

server {
listen       80;
server_name  proxy.example.local;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

В данной конфигурации все запросы, поступающие на порт 80, перенаправляются на внутренний сервер по адресу 127.0.0.1:8080. Дополнительно устанавливаются заголовки для передачи исходного IP-адреса клиента и имени хоста.

Балансировка нагрузки

Angie поддерживает балансировку между несколькими серверами приложений с помощью блока upstream, например:

upstream backend {
server 192.168.1.10 max_fails=3 fail_timeout=30s;
server 192.168.1.11 max_fails=3 fail_timeout=30s;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}

В данной конфигурации создаётся пул из двух серверов с балансировкой по умолчанию (round-robin) и базовым механизмом проверки доступности через параметры max_fails и fail_timeout.

Привязка сессий

Для случаев, когда требуется сохранять сессию пользователя на одном и том же бэкенде, используется механизм привязки сессий (sticky sessions), например:

upstream backend {
server 192.168.1.10;
server 192.168.1.11;
sticky cookie srv_id expires=1h domain=.example.local path=/;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}

При данной настройке создаётся cookie srv_id, позволяющее направлять все запросы пользователя в течение часа на один и тот же сервер.

Тайм-ауты и ограничения

Рекомендуется дополнительно настроить параметры тайм-аутов, чтобы защитить сервер от зависших соединений:

proxy_connect_timeout       5s;
proxy_send_timeout         30s;
proxy_read_timeout         30s;
send_timeout               30s;

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

limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_conn addr 10;
limit_req_zone $binary_remote_addr zone=req:10m rate=1r/s;
limit_req zone=req burst=5;

После внесения всех изменений в конфигурационные файлы необходимо выполнить проверку синтаксиса:

sudo angie -t

После проверки необходимо перезапустить службу без обрыва соединений:

sudo systemctl reload angie.service

Ограничения и защита в Angie

В целях повышения безопасности и устойчивости веб-сервера Angie рекомендуется настроить ряд механизмов ограничения ресурсов и фильтрации запросов. Это позволяет минимизировать риск DoS-атак, защитить сервис от чрезмерной нагрузки и контролировать активность пользователей:

Ограничение количества подключений от одного IP-адреса директивой limit_conn:

limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_conn addr 20;

где для IP-адреса создаётся зона размером 10 МБ и допускается не более 20 одновременных подключений.

Ограничение скорости передачи данных к клиентам с помощью limit_rate:

server {
location / {
limit_rate 500k;
}
}

где задан параметр "limit_rate 500k", который позволит не превышать скорость 500 КБ в секунду для одного соединения.

Ограничение скорости запросов с помощью limit_req:

limit_req_zone $binary_remote_addr zone=req_zone:10m rate=5r/s;
limit_req zone=req_zone burst=10 nodelay;

где задается не более 5 запросов в секунду на один IP с возможностью коротких всплесков до 10 запросов подряд.

Фильтрация доступа к ресурсу по IP-адресам можно использовать директивы allow и deny:

server {
location / {
allow 192.168.1.0/24;
deny all;
}
}

В данном случае доступ будет разрешён только из подсети 192.168.1.0/24, остальные подключения будут отклоняться.

Защита от медленных атак типа slowloris с помощью настройки тайм-аутов:

client_body_timeout 10s;
client_header_timeout 10s;
send_timeout 30s;
keepalive_timeout 15s;

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

Для дополнительной защиты возможно использование fail2ban, который анализирует журналы ошибок Angie и блокирует IP-адреса с подозрительной активностью. Рекомендуется настроить fail2ban с фильтром для error.log и указанием параметров бана в файле /etc/fail2ban/jail.conf или отдельном jail-файле, например:

[angie]
enabled  = true
filter   = angie
port     = http,https
logpath  = /var/log/angie/error.log
maxretry = 5
findtime = 600
bantime  = 3600

Логирование и ротация журналов в Angie

Веб-сервер Angie обладает гибкими возможностями по ведению журналов запросов и ошибок, которые позволяют контролировать его работу, проводить аудит и своевременно реагировать на возникающие сбои или аномалии.

По умолчанию Angie сохраняет журналы обращений в файл /var/log/angie/access.log, а ошибки — в файл /var/log/angie/error.log. Форматы записей можно изменять в соответствии с требованиями эксплуатации, например, добавив в них дополнительную информацию о заголовках, времени ответа, реферере или пользовательском агенте. Для этого используется директива log_format. Пример расширенного шаблона:

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log  /var/log/angie/access.log  main;

Уровень детализации сообщений об ошибках регулируется директивой error_log. Например, для вывода предупреждений и ошибок достаточно указать уровень warn:

error_log  /var/log/angie/error.log  warn;

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

server {
server_name site1.local;
access_log /var/log/angie/site1_access.log;
error_log  /var/log/angie/site1_error.log warn;
}

Также Angie поддерживает вывод журналов через системный журнал journald или через syslog-сервер. Для этого в настройках access_log и error_log можно указать:

access_log syslog:server=unix:/dev/log,facility=local7,tag=angie_access;
error_log  syslog:server=unix:/dev/log,facility=local7,tag=angie_error warn;

Это обеспечивает централизованный сбор журналов для последующего анализа средствами системного журнала.

Ротация журналов

Для управления размерами файлов журналов и автоматического их сжатия рекомендуется применять системную утилиту logrotate. При стандартной установке создаётся конфигурация в каталоге /etc/logrotate.d/angie, которая может быть настроена, например, следующим образом:

/var/log/angie/*.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
create 0640 nginx adm
sharedscripts
postrotate
sudo systemctl reload angie.service > /dev/null 2>&1 || true
endscript
}

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

Мониторинг и диагностика в Angie

Для эффективного администрирования веб-сервера Angie необходимо обеспечить постоянный мониторинг его состояния и использование встроенных инструментов диагностики.

Angie предоставляет расширенные возможности мониторинга за счёт встроенного REST API и визуальной консоли Console Light. REST API позволяет в реальном времени получать сведения о конфигурации, состоянии клиентских соединений, статистике зон разделяемой памяти, а также о параметрах работы проксируемых серверов. Данные возвращаются в формате JSON, что упрощает интеграцию с внешними системами мониторинга, например Zabbix или Prometheus.

Для Prometheus в Angie реализован собственный экспорт метрик с возможностью настройки шаблонов. Это позволяет агрегировать показатели нагрузки и работы сервера в стандартных панелях мониторинга, а также формировать предупреждения при выходе параметров за заданные пределы.

Кроме того, Angie поддерживает визуальную консоль Console Light, которая позволяет в браузере наблюдать за ключевыми показателями веб-сервера. Console Light не требует отдельной установки и доступна сразу после включения в конфигурации. Для её активации достаточно добавить в основной конфигурационный файл соответствующий блок и открыть указанный интерфейс по адресу сервера.

Мониторинг и диагностика могут дополняться средствами анализа логов. Рекомендуется:

отслеживать изменения в журналах ошибок и доступа с помощью системного журнала или logrotate;
контролировать ключевые тайм-ауты и показатели использования памяти;
проверять своевременность применения обновлений конфигурации с помощью команды angie -t;
анализировать производительность с помощью отчётов Prometheus или других инструментов.

Резервное копирование и восстановление конфигурации Angie

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

В первую очередь необходимо включить в резервную копию следующие элементы:

Основной файл конфигурации /etc/angie/angie.conf.
Все файлы виртуальных хостов, например, в каталогах /etc/angie/conf.d/, /etc/angie/sites-available/ и /etc/angie/sites-enabled/.
Пользовательские сертификаты и ключи в каталогах /etc/ssl/certs/ и /etc/ssl/private/.
Файлы журналов конфигурационных шаблонов мониторинга (если используются).

Рекомендуется использовать утилиты tar или rsync, позволяющие быстро создать резервную копию всей структуры конфигурации вместе с правами доступа (подробнее о работе с утилитами рассмотрено в разделе Резервное копирование данных). Пример команды:

sudo tar czf /backup/angie-config-$(date +%Y%m%d).tar.gz /etc/angie /etc/ssl

Архив, созданный таким образом, можно переместить на внешний носитель или в защищённое хранилище.

При необходимости восстановления достаточно выполнить распаковку архива в исходное место и проверить корректность прав доступа:

sudo tar xzf angie-config-20250620.tar.gz -C /

После восстановления рекомендуется:

убедиться в целостности всех файлов конфигурации;
проверить синтаксис конфигурации командой angie -t;
выполнить перезапуск или перезагрузку конфигурации angie:

sudo systemctl reload angie.service

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

Также следует рассмотреть возможность интеграции конфигурационных файлов Angie в систему управления версиями (например, Git), что обеспечит контроль версий и удобное отслеживание изменений между разными этапами эксплуатации.

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

Миграция с Nginx на Angie

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

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

При выполнении миграции с Nginx на Angie рекомендуется придерживаться следующего порядка:

Подготовка и анализ конфигурации:

проверить актуальность версий Nginx и Angie;
необходимо убедиться, что установленные модули Nginx не используют закрытые проприетарные расширения, отсутствующие в Angie;
сохранить резервную копию всех конфигурационных файлов Nginx;

Установка Angie:

установка пакета Angie через менеджер пакетов dnf;
проверка доступности службы и наличия необходимых зависимостей;
отключение службу Nginx для исключения конфликта портов;

Перенос конфигурации:

копирование данных из /etc/nginx в /etc/angie;
проверка всех include-директив, которые должны указывать корректные пути;
убедиться в корректности путей к логам и каталогам виртуальных хостов;

Тестирование:

проверка синтаксис конфигурации Angie командой angie -t;
локальное тестирование на стенде для проверки работоспособности всех виртуальных хостов, TLS, проксирования и других функций;
при необходимости корректировка параметров, добавление новых возможностей Angie (например, http3, slow_start).

Ввод в эксплуатацию:

запуск службу Angie;
убедиться в корректном функционировании всех сайтов и сервисов;
настройка мониторинга и журналирование для оперативного контроля состояния.

Рекомендации для выполнения успешной миграции:

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