Nginx-прокси

Материал из ISPWiki
Версия от 12:21, 4 декабря 2015; Cher (обсуждение | вклад) (Основные принципы работы)
Перейти к: навигация, поиск


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


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

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


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

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

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


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

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

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

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

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

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