Nginx + apache + mariadb (mysql) + php + php-fpm (fastcgi) + ftp + phpmyadmin + memcached + postfix на ubuntu

Введение

Сегодня я расскажу о том, как настроить балансировку нагрузки с помощью nginx. Чаще всего это необходимо для балансировки нагрузки между бэкендами и обеспечения отказоустойчивости в работе web сервиса. Существуют различия в возможностях тонкой настройки балансировщика в бесплатной и платной версии nginx plus. Это один из первых моментов, где я столкнулся с тем, что мне стали необходимы функции платной версии, которых не было в бесплатной. Но цена nginx plus велика.

Я рассмотрю простой пример, где у нас в качестве web сервера выступает nginx, который распределяет запросы на три равноценных сервера. В случае выхода из строя одного из серверов, он все запросы будет адресовать оставшимся в работе серверам. Теоретически это должно проходить незаметно для клиентов. Практически же есть масса нюансов в работе этого инструмента. Постараюсь обо всем этом рассказать.

Алгоритмы балансировки нагрузки

Далее балансировщик выбирает из пула один из серверов согласно одному из алгоритмов. HAProxy поддерживает несколько алгоритмов балансировки.

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

Наиболее распространёнными являются эти алгоритмы:

1. Согласно алгоритму Round Robin (или алгоритм кругового обслуживания) серверы получают трафик последовательно. Балансировщик выбирает первый сервер в списке и передаёт ему первый запрос, второй сервер получит второй запрос и т.д.
2. Балансировщик выбирает для обслуживания трафика наименее загруженный сервер (то есть сервер с наименьшим количеством подключений на текущий момент). Такой алгоритм особенно полезен, если для обслуживания трафика нужны длинные сессии.
3. Балансировщик нагрузки выбирает сервер на основе хэша исходного IP запроса (например, на основе IP-адреса посетителя). При этом все запросы конкретного пользователя будут обслуживаться одним и тем же сервером бэкэнда.

Настройка HAProxy под ваш сервер

Теперь добавьте следующие каталоги и файл статистики для записей HAProxy:

Создайте символьную ссылку для двоичных файлов, чтобы вы могли запускать команды HAProxy от имени обычного пользователя:

Если вы хотите добавить прокси-сервер в систему в качестве службы, скопируйте файл haproxy.init из examples в свой каталог /etc/init.d. Отредактируйте права доступа к файлу, чтобы скрипт выполнялся, а затем перезагрузите демон systemd:

В целях удобства также рекомендуется добавить нового пользователя для запуска HAProxy:

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

В нашем случае версия должна быть 2.0.7, как показано в примере вывода выше.

Наконец, файрвол в CentOS 8 по умолчанию довольно рестриктивен для этого проекта. Используйте следующие команды, чтобы разрешить необходимые службы и перезагрузить файрвол:

Проверка безопасности и параметров

Для корректной работы системы выполним дополнительную настройку системы. После входа в nextcloud под администратором, переходим в настройки для пользователя:

В разделе «Параметры сервера» переходим в Основные сведения:

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

Рассмотрим процесс решения некоторых из них.

1. PHP не настроен правильно для получения переменных системного окружения

Открываем файл php.ini. При нашей установке, это:

vi /etc/php-fpm.d/www.conf

Снимаем комментарий с параметра PATH:

env = /usr/local/bin:/usr/bin:/bin

Перезапускаем php-fpm:

systemctl restart php-fpm

Открываем на редактирование файл:

vi /etc/php.ini

Меняем настройку для memory_limit:

memory_limit = 512M

Перезапускаем php-fpm:

systemctl restart php-fpm

Выполним команду для индексирования баз:

sudo -u apache php /var/www/nextcloud/occ db:add-missing-indices

4. Некоторые индексы базы данных не были преобразованы в тип big int

Выполним команду для преобразования в тип big int:

sudo -u apache php /var/www/nextcloud/occ db:convert-filecache-bigint

На запрос Continue with the conversion отвечаем утвердительно:

Continue with the conversion (y/n)? y

5. В системе не установлены рекомендуемые модули PHP

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

dnf install php-<название модуля>

Установка некоторых модулей может вызвать затрудение. Например, imagick в CentOS 8 устанавливается по инструкции ниже.

Установим ImageMagick:

dnf —enablerepo=PowerTools install ImageMagick ImageMagick-devel

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

dnf install php-devel php-pear make

Собираем imagick:

pecl install imagick

Создаем файл с расширением php:

vi /etc/php.d/20-imagick.ini

extension=imagick.so

Перезапускаем php-fpm:

systemctl restart php-fpm

6. Не загружен модуль OPcache

Устанавливаем модуль opcache командой:

dnf install php-opcache

Открываем конфигурационный файл:

vi /etc/php.d/10-opcache.ini

Редактируем следующее:

…
opcache.max_accelerated_files=10000
…
opcache.save_comments=1
…
opcache.revalidate_freq=1
…

Перезапускаем php-fpm:

systemctl restart php-fpm

7. Не настроена система кеширования

Для решения проблемы мы должны установить и настроить одно из средств кэширования:

• APCu
• Redis
• Memcached

Мы рассмотрим последний вариант. Для этого выполняем установку модуля по инструкции Установка и настройка memcached на CentOS.

После этого открываем конфигурационный файл для nextcloud:

vi /var/www/nextcloud/config/config.php

И добавим:

  …
  ‘memcache.local’ => ‘\\OC\\Memcache\\Memcached’,
  ‘memcache.distributed’ => ‘\\OC\\Memcache\\Memcached’,
  ‘memcached_servers’ =>
  array (
    0 =>
    array (
      0 => ‘localhost’,
      1 => 11211,
    ),
  ),
  …

Настройка СУБД

Заходим в оболочку mysql:

mysql -uroot -p

Смотрим значение для переменной innodb_file_format:

> show variables like ‘innodb_file_format’;

Если видим значение «Antelope», меняем его на Barracuda:

> SET GLOBAL innodb_file_format=Barracuda;

Выходим из оболочки:

> quit

Настройка Nextcloud

Переводим Nextcloud в режим обслуживания:

sudo -u apache php /var/www/nextcloud/occ maintenance:mode —on

Перезагружаем mariadb (если на первом шаге нам пришлось менять значение для переменной innodb_file_format):

systemctl restart mariadb

Редактирование базы данных

Снова подключаемся к консоли управления СУБД:

mysql -uroot -p

Меняем кодировку для базы данных:

> ALTER DATABASE nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

* где nextcloud — имя созданной нами базы данных.

Выходим из mariadb:

> quit

Также задаем новую кодировку для nextcloud

sudo -u apache php /var/www/nextcloud/occ config:system:set mysql.utf8mb4 —type boolean —value=»true»

Преобразуем все таблицы в базе:

sudo -u apache php /var/www/nextcloud/occ maintenance:repair

Завершаем режим обслужавания:

sudo -u apache php /var/www/nextcloud/occ maintenance:mode —off

Балансировка нагрузки на транспортном уровне (layer 4)

Начнем с базовой настройки. Создайте новый файл конфигурации, например, используя vi с командой ниже:

Добавьте в файл следующие разделы. Замените server_name тем, что должно вызывать ваши сервера на странице статистики, а private_ip — приватными IP-адресами серверов, на которые вы хотите направлять веб-трафик. Вы можете проверить приватные IP-адреса на панели управления UpCloud и на вкладке Private network в меню Network.

Это определяет балансировщик нагрузки транспортного уровня (layer 4) с внешним именем http_front, прослушивающий порт 80, который затем направляет трафик к бэкенду по умолчанию с именем http_back. Дополнительная статистика /haproxy?stats подключает страницу статистики по указанному адресу.

Метод балансировки

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

• round-robin — используется по умолчанию. Веб сервер равномерно распределяет нагрузку на сервера с учетом их весов. Специально указывать этот метод в конфигурации не надо.
• least-connected — запрос отправляется к серверу с наименьшим количеством активных подключений. В конфигурации данный параметр распределения запросов устанавливается параметром least_conn.
• ip-hash — используется хэш функция, основанная на клиентском ip адресе, для определения, куда направить следующий запрос. Используется для привязки клиента к одному и тому же серверу. В предыдущих методах один и тот же клиент может попадать на разные серверы.
• hash — задаёт метод балансировки, при котором соответствие клиента серверу определяется при помощи хэшированного значения ключа. В качестве ключа может использоваться текст, переменные и их комбинации.
• random — балансировка нагрузки, при которой запрос передаётся случайно выбранному серверу, с учётом весов.

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

Пример настройки:

upstream cache-api {
    ip_hash;
    server 10.32.18.6:8080;
    server 10.32.18.7:8080;
    server 10.32.18.8:8080;
}

Терминология HAProxy

В балансировке нагрузки и проксировании существует много терминов и понятий. Рассмотрим самые основные из них.

Списки управления доступом (ACL)

В балансировке нагрузки списки управления доступом используются для проверки определённых условий и выполнения действий (например, для выбора сервера, блокировки запроса и т.п.) согласно результату этой проверки. Списки контроля доступа обеспечивают гибкую переадресацию сетевого трафика на основе различных факторов (например, с учётом количества подключений к бэкэнду).

ACL выглядит так:

Такой ACL выполняется, если путь запроса пользователя начинается с /blog (например, http://yourdomain.com/blog/blog-entry-1).

Бэкэнд

Бэкэнд – это набор серверов, которые обрабатывают запросы. Настройки этих серверов находятся в разделе backend конфигурационного файла HAProxy. В основном бэкэнд определяется:

• алгоритмом балансировки нагрузки;
• и списком серверов и портов.

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

Так выглядит настройка двух бэкэндов (web-backend и blog-backend) с двумя серверами в каждом.

• Строка balance roundrobin определяет алгоритм балансировки нагрузки.
• Строка mode http определяет уровень балансировки (в данном случае это уровень 7).
• Опция check в конце директив server настраивает проверку состояния серверов бэкэнда.

Фронтэнд

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

• Наборы IP-адресов и портов (например, 10.1.1.7:80, *:443);
• Списки управления доступом.
• Правила use_backend, которые определяют, какой бэкэнд использовать в зависимости от условий ACL.
• Правила default_backend которые обрабатывают случаи, не отвечающие предыдущим правилам.

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

3: Создание контейнеров

Настройка LXD успешно завершена. Теперь можно создать контейнеры с помощью команды lxc.

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

Команда вернёт:

Сейчас команда lxc взаимодействует с гипервизором LXD впервые; вывод сообщает, что команда автоматически создала сертификат клиента для безопасной связи с LXD. Далее можно найти информацию о том, как запустить контейнер. В конце вывода можно найти пустой список контейнеров.

Создайте три контейнера: два для веб-серверов и один для обратного прокси-сервера. Цель обратного прокси-сервера – перенаправить входящие из Интернета соединения на правильный веб-сервер в контейнере.

С помощью команды lxc launch создайте и запустите контейнер Ubuntu 16.04 по имени web1. Символ x в части команды ubuntu:x – это сокращение от Xenial, кодового имени дистрибутива Ubuntu 16.04; ubuntu: – это идентификатор предварительно настроенного репозитория образов LXD.

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

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

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

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

Вывод после создания первого контейнера:

Теперь у вас есть три пустых контейнера. Чтобы получить информацию о них, введите:

На экране появится таблица, в которой указано имя, состояние, IP и тип каждого контейнера, а также наличие снапшотов контейнеров.

Запишите имена контейнеров и их адреса IPv4.

Настройка балансировки нагрузки на прикладном уровне (layer 7)

Еще одна доступная возможность — настроить балансировщик нагрузки для работы на прикладном уровне (layer 7), что полезно, когда части вашего веб-приложения расположены на разных хостах. Это может быть достигнуто путем регулирования передачи соединения, например, по URL.

Откройте файл конфигурации HAProxy с помощью текстового редактора:

Затем настройте сегменты фронтенд и бэкенд в соответствии с примером ниже:

Фронтенд объявляет правило ACL с именем url_blog, которое применяется ко всем соединениям с путями, начинающимися с /blog. Use_backend определяет, что соединения, соответствующие условию url_blog, должны обслуживаться бэкендом с именем blog_back, а все остальные запросы обрабатываются бэкендом по умолчанию.

Со стороны бэкенда конфигурация устанавливает две группы серверов: http_back, как и раньше, и новую, называемую blog_back, которая обслуживает соединения с example.com/blog.

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

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

Интеграция HAProxy с ClusterControl

ClusterControl интегрирован с HAProxy для упрощения развертывания и управления балансировщиком нагрузки в сочетании с кластерным бэкендом MySQL, таким как Galera или MySQL NDB Cluster. Также можно добавить существующий/уже развернутый экземпляр HAProxy в ClusterControl, чтобы отслеживать и управлять им напрямую из пользовательского интерфейса ClusterControl.

Для настройки HAProxy перейдите в ClusterControl > Manage > Load Balancer > Install HAProxy и введите нужную информацию:

• HAProxy Address. IP-адрес или имя узла HAProxy. ClusterControl должен иметь возможность подключаться по SSH без пароля.
• Listen Port. Порт, который будет прослушивать экземпляр HAProxy. Этот порт будет использоваться для подключения к серверам MySQL с балансировкой нагрузки.
• Policy. Алгоритм балансировки нагрузки. Поддерживаемые значения:
  • lessconn — соединение устанавливается с сервером с наименьшим числом соединений;
  • roundrobin — каждый сервер используется по очереди, в соответствии со своим весом;
  • source — IP-адрес клиента хэшируется и делится на общий вес, поэтому он всегда будет попадать на один и тот же сервер, пока ни один сервер не выйдет из строя или отключится.
• Install from Package Manager. Для Redhat используется диспетчер пакетов YUM. Для Debian используется команда APT.
• Build from Source. Будет использоваться последний доступный пакет исходных кодов:
  • ClusterControl скомпилирует последний доступный исходный пакет, загруженный с .
  • Эта опция требуется только в том случае, когда необходимо использовать последнюю версию HAProxy, или если возникли проблемы с менеджером пакетов дистрибутива ОС. В репозиториях пакетов некоторых старых версий ОС нет HAProxy .
• Overwrite Existing on targets. Если сценарий mysqlchk уже существует, ClusterControl перепишет его. Если сценарий настроен под конкретные потребности, требуется снять этот флажок.
• Show Advanced Settings. Дополнительные настройки:
  • Stats Socket. Расположение файла сокета UNIX для запроса статистики. По умолчанию используется , изменять его не рекомендуется.
  • Admin Port. Порт для доступа к странице статистики HAProxy. По умолчанию 9600.
  • Admin User. Пользователь с правами администратора для доступа к странице статистики.
  • Admin Password. Пароль для пользователя-администратора.
  • Backend Name. Имя обработчика для бэкенда. Без пробелов.
  • Timeout Server. Максимальное время бездействия на стороне сервера заданное в секундах.
  • Timeout Client. Максимальное время бездействия на стороне клиента заданное в секундах.
  • Max Connections Frontend. Максимальное количество одновременных подключений к HAProxy.
  • Max Connection Backend per instance. Ограничение числа подключений, которые могут быть сделаны от HAProxy к каждому серверу MySQL. Соединения, полученные после достижения этого значения, HAProxy поставит в очередь. Рекомендуется установить значение меньше, чем для MySQL, чтобы не допустить переполнения сообщениями.
  • Xinetd allow connections from. Сеть, которой разрешено подключаться к скрипту проверки доступности, выполняемому в рамках xinetd на сервере MySQL.
• Server Instances. Список серверов MySQL в кластере.
• Include. Включить сервер в балансировку нагрузки.
• Role. Выберите, является ли узел активным (Active) или резервным (Backup). В режиме резервного копирования сервер будет использоваться для балансировки нагрузки, только когда все остальные активные серверы недоступны.

Когда поля в диалоговом окне заполнены, нажмите «Install HAProxy», чтобы запустить задание развертывания:

В процессе работы задания ClusterControl выполняет следующие задачи:

• устанавливает вспомогательные пакеты,
• настраивает балансировщик,
• настраивает скрипт mysqlchk (из шаблона) на каждом узле Galera,
• устанавливает и настраивает xinetd в ,
• регистрирует узел HAProxy в ClusterControl.

Отследить прогресс развертывания можно в , как показано в примере ниже:

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

Поскольку при балансировке соединения к серверам MySQL будут открываться не с серверов приложений, а с сервера HAProxy, необходимо добавить права для тех же пользователей, которые используются приложениями, но для IP-адресов, используемых серверами HAProxy:

mysql> GRANT ALL PRIVILEGES ON mydb.* TO 'appuser'@'ha.pr.ox.yip' IDENTIFIED BY 'password';

ClusterControl автоматически перезапускает процесс HAProxy в случае сбоя.

Перенаправление запросов для отсутствующих доменов (перенаправление по умолчанию)

Если обращение к веб-серверу идет по IP-адресу или домену, который не прописан в конфигурационном файле, можно перенаправить весь трафик на домен по умолчанию:

server {
        listen 80 default_server;
        return 302 https://welcome.domain.ru$request_uri;
}

или независимо от протокола:

server {
        listen 80 default_server;
        return 302 $scheme://welcome.domain.ru$request_uri;
}
server {
        listen 443 default_server;
        return 302 $scheme://welcome.domain.ru$request_uri;
        ssl on;
        ssl_certificate /etc/nginx/ssl/cert.pem;
        ssl_certificate_key /etc/nginx/ssl/cert.key;
}

* $scheme позволяет перевести запрос на тот же протокол (http или https), по которому он был инициирован.
* если nginx должен слушать и обрабатывать запросы по https, необходимо указывать в настройках пути к сертификатам.

Сценарии настройки

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

1. Backend на https

Предположим, что наши внутренние серверы отвечают по SSL-каналу. Таким образом, нам нужно отправлять запрос по порту 443. Также схема проксирования должна быть https.

Настройка сайта:

server {
    …
    location / {
        proxy_pass https://dmosk_backend;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
    …
}

* обратите внимание на 2 момента:

1. Мы в схеме подключения proxy_pass указали https. В противном случае при подключении NGINX будет возвращать ошибку 400.
2. Мы задали дополнительные опции proxy_set_header, которых не было в примерах выше. 

Настройка upstream:

upstream dmosk_backend {
    server 192.168.10.10:443;
    server 192.168.10.11:443;
    server 192.168.10.12:443;
}

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

2. Разные бэкенды для разных страниц

Нам может понадобиться разные страницы сайта переводить на разные группы внутренних серверов.

Настройка сайта:

server {
    …
    location /page1 {
      proxy_pass http://backend1;
    }
    location /page2 {
      proxy_pass http://backend2;
    }
    …
}

* при такой настройке мы будем передавать запросы к странице page1 на группу backend1, а к page2 — backend2.

Настройка upstream:

upstream backend1 {
    server 192.168.10.10;
    server 192.168.10.11;
}
upstream backend2 {
    server 192.168.10.12;
    server 192.168.10.13;
}

* в данном примере у нас есть 2 апстрима, каждый со своим набором серверов.

3. На другой хост

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

Настройка сайта:

server {
    …
    location / {
        proxy_pass https://dmosk_backend;
        proxy_set_header   Host             internal.domain.com;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
    …
}

* в данном примере мы будем проксировать запросы на бэкенды, передавая им имя хоста internal.domain.com.

4. TCP-запрос

Рассмотрим, в качестве исключения, TCP-запрос на порт 5432 — подключение к базе PostgreSQL.

Настройка сайта:

server {
    listen 5432;
    proxy_pass tcp_postgresql;
}

* в данном примере мы слушаем TCP-порт 5432 и проксируем все запросы на апстрим tcp_postgresql.

Настройка upstream:

upstream tcp_postgresql {
    server 192.168.10.14:5432;
    server 192.168.10.15:5432;
}

* запросы будут случайным образом передаваться на серверы 192.168.10.14 и 192.168.10.15.

5. UDP-запрос

Рассмотрим также и возможность балансировки UDP-запросов — подключение к DNS по порту 53.

Настройка сайта:

server {
    listen 53 udp;
    proxy_pass udp_dns;
    proxy_responses 1;
}

* в данном примере мы слушаем UDP-порт 53 и проксируем все запросы на апстрим udp_dns. Опция proxy_responses говорит о том, что на один запрос нужно давать один ответ.

Настройка upstream:

upstream udp_dns {
    server 192.168.10.16:53;
    server 192.168.10.17:53;
}

* запросы будут случайным образом передаваться на серверы 192.168.10.16 и 192.168.10.17.

Установка HAProxy на CentOS 8

В силу того, что HAProxy — быстро развивающееся приложение с открытым исходным кодом, дистрибутив, доступный вам в стандартных репозиториях CentOS, может оказаться не самой последней версией. Чтобы узнать актуальную версию, выполните следующую команду:

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

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

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

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

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

Затем скомпилируйте программу под вашу систему:

И, наконец, установите саму HAProxy:

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

Шаг 4 — Конфигурация местоположения

Когда запрос поступает в NGINX, блок местоположения определяет, как обрабатывать и куда направлять трафик. В следующем фрагменте весь трафик на сайт передается в upstream (примечание переводчика: upstream — обычно это сервера приложений) кластер с именем targetCluster. Upstream кластер определяет узлы, которые должны обрабатывать запрос. Мы обсудим это на следующем шаге.

В Envoy этим занимается Filters.

Envoy Filters

Для статической конфигурации фильтры определяют, как обрабатывать входящие запросы. В этом случае мы устанавливаем фильтры, которые соответствуют server_names на предыдущем шаге. Когда поступают входящие запросы, которые соответствуют определенным доменам и маршрутам, трафик направляется в кластер. Это эквивалент восходящей конфигурации NGINX.

Имя envoy.http_connection_manager является встроенным фильтром в Envoy Proxy. Другие фильтры включают Redis, Mongo, TCP. Вы можете найти полный список в .

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

Доступ к файловой базе 1с через интернет в браузере

Теперь перемещаемся на виртуальную машину с nginx. Предварительно не забудьте добавить dns запись в каком-то домене, по которой вы будете ходить в базу через интернет. Она нам нужна, чтобы выпустить бесплатный tls сертификат, чтобы ходить в базу по https. Я не буду привязываться к какой-то конкретной операционной системе и рассказывать, как все делать именно в ней. Систему выбирайте на свой вкус. Настройка будет одинаковой. Нам нужны будут в системе 2 пакета: nginx и certbot. Установите их:

# yum install nginx certbot

или

# apt install nginx certbot

На данную виртуальную машину должны быть проброшены 80 и 443 порты с внешнего ip адреса. Как это будет сделано, зависит от ваших сетевых настроек. В случае с proxmox я настраиваю подобный проброс с самого хоста с помощью iptables. Пример настройки iptables читайте в отдельной статье. Там есть и про проброс. Не буду на этом задерживаться в статье про 1С.

Теперь нам нужно получить сертификат. Для этого запускайте в консоли certbot и следуйте инструкциям. Перед этим остановите nginx. Для быстрого получения сертификата certbot предлагает временно запустить свой веб сервер на 80-м порту.

# systemctl stop nginx
# certbot certonly

Подробно получение сертификата let’s encrypt с помощью certbot я рассматриваю в статье про . Результатом работы certbot должны быть tls сертификаты в директории /etc/letsencrypt/live. Используем их в настройке виртуального хоста nginx для публикации баз 1С. Создаем в директории /etc/nginx/conf.d/ конфиг 1c.site.ru.conf примерно следующего содержания. Взял его с рабочего сервера.

server {
    listen 443 ssl http2;
    server_name 1c.site.ru;
    access_log /var/log/nginx/1c-access.log;
    error_log /var/log/nginx/1c-error.log;

    ssl_certificate /etc/letsencrypt/live/1c.site.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/1c.site.ru/privkey.pem;

    location /.well-known/acme-challenge/ {
    root /tmp;
    }

    location / {
    auth_basic "Restricted Access";
    auth_basic_user_file /etc/nginx/htpasswd.1c;
    proxy_pass http://10.10.10.11:80;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto https;
    }
}

server {
    listen 80;
    server_name 1c.site.ru;
    return 301 https://1c.site.ru$request_uri;
}

В данном случае 10.10.10.11 — локальный ip адрес виртуальной машины с windows, где опубликована база 1С через apache. Доступ к 1С сразу же закрыт отдельным паролем и механизмом веб сервера auth basic. Создадим файл с именем пользователя и паролем, указанным в конфиге.

# htpasswd -c /etc/nginx/htpasswd.1c user1c

Если у вас нет в системе утилиты htpasswd, то установите пакет httpd-tools. Она из него. user1c — имя пользователя. Пароль вам предложат задать в консоли.

Теперь можно запускать nginx и проверять доступ к базе 1с по https с дополнительной авторизацией. Так как в конфиге nginx настроен proxy_pass всех запросов через location / , то на самой виртуалке с 1С вы можете публиковать сколько угодно баз через алиасы, например /buh3, /zup3 и т.д. Все они будут автоматом направляться с nginx на apache. При этом на самом nginx конфигурацию менять не придется.

Вот и все. Можно относительно безопасно выставлять такую конструкцию в интернет. В случае необходимости можно настроить fail2ban, если кто-то надумает перебирать пароли или просто выполнять непонятные запросы к веб серверу с опубликованными базами. При желании в том же nginx с помощью директив allow и deny можно ограничить доступ к виртуальному хосту с базами на уровне ip адресов. Это на случай, если не умеете делать то же самое на фаерволе. В nginx проще и быстрее.

Не забудьте настроить автоматическое обновление tls сертификатов. Как это сделать, я рассказываю в статье с настройкой web сервера. Ссылку на нее я дал выше.

Заключение

Теперь вы знаете, как настроить Apache в качестве обратного прокси-сервера для одного или нескольких внутренних серверов. mod_proxy можно эффективно использоваться для того, чтобы настраивать обратный прокси для серверов с приложениями, написанных на различных языках программирования и технологиях, таких как Python, Django или Ruby и Ruby on Rails. Также mod_proxy можно использовать для балансировки нагрузки между несколькими бэкенд-серверами для сайтов с большой нагрузкой, чтобы обеспечить высокую доступность таких ресурсов.

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

• mod_proxy_ftp для FTP;
• mod_proxy_connect для SSL-туннеля;
• mod_proxy_ajp для протокола AJP (Apache JServ Protocol);
• mod_proxy_wstunnel для веб-сокетов.

Узнать более подробно о них вы можете в официальной документации mod_proxy Apache: http://httpd.apache.org/docs/current/mod/mod_proxy.html