Настройка Nginx#

Настройка Nginx в качестве веб-сервера, предоставляющего разный контент для разных доменов#

По умолчанию Nginx действует как веб-сервер, который предоставляет клиентам одинаковый контент для всех доменных имен, связанных с IP-адресами сервера. Эта процедура объясняет, как настроить Nginx:

для обслуживания запросов в example.ru домен с содержимым из /var/www/example.ru/ каталога;
для обслуживания запросов в example.net домен с содержимым из /var/www/example.net/ каталога;
для обслуживания всех других запросов, например, на IP-адрес сервера или на другие домены, связанные с IP-адресом сервера, с содержимым из /usr/share/nginx/html/ каталога.

Предварительные условия
- Клиенты и веб-сервер разрешают `example.ru` и `example.net` домен к IP-адресу веб-сервера
- Вручную добавлены записи на свой DNS-сервер

Отредактируйте файл /etc/nginx/nginx.conf:
- По умолчанию файл /etc/nginx/nginx.conf уже содержит всеобъемлющую конфигурацию. Если удалили эту часть из конфигурации, повторно добавьте следующий серверный блок в HTTP-блок в файле /etc/nginx/nginx.conf:
```
server {
      listen       80 default_server;
      listen       [::]:80 default_server;
      server_name  _;
      root         /usr/share/nginx/html;
  }
```
  Где:
  - директива listen определяет, какие IP-адреса и порты прослушивает служба. В этом случае Nginx прослушивает порт 80 как по всем адресам IPv4, так и по IPv6. Параметр default_server указывает, что Nginx использует этот серверный блок по умолчанию для запросов, соответствующих IP-адресам и портам;
  - параметр server_name определяет имена хостов, за которые отвечает этот серверный блок. Установка server_name в _ настраивает Nginx на принятие любого имени хоста для этого серверного блока;
  - директива root задает путь к веб-контенту для этого серверного блока.
- Добавьте аналогичный серверный блок для example.ru домен в HTTP-блок:
```
server {
      server_name  example.ru;
      root         /var/www/example.ru/;
      access_log   /var/log/nginx/example.ru/access.log;
      error_log    /var/log/nginx/example.ru/error.log;
  }
```
  Где:
  - access_log - определяет отдельный файл журнала доступа для этого домена;
  - error_log - определяет отдельный файл журнала ошибок для этого домена.
- Добавьте аналогичный серверный блок для example.net домен к HTTP-блоку:
```
server {
      server_name  example.net;
      root         /var/www/example.net/;
      access_log   /var/log/nginx/example.net/access.log;
      error_log    /var/log/nginx/example.net/error.log;
  }
```
Создайте корневые каталоги для обоих доменов:
```
mkdir -p /var/www/example.ru/
~~

и

~~~bash
mkdir -p /var/www/example.net/
```
Установите контекст httpd_sys_content_t для обоих корневых каталогов:
```
semanage fcontext -a -t httpd_sys_content_t "/var/www/example.ru(/.*)?"
restorecon -Rv /var/www/example.ru/
semanage fcontext -a -t httpd_sys_content_t "/var/www/example.net(/.\*)?"
restorecon -Rv /var/www/example.net/
```
Эти команды устанавливают контекст httpd_sys_content_t в каталогах /var/www/example.ru/ и /var/www/example.net/.

Обратите внимание, что для выполнения команд restorecon необходимо установить пакет policycoreutils-python-utils.
Создайте каталоги журналов для обоих доменов:
```
mkdir /var/log/nginx/example.ru/
```
и
```
mkdir /var/log/nginx/example.net/
```
Перезапустите службу Nginx:
```
systemctl restart nginx
```

Этапы проверки:

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

echo "Content for example.ru" /var/www/example.ru/index.html
echo "Content for example.net" /var/www/example.net/index.html
echo "Catch All content" /usr/share/nginx/html/index.html

В любом браузере подключитесь к http://example.ru. Веб-сервер показывает пример содержимого из файла /var/www/example.ru/index.html.
В любом браузере подключитесь к http://example.net. Веб-сервер показывает пример содержимого из файла /var/www/example.net/index.html.
В любом браузере подключитесь к http://IP_address_of_the_server. Веб-сервер показывает пример содержимого из файла /usr/share/nginx/html/index.html.

Добавление шифрования TLS на веб-сервер Nginx#

В этом разделе описывается, как включить шифрование TLS на веб-сервере Nginx для example.ru домен.

Предварительные условия
- Закрытый ключ хранится в файле `/etc/pki/tls/private/example.ru.key`
- Сертификат TLS хранится в файле `/etc/pki/tls/certs/example.ru.crt`. Если используете другой путь, адаптируйте соответствующие шаги процедуры
- Сертификат CA был добавлен к файлу сертификата TLS сервера
- Клиенты и веб-сервер преобразуют имя хоста сервера в IP-адрес веб-сервера
- Порт `443` открыт в локальном межсетевом экране

Для получения подробной информации о создании закрытого ключа и запроса на подписание сертификата (CSR), а также о том, как запросить сертификат у центра сертификации (CA).

Отредактируйте файл /etc/nginx/nginx.conf и добавьте следующий серверный блок к HTTP-блоку в конфигурации:

server {
     listen              443 ssl;
     server_name         example.ru;
     root                /usr/share/nginx/html;
     ssl_certificate     /etc/pki/tls/certs/example.ru.crt;
     ssl_certificate_key /etc/pki/tls/private/example.ru.key;
  }

По соображениям безопасности настройте, чтобы только пользователь с административными полномочиями мог получить доступ к файлу закрытого ключа:
```
chown root:root /etc/pki/tls/private/example.ru.key
chmod 600 /etc/pki/tls/private/example.ru.key
```
Предупреждение: Если к закрытому ключу получили доступ неавторизованные пользователи, отмените сертификат, создайте новый закрытый ключ и запросите новый сертификат. В противном случае соединение TLS больше не является безопасным.
Перезапустите cлужбу Nginx:
```
systemctl restart nginx
```
Опционально. Используйте браузер и подключитесь к https://example.ru.

Настройка Nginx в качестве обратного прокси для HTTP-трафика#

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

Эта процедура объясняет, как перенаправить трафик в каталог /example на веб-сервере по URL https://example.ru.

Предварительные условия
- При необходимости шифрование TLS включено на обратном прокси-сервере

Отредактируйте файл /etc/nginx/nginx.conf и добавьте следующие настройки в серверный блок, который должен обеспечивать обратный прокси:
```
location /example {
proxy_pass https://example.ru;
```
Блок location определяет, что Nginx передает все запросы в каталоге /example в https://example.ru.
Установите для логического параметра httpd_can_network_connect SELinux значение 1, чтобы SELinux позволил Nginx пересылку трафика:
```
setsebool -P httpd_can_network_connect 1
```
Перезапустите службу Nginx:
```
systemctl restart nginx
```
Опционально. Используйте браузер и подключитесь к http://host_name/example, где отобразится содержание https://example.ru.

Настройка Nginx в качестве балансировщика нагрузки HTTP#

Можно использовать функцию обратного прокси-сервера Nginx для балансировки нагрузки на трафик. Эта процедура описывает, как настроить Nginx в качестве балансировщика нагрузки HTTP, который отправляет запросы на разные серверы, основываясь на том, какой из них имеет наименьшее количество активных подключений. Если оба сервера недоступны, процедура также определяет третий хост по причинам резервного копирования.

Отредактируйте файл /etc/nginx/nginx.conf и добавьте следующие настройки:
```
  http {
      upstream backend {
          least_conn;
          server server1.example.ru;
          server server2.example.ru;
          server server3.example.ru backup;
      }

      server {
          location / {
              proxy_pass http://backend;
          }
      }
  }
```
Директива least_conn в группе хостов с именем backend определяет, что Nginx отправляет запросы на server1.example.ru или server2.example.ru, в зависимости от того, какой хост имеет наименьшее количество активных подключений. Nginx использует server3.example.ru только в качестве резервной копии на случай, если два других хоста недоступны.

С директивой proxy_pass, установленной на http://backend, Nginx действует как обратный прокси-сервер и использует серверную группу хостов для распределения запросов на основе настроек этой группы.

Вместо метода балансировки нагрузки least_conn можно указать:
- отсутствие способа использовать циклический перебор и равномерно распределять запросы по серверам;
- ip_hash для отправки запросов с одного клиентского адреса на один и тот же сервер на основе хеша, вычисленного из первых трех октетов IPv4-адреса или всего IPv6-адреса клиента;
- <hash> для определения сервера на основе пользовательского ключа, который может быть строкой, переменной или комбинацией того и другого. Согласованный параметр настраивает, что Nginx; распределяет запросы по всем серверам на основе определенного пользователем значения хешированного ключа;
- случайные отправки запросов на случайно выбранный сервер.
Перезапустите службу Nginx:
```
systemctl restart nginx
```