- PVSM.RU - https://www.pvsm.ru -
Написанию этого небольшого руководства предшествовало нескольких недель мучений с попытками работы над проектами, когда было необходимо чтобы был запущен контейнер с сайтом для работы, контейнеры с тестовыми сборками, чтобы тестировщики могли безопасно для основных данных проверить новые возможности системы, а так же сборки техподдержке для изучения работы с системой в условиях приближенных к "боевым".
Помимо этого должен был работать служебный web-интерфейс для членов моей группы разработки. При этом часть систем должна работать на одной версии php, часть на другой. При этом есть различия в окружении в котором работают сайты, начиная с операционной системы и http-сервера обрабатывающего запросы, и заканчивая установленными модулями php.
Вроде бы ничего сложного, подними контейнеры и пробрасывай порты наружу. Но для каждого контейнера нужно указать свои внешние порты, которые нужно запоминать, а потом передать их, например, бухгалтеру (это тоже тестировщик), чтобы он проверил доработки в используемой им системе. Иногда я и сам не мог понять, почему только что исправленные скрипты работают не так как положено или почему сайт вообще не открывается.
После раздумий было решено пробрасывать все запросы через HAPRoxy на фронтенде, который доступен по портам 80 и 443, и в зависимости от имени хоста направляет запросы на нужный контейнер.
Начнем настройку с конфигурации docker сети, потому что нам нужен контроль над сетевыми адресами которые будут выделены контейнерам.
Создаем docker сеть с указанием подсети. Указать подсеть необходимо для направления запросов с HAProxy на определенные ip-адреса чтобы не было проблем с разрешением имен доменов, если какой-то из контейнеров не запущен.
docker network create develop --subnet=172.20.0.0/16
Чтобы запускаемые контейнеры работали в нужной нам сети и получали ip адреса из нее в docker-compose.yml будем напрямую указывать сеть:
networks:
default:
external:
name: develop
а в конфигурации контейнеров, на которые будут перенаправляться запросы с HAProxy, жестко задавать ip-адрес.
networks:
default:
ipv4_address: 172.20.1.1
Для работы HAProxy по https необходимо создать самоподписанный сертификат или подключить готовый от удостоверяющего центра.
Для создания самоподписанного сертификата необходимо выполнить ряд команд, после которых вы получите файл сертификата который можно использовать для работы HAProxy.
sudo openssl genrsa -out site.key 2048
sudo openssl req -new -key site.key -out site.csr
sudo openssl x509 -req -days 365 -in site.csr -signkey site.key -out site.crt
sudo bash -c 'cat site.key site.crt >> site.pem'
Путь к полученному файлу сертификата необходимо будет прописать в конфигурации HAProxy.
Подготовительны шаги закончены, дальше объединяем все в конфигурациях HAProxy и Docker.
Ниже приведены примеры файлов конфигурации haproxy.cfg и docker-compose.yml.
Подробно останавливаться на каждом пункте конфигураций не буду, они хорошо описаны в документации. Я сделаю только краткие примечания для тех, что еще не использовал HAProxy и docker-compose.
Приведенная конфигурация для HAProxy перенаправляет все запросы с порта 80 на порт 443, а затем, основываясь на имени запрошенного хоста, направляет на один из сайтов которые работают по 80 порту. Для сайтов нет необходимости настраивать работу по https.
Запросы пришедшие на 443 порт будут сразу направлены на соответствующие сайты.
В понятиях HAProxy разделы описанные как frontend представляют внешние интерфейсы, куда приходят запросы.
В настройках frontend указываются условия, при удовлетворении которым запрос будет переадресован на заданный backend.
Backend, соответственно, интерфейсы куда запросы перенаправляются.
Раздел defaults задает общие параметры для всех разделов описанных в конфигурации.
По умолчанию в официальных docker образах HAProxy файл конфигурации располагается в /usr/local/etc/haproxy/haproxy.cfg
defaults
mode http
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
frontend http_frontend
bind *:80
redirect scheme https if !{ ssl_fc }
frontend https_frontend
bind *:443 ssl crt /etc/ssl/certs/site.pem
acl is_microbase hdr_end(host) -i microbase.localhost
use_backend microbase if is_microbase
acl is_coordinator hdr_end(host) -i coordinator.localhost
use_backend coordinator if is_coordinator
backend microbase
server microbase 172.20.1.1:80 check
backend coordinator
server coordinator 172.20.1.2:80 check
Для запуска docker контейнеров будем использовать docker-compose, что позволит описать все необходимые настройки в одном или в нескольких yml файлах конфигурации которые можно будет объединить при запуске.
Приведенная конфигурация запускает контейнеры для сайтов microbase.localhost и coordinator.localhost на которые будут направлены запросы с HAProxy.
Так же в конфигурации задан контейнер c самим HAProxy который будет обрабатывать запросы.
По умолчанию docker-compose будет использовать файл docker-compose.yml в папке из которой запущен.
Передать имя другого файла можно при помощи параметра -f.
При вызове docker-compose может быть указано несколько параметров -f. При этом, каждый последующий файл конфигурации будет дополнять предыдущие.
version: "3"
services:
microbase:
image: "inblank/php7.4-apache"
volumes:
- ./microbase:/var/www
networks:
default:
ipv4_address: 172.20.1.1
coordinator:
image: "inblank/php7.4-apache"
volumes:
- ./coordinator:/var/www
networks:
default:
ipv4_address: 172.20.1.2
haproxy:
image: "haproxy:2.2-alpine"
ports:
- 80:80
- 443:443
volumes:
- ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg
- ./cert.pem:/etc/ssl/certs/site.pem
networks:
default:
external:
name: develop
Тестирование производилось утилитой siege с настройками по умолчанию и с 25 конкурирующими подключениями. Каждый тест был ограничен по времени 1-ой минутой.
siege coordinator.localhost -t 1m
В качестве теста использовался php файл со следующим кодом:
<?php
echo "Hello World!";
Сайты работали под управлением apache 2.4 и php как модуль.
Запуск производился на ноутбуке с процессором Intel Core i5-8250U 1.60GHz, оперативной памятью 8Гб и SSD диском. В качестве системы использовался Linux Mint 20 Cinnamon
Ниже приведены результаты тестирования.
Через HAProxy | Прямое подключение |
---|---|
** SIEGE 4.0.4 ** Preparing 25 concurrent users for battle. The server is now under siege... Lifting the server siege... Transactions: 258084 hits Availability: 100.00 % Elapsed time: 59.39 secs Data transferred: 2.95 MB Response time: 0.01 secs Transaction rate: 4345.58 trans/sec Throughput: 0.05 MB/sec Concurrency: 24.72 Successful transactions: 258084 Failed transactions: 0 Longest transaction: 0.04 Shortest transaction: 0.00 |
** SIEGE 4.0.4 ** Preparing 25 concurrent users for battle. The server is now under siege... Lifting the server siege... Transactions: 314572 hits Availability: 100.00 % Elapsed time: 59.18 secs Data transferred: 3.60 MB Response time: 0.00 secs Transaction rate: 5315.51 trans/sec Throughput: 0.06 MB/sec Concurrency: 24.64 Successful transactions: 314572 Failed transactions: 0 Longest transaction: 0.11 Shortest transaction: 0.00 |
Разница в производительности ~18%.
Через HAProxy | Прямое подключение |
---|---|
** SIEGE 4.0.4 ** Preparing 25 concurrent users for battle. The server is now under siege... Lifting the server siege... Transactions: 114804 hits Availability: 100.00 % Elapsed time: 59.44 secs Data transferred: 0.66 MB Response time: 0.01 secs Transaction rate: 1931.43 trans/sec Throughput: 0.01 MB/sec Concurrency: 24.78 Successful transactions: 114824 Failed transactions: 0 Longest transaction: 1.03 Shortest transaction: 0.00 |
** SIEGE 4.0.4 ** Preparing 25 concurrent users for battle. The server is now under siege... Lifting the server siege... Transactions: 134364 hits Availability: 100.00 % Elapsed time: 59.80 secs Data transferred: 19.99 MB Response time: 0.01 secs Transaction rate: 2246.89 trans/sec Throughput: 0.33 MB/sec Concurrency: 24.74 Successful transactions: 134374 Failed transactions: 0 Longest transaction: 0.08 Shortest transaction: 0.00 |
Разница в производительности ~14.5%.
Как и предполагалось, наблюдается падение производительности при использовании решения с HAProxy, но оно не критическое для использования данной конфигурации в процессе разработки сайтов и обеспечения доступа к тестовым сборкам.
Автор: Павел Александров
Источник [8]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/php-2/356925
Ссылки в тексте:
[1] Официальный сайт HSProxy: https://www.haproxy.com
[2] Документация по HAProxy: https://www.haproxy.com/documentation/hapee/
[3] The Four Essential Sections of an HAProxy Configuration: https://www.haproxy.com/blog/the-four-essential-sections-of-an-haproxy-configuration/
[4] Официальный Docker образ HAProxy: https://hub.docker.com/_/haproxy
[5] Официальный сайт Docker: https://www.docker.com/
[6] Официальная страница docker-compose: https://docs.docker.com/compose/
[7] Docker Compose file version 3 reference: https://docs.docker.com/compose/compose-file/
[8] Источник: https://habr.com/ru/post/518930/?utm_source=habrahabr&utm_medium=rss&utm_campaign=518930
Нажмите здесь для печати.