Nginx-прокси

Материал из ISPWiki
Перейти к: навигация, поиск

Данная статья посвящена описанию механизмов работы модуля проксирования запросов пользовательских приложений (сокращенно Nginx-прокси). Под пользовательскими приложениями понимаются например phpMyAdmin, phpPGAdmin, Roundcube и т.д.

Работа панели без использования Nginx-прокси

Без использования Nginx-прокси панель управления перенаправляет запросы к пользовательским приложениям на узел кластера, обслуживающий необходимую роль (например, "Почтовый сервер" для Roundcube). При этом дальнейшая работа пользователя с приложением будет производиться уже по адресу узла кластера (по умолчанию используется основной IP-адрес узла кластера, например https://12.34.56.78/roundcude).

Задачи использования Nginx-прокси

При предоставлении услуг shared-хостинга может понадобиться настроить доступ к пользовательским приложениям через единую точку входа. В качестве адреса точки входа будет использоваться указанное в настройках доменное имя. Это позволяет решить несколько проблем:

  • Доступ ко всем пользовательским приложениям и, если необходимо, в панель управления по одному доменному имени
  • Возможность использовать один SSL-сертификат (полученный на доменное имя) для работы пользовательских приложений, а также доступа в панель управления
  • Пользователь получает постоянный адрес (URL) пользовательского приложения, который не будет изменяться (например, при перемещении пользователя между узлами кластера)

Основные принципы работы

Веб-сервер Nginx позволяет прозрачно проксировать клиентские запросы. С помощью этого механизма решаются описанные выше задачи. Логически схема проксирования выглядит следующим образом:

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

На мастер-сервере настраивается веб-сервер Nginx следующим образом:

  1. Создается виртуальный сервер (server) для нужного доменного имени на определенном администратором IP-адресе на порту 80 для перенаправления запросов на порт защищенного соединения
  2. Создается виртуальный сервер (server) для нужного доменного имени на определенном администратором IP-адресе на порту защищенного соединения (443), предоставляющий функциональность проксирования
  3. Создаются именованные виртуальные директории (location) для каждого узла кластера (location @node1). Они отвечают за проксирование запроса на узел кластера
  4. Создаются виртуальные директории (location) для каждого пользователя (location /username)
  5. В location пользователя создаются виртуальные директории (location) для каждого пользовательского приложения (location /username/appname). Они определяют, в какой именованный location узла кластера передать запрос для обработки
  6. Если необходимо проксировать запросы к панели управления, настраивается корневая виртуальная директория location / и проксирующая запросы к панели виртуальная директория location @ispmgr

Технические подробности

  • Для каждого узла кластера при его создании или изменении основного IP-адреса регистрируется рассинхронизация основного IP-адреса, при синхронизации настраивающая на узле кластера его основной IP-адрес. При этом на узле кластера, если он имеет установленный Nginx:
  1. В основном конфигурационном файле веб-сервера Nginx создается виртуальный сервер, по умолчанию обрабатывающий запросы на основном IP-адресе узла кластера (прослушивает порты 80 и 443)
  2. Снимается признак приоритета для всех WWW-доменов, которые были приоритетными на новом основном IP-адресе узла кластера. В дальнейшем WWW-домены, созданные на основном IP-адресе узла кластера, нельзя использовать как приоритетные
  • Настройки виртуального сервера nginx-прокси находятся в файле masterproxy.conf директории включаемых конфигурационных файлов Nginx (conf.d)
  • Виртуальные директории для пользовательских приложений конфигурируются только при определении расположения соответствующей роли пользователя, не ранее

Пример конфигурационного файла виртуального сервера

 server {
         server_name test.net www.test.net;
         ssl on;
         listen 192.168.40.51:443 ssl;
         add_header Strict-Transport-Security "max-age=31536000;";
         client_max_body_size 0;
         ssl_certificate "/usr/local/mgr5/etc/nginx_certs/masterproxy.crtca";
         ssl_certificate_key "/usr/local/mgr5/etc/nginx_certs/masterproxy.key";
         ssl_ciphers HIGH:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!EXP:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2;
         ssl_prefer_server_ciphers on;
         ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
         location @node1 {
                 proxy_redirect /$2/ /$1/$2/;
                 proxy_redirect https://192.168.40.51/$2/ /$1/$2/;
                 proxy_cookie_path /$2/ /$1/$2/;
                 proxy_pass https://192.168.40.51;
                 proxy_request_buffering off;
                 rewrite ^\/(.*?)\/([^\/?]*)(.*)$ /$2$3 break;
         }
         location @node2 {
                 proxy_redirect /$2/ /$1/$2/;
                 proxy_redirect https://192.168.40.52/$2/ /$1/$2/;
                 proxy_cookie_path /$2/ /$1/$2/;
                 proxy_pass https://192.168.40.52;
                 proxy_request_buffering off;
                 rewrite ^\/(.*?)\/([^\/?]*)(.*)$ /$2$3 break;
         }
         location /user1 {
                 location /user1/phpmyadmin {
                         try_files /does_not_exists @node1;
                 }
                 location /user1/roundcube {
                         try_files /does_not_exists @node2;
                 }
         }
         location @ispmgr {
                 proxy_set_header Host $host:$server_port;
                 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                 proxy_set_header X-Forwarded-Proto $scheme;
                 proxy_set_header X-Real-IP $remote_addr;
                 proxy_set_header X-Forwarded-Secret kBBoQd5H6CAcwb5G;
                 proxy_pass https://192.168.40.51:1500;
                 proxy_request_buffering off;
                 proxy_redirect https://192.168.40.51:1500 /;
         }
         location / {
                 try_files /does_not_exists @ispmgr;
         }
 }
 
 server {
         server_name test.net www.test.net;
         return 301 https://$host:443$request_uri;
         listen 192.168.40.51:80;
 }

В приведенном примере видно, что так как пользовательские роли сервера баз данных MySQL и почтового сервера расположены на разных узлах кластера, запросы к соответствующим приложениям (phpMyAdmin и Roundcube) передается на обработку разным именованным виртуальным директориям проксирования.