How to Add New Virtual Hosts
If you have Apache and Nginx web servers, then you need only two backends: one for Apache and one for Nginx.
When you need to add another domain (or sub-domain), you don’t need to add a new backend in HAProxy. Instead, you should create a new virtual host for the new domain (or sub-domain) in Apache or Nginx, then use the directive in HAProxy to redirect traffic to the correct backend.
frontend http bind 12.34.56.78:80 mode http redirect scheme https code 301 frontend https bind 12.34.56.78:443 mode tcp tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } default_backend nginx use_backend nginx if { req_ssl_sni -i domain1.com } use_backend nginx if { req_ssl_sni -i sub.domain1.com } use_backend apache if { req_ssl_sni -i domain2.com } use_backend apache if { req_ssl_sni -i sub.domain2.com } backend nginx mode tcp option ssl-hello-chk server nginx 127.0.0.1:443 check backend apache mode tcp option ssl-hello-chk server apache 127.0.0.2:443 check
I recommend using and as the backend names like in the above code, so you know which web server is hosting which application.
Проверка безопасности и параметров
Для корректной работы системы выполним дополнительную настройку системы. После входа в 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
Установка HAProxy
Данную установку необходимо произвести на каждом сервере с ОС Linux.
- Запустите терминал. Введите команду для установки HAProxy: sudo apt-get install haproxy
- Запустите Midnight Commander с root правами: sudo mc
- Откройте файл /etc/default/haproxy и добавьте строку ENABLED=1 (Эта настройка позволяет автоматически запускать HAProxy при загрузке системы)
-
Отредактируйте файл конфигурации HAProxy: /etc/haproxy/haproxy.cfg используя примеры. Описание настраиваемых параметров:
- log — вести лог в /dev/log сохраняя в «объект» local0.
- chroot — настройки безопасности, «запирающие» HAProxy в указанной директории.
- stats socket — настройки сокета, по которому будет передаваться статистика.
- maxconn — максимальное количество конкурирующих соединений на один процесс.
- user — пользователь, от имени которого будет запущена программа.
- group — группа пользователя, от имени которого будет запущена программа.
- daemon — запуск процесса как демона.
- log — указывает, в какой лог вести записи (global в данном случае означает, что используются параметры, заданные в секции global).
- mode — устанавливает протокол взаимодействия, принимает одно из значений: tcp, http, health.
- retries — количество попыток соединения с сервером в случае отказа.
- option httplog — формат лога, в случае использования HAProxy для проксирования HTTP-запросов, рекомендуется включать данную настройку.
- option redispatch — разрешает программе разорвать и переназначить сессию в случае отказа сервера.
- contimeout — максимальное время ожидания успешного соединения с сервером.
- bind :9000 — означает, что HAProxy будет ожидать запросы к порту 9000.
- stats enable — включить отчеты со статистикой.
- stats uri — установка адреса страницы с отчетом.
- stats auth — логин и пароль для авторизации на странице со статистикой (может быть задано несколько).
-
cookie indeedid_proxy insert indirect nocache — строка сообщает HAProxy, что нужно установить cookie с именем indeedid_proxy. Параметр nocache означает, что этот тип трафика должен быть персональным и не кешировал его.
HAProxy предлагает несколько алгоритмов балансировки, и в зависимости от вашей задачи можно выбрать наиболее подходящий:
- roundrobin — каждый сервер получает запросы пропорционально своему весу, при этом веса серверов могут меняться на лету
- static-rr — то же, что и roundrobin, только изменение весов на лету не даст никакого эффекта
- leastconn — выбирает сервер с наименьшим количеством активных соединений
- first — выбирает первый сервер с доступными слотами для соединения
- source — на основе хэша IP-адреса отправителя запроса и весов серверов назначается сервер для соединения
- uri — сервер выбирается на основе адреса (без параметров) страницы
- url_param — сервер выбирается на основе GET-параметров запроса
- hdr — сервер выбирается на основе заголовков запроса
- rdp-cookie — сервер выбирается на основе cookie (если они не установлены, то применяется обычный round robin)
Дополнительные настройки
Рассмотрим настройки, которые могут оказаться полезными.
Логирование
Открываем конфигурационный файл:
vi /etc/haproxy/haproxy.cfg
Проверяем наличие следующей строки в секции global:
global
…
log 127.0.0.1 local2
* при ее отсутствии, добавляем.
Создаем файл с настройками логов для haproxy:
vi /etc/rsyslog.d/haproxy.conf
local2.* /var/log/haproxy.log
Перезапускаем rsyslog:
systemctl restart rsyslog
Если мы используем Debian или Ubuntu, то также открываем конфигурационный файл rsyslog.conf:
vi /etc/rsyslog.conf
Добавляем, если нет:
…
$ModLoad imudp
$UDPServerRun 514
…
Постоянное HTTP-соединение
По аналогии с keep-alive у NGINX и Apache. В новых версиях HAProxy настроено по умолчанию. В случае необходимости настройки таймаута, в секции defaults правим:
defaults
…
option http-server-close
timeout http-keep-alive 10s
Вопросы от пользователей по engine x
Применяя https через proxy_pass нужно ли производить настройку https бэкенда?
Не обязательно, но возможно у вас есть программное обеспечение, которое не может функционировать в таком формате. Вы получите ссылку http://site.ru:443. Тогда придется осуществить настройку обмена данными между engine x и бэкендом.
Есть два способа реализации. На nginx настраивается nfs сервер и уже затем, на бэкенде можно привязать директорию /etc/letsencrypt. Это позволит использовать сертификаты таким образом, будто они находятся на локальной директории.
Вариант два – использование bash-скрипта. Он будет копировать сертификаты через scp.
На бэкенде службы нужно постоянно перезапускать, после обновления сертификата.
Nginx или haproxy выбрать для проксирования?
Софт похожий по определению, поэтому четкого ответа на заданный вопрос дать невозможно. Но в haproxy есть функционал, который для nginx доступен только в расширенной версии. Выбирать нужно в соответствии с задачей, которую предстоит решить.
Добавляет ли engine x в режиме proxy_pass дополнительные сетевые задержки?
Да, но connect timeout мал, особенно если nginx proxy manager и сервер принадлежат одной и той же локальной сети. В общем, можно пренебречь задержками. При проксировании через интернет – следите за величиной задержки. Желательно, чтобы servers располагались как можно ближе друг к другу.
Шаг 3: изменение изначальных установок для включения прокси
В этой части необходимо внести изменения для того, чтобы изначальный виртуальный хост Apache выполнял роль обратного прокси-сервера для одного или нескольких бэкенд-серверов.
Сначала нужно открыть конфигурационный файл Apache в редакторе nano (или в другом редакторе на ваш выбор):
$ sudo nano /etc/apache2/sites-available/000-default.conf
Внутри этого файла найдите блок с первой строкой <VirtualHost *:80> . Первый пример ниже продемонстрирует, как изменить этот файл так, чтобы использовать обратный прокси для одного бэкенд-сервера, а второй пример – для установки балансировки нагрузки для нескольких бэкенд-серверов.
1 пример: обратное прокси для одного бэкенд-сервера
Скопируйте текст ниже вместо всего текста, расположенного в блоке VirtualHost, то есть чтобы в итоге блок выглядел вот так:
<VirtualHost *:80> ProxyPreserveHost On ProxyPass / http://127.0.0.1:8080/ ProxyPassReverse / http://127.0.0.1:8080/ </VirtualHost>
Если вы продолжаете следовать этому руководству и используете тестовые серверы, которые создали ранее, то скопируйте 127.0.0.1:8080, как и написано в примере. Если у вас есть свои собственные серверы приложений, то используйте их адреса.
В блоке используется три директивы:
- ProxyPreserveHost – заставляет Apache передать оригинальный заголовок Host бэкенд-серверу. Это полезно, так как в этом случае бэкенд-сервер получает адрес, который используется для доступа к приложению;
- ProxyPass – основная директива для настройки прокси. В данном случае она указывает, что все, что идет после корневого адреса URL (/), должно быть отправлено на бэкенд-сервер по указанному адресу. Например, если Apache получит запрос /primer, то он подключится к http://ваш_бэкенд-сервер/primer и отправит соответствующий ответ;
- ProxyPassReverse – должна иметь такие же настройки, как и ProxyPass. Она сообщает Apache, как изменить заголовки в ответе от бэкенд-сервера. Таким образом гарантируется, что браузер клиента будет перенаправлен на прокси-адрес, а не на адрес бэкенд-сервера.
После внесения изменений Apache необходимо перезапустить:
$ sudo systemctl restart apache2
Теперь, если вы наберете в браузере адрес своего сервера, вы увидите ответ от вашего бэкенд-сервера вместо приветственной страницы Apache.
2 пример: балансировка нагрузки между несколькими бэкенд-серверами
Если у вас есть несколько бэкенд-серверов, будет хорошей идеей при использовании прокси распределить трафик между ними; сделать это можно при помощи функции балансировки нагрузки утилиты mod_proxy.
Как и в первом примере, тут вам тоже необходимо заменить текст в блоке VirtualHost на следующий:
<VirtualHost *:80> <Proxy balancer://mycluster> BalancerMember http://127.0.0.1:8080 BalancerMember http://127.0.0.1:8081 </Proxy> ProxyPreserveHost On ProxyPass / balancer://mycluster/ ProxyPassReverse / balancer://mycluster/ </VirtualHost>
В целом текст похож на предыдущий, однако вместо указания одного бэкенд-сервера появляется новый блок Proxy, в котором указано несколько серверов. Блок называется balancer://mycluster (название можно изменить) и состоит из одного или нескольких BalancerMembers, которые определяют адреса лежащих в основе бэкенд-серверов.
Директивы ProxyPass и ProxyPassReverse используют пул балансировки нагрузки под названием mycluster вместо конкретного сервера.
Вы можете использовать адреса тестовых серверов (как указано выше), либо заменить их на адреса своих серверов.
Для того, чтобы изменения вступили в силу, перезапустите Apache:
$ sudo systemctl restart apache2
Теперь проведите такой же тест, как и в первом примере: введите IP-адрес вашего сервера в браузер и вместо стандартного приветствия Apache вы увидите один из ответов бэкенд-серверов. Если вы используете тестовые серверы, то это будет либо “Hello world!”, либо “Hello Timeweb!”. Обновите страницу несколько раз и, если вы увидели оба текста, значит все работает корректно.
Практическое пошаговое руководство, в шесть шагов
В этом базовом примере демонстрируется NGINX и swarm в действии, показана основная концепция используемая в девопс.
В этом документе проходит несколько этапов настройки контейнерного сервера NGINX и его использования для балансировки трафика в кластере. Для ясности эти шаги разработаны как руководство по настройке кластера с тремя узлами и запуску двух служб докеров в этом кластере; Завершив это упражнение, вы познакомитесь с общим рабочим процессом, необходимым для использования swarm режима и балансировки нагрузки между конечными точками Windows Container, используя балансировщик нагрузки NGINX.
Базовая установка
Это упражнение требует наличия трех контейнерных хостов, два из которых будут объединены в кластер кластера с двумя узлами , а другой будет использоваться для размещения балансировщика нагрузки в контейнере NGINX. Чтобы продемонстрировать балансировщик нагрузки в действии, две кластерные службы будут развернуты в кластере swarm, а сервер NGINX будет настроен на балансировку нагрузки между экземплярами контейнера, которые определяют эти службы. Сервисы будут как веб-сервисами, так и хостингом контента, который можно просматривать через веб-браузер. С помощью этой настройки балансировщик нагрузки легко продемонстрировать в работе, поскольку трафик маршрутизируется между двумя службами каждый раз, когда просмотр веб-браузера с отображением их содержимого обновляется.
На рисунке ниже представлена визуализация этой установки из трех узлов. Два из узлов, узел «Swarm Manager» и узел «Swarm Worker» вместе образуют кластер двухуровневого swarm режима кластера, запускающий две веб-службы «Docker», «S1» и «S2». Третий узел («Host NGINX» на рисунке) используется для размещения контейнерного балансировщика нагрузки NGINX, а балансировщик нагрузки настроен для маршрутизации трафика через конечные точки контейнера для двух сервисов контейнера. Эта цифра включает в себя пример IP-адресов и номеров портов для двух хостов swarm и для каждой из шести конечных точек контейнера, запущенных на хостах.
Системные Требования
Три или более компьютерных систем, работающих под управлением Windows 10 Creators Update (доступных сегодня для пользователей программы Windows Insiders ), настраиваются как контейнерные узлы (см. Раздел «Контейнеры Windows в Windows 10» для получения дополнительной информации о том, как начать работу с контейнерами Docker Windows 10).
Кроме того, каждая система хоста должна быть сконфигурирована со следующим:
- Образ контейнера microsoft windowsservercore
- Docker Engine v1.13.0 или новее
- Открытые порты: в режиме «SWARM» для каждого хоста должны быть доступны следующие порты.
- TCP-порт 2377 для обмена данными по управлению кластером
- TCP и UDP-порт 7946 для обмена данными между узлами
- TCP и UDP-порт 4789 для наложения сетевого трафика
* Обратите внимание на использование двух узлов, а не трех:Эти инструкции могут быть выполнены, используя только два узла. Однако в настоящее время в Windows существует известная ошибка, которая запрещает контейнерам получать доступ к их хостам, используя localhost или даже внешний IP-адрес хоста (более подробно об этом см
Ниже в разделах Caveats and Gotchas). Это означает, что для доступа к службам докеров через их открытые порты на swarm узлах балансировщик нагрузки NGINX не должен находиться на том же хосте, что и любой из экземпляров контейнера службы.Другими словами, если для выполнения этого упражнения вы используете только два узла, один из них должен быть выделен для размещения балансировщика нагрузки NGINX, а другой использоваться как контейнер контейнеров swarm (т. Е. У вас будет один хост swarm кластер, хост, предназначенный для размещения вашего контейнерного балансировщика нагрузки NGINX).
Benefits and drawbacks of using HAProxy
HAProxy is another open source load balancing solution. As it is a single-purpose solution in that it only offers load-balancing capabilities, it is much more focused on that one aspect compared to Nginx. Below are a few benefits and drawbacks to using HAProxy.
Benefits:
- Provides a comprehensive list of 61 different metrics. See section 9 for a full list of available statistics
- The status page is much more detailed and user-friendly as compared to Nginx’s
- Easily able to integrate with third party monitoring services (e.g. Datadog)
Drawbacks:
Does not provide other features that Nginx offers such as web server capabilities
HAProxy is quite thorough in terms of metrics it provides. Of course, since it is only a load balancing software you can’t use it for other purposes as you can with Nginx.
Заключение
Мне не приходилось пробовать в деле никаких других балансировщиков, кроме Nginx. Знаю, что есть haproxy, но попробовать так и не дошли руки. Бесплатная версия nginx очень слабо подходит для полноценной балансировки крупного проекта, либо я просто не понимаю, как его правильно использовать. Реально не хватает тех фич, которые есть в Nginx Plus. До того момента, как не начал использовать балансировщик, не понимал толком, что там такого в платной версии. Теперь прекрасно понимаю
Готовые примеры балансировки с использованием фич Nginx Plus приведены в этой статье
Так же обращаю внимание на формат логов, который для удобства стоит подправить под использование бэкендов. Этот вопрос я рассмотрел отдельно в статье про мониторинг производительности бэкендов с помощью elk stack
Буду рад любым комментариям, ссылкам, советам по существу затронутой темы. Я в ней новичок. Ни на что не претендую, поделился своим опытом.
Если у вас есть желание научиться администрировать системы на базе Linux, но вы с ними никогда не работали и не знакомы, то рекомендую начать с онлайн-курса «Linux для начинающих» в OTUS. Курс для новичков, для тех, кто с Linux не знаком. Цена за курс минимальная (символическая). Информация о курсе и цене.