Написанию этого небольшого руководства предшествовало нескольких недель мучений с попытками работы над проектами, когда было необходимо чтобы был запущен контейнер с сайтом для работы, контейнеры с тестовыми сборками, чтобы тестировщики могли безопасно для основных данных проверить новые возможности системы, а так же сборки техподдержке для изучения работы с системой в условиях приближенных к "боевым".
Помимо этого должен был работать служебный web-интерфейс для членов моей группы разработки. При этом часть систем должна работать на одной версии php, часть на другой. При этом есть различия в окружении в котором работают сайты, начиная с операционной системы и http-сервера обрабатывающего запросы, и заканчивая установленными модулями php.
Вроде бы ничего сложного, подними контейнеры и пробрасывай порты наружу. Но для каждого контейнера нужно указать свои внешние порты, которые нужно запоминать, а потом передать их, например, бухгалтеру (это тоже тестировщик), чтобы он проверил доработки в используемой им системе. Иногда я и сам не мог понять, почему только что исправленные скрипты работают не так как положено или почему сайт вообще не открывается.
После раздумий было решено пробрасывать все запросы через HAPRoxy на фронтенде, который доступен по портам 80 и 443, и в зависимости от имени хоста направляет запросы на нужный контейнер.
Конфигурация docker
Начнем настройку с конфигурации 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
Сертификат для работы https
Для работы HAProxy по https необходимо создать самоподписанный сертификат или подключить готовый от удостоверяющего центра.
Создание самоподписанного сертификата
Для создания самоподписанного сертификата необходимо выполнить ряд команд, после которых вы получите файл сертификата который можно использовать для работы HAProxy.
- Создаем приватный ключ (key)
sudo openssl genrsa -out site.key 2048
- Создаем Certificate Signing Request (csr)
sudo openssl req -new -key site.key -out site.csr
- Создаем сам самоподписанный сертификат (crt)
sudo openssl x509 -req -days 365 -in site.csr -signkey site.key -out site.crt
- Объединяем ключ и сертификат (pem)
sudo bash -c 'cat site.key site.crt >> site.pem'
Путь к полученному файлу сертификата необходимо будет прописать в конфигурации HAProxy.
Подготовительны шаги закончены, дальше объединяем все в конфигурациях HAProxy и Docker.
Ниже приведены примеры файлов конфигурации haproxy.cfg и docker-compose.yml.
Подробно останавливаться на каждом пункте конфигураций не буду, они хорошо описаны в документации. Я сделаю только краткие примечания для тех, что еще не использовал HAProxy и docker-compose.
Конфигурация HAPRoxy
Приведенная конфигурация для 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 50000msfrontend 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_coordinatorbackend microbase server microbase 172.20.1.1:80 checkbackend coordinator server coordinator 172.20.1.2:80 check
Конфигурации docker-compose.yml
Для запуска 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.pemnetworks: default: external: name: develop
Тестирование
Тестирование производилось утилитой siege с настройками по умолчанию и с 25 конкурирующими подключениями. Каждый тест был ограничен по времени 1-ой минутой.
siege coordinator.localhost -t 1m
В качестве теста использовался php файл со следующим кодом:
<?phpecho "Hello World!";
Сайты работали под управлением apache 2.4 и php как модуль.
Запуск производился на ноутбуке с процессором Intel Core i5-8250U 1.60GHz, оперативной памятью 8Гб и SSD диском. В качестве системы использовался Linux Mint 20 Cinnamon
Ниже приведены результаты тестирования.
- Запросы на 80 порт без переадресации
Через HAProxy Прямое подключение ** SIEGE 4.0.4** Preparing 25 concurrent users for battle.The server is now under siege...Lifting the server siege...Transactions: 258084 hitsAvailability: 100.00 %Elapsed time: 59.39 secsData transferred: 2.95 MBResponse time: 0.01 secsTransaction rate: 4345.58 trans/secThroughput: 0.05 MB/secConcurrency: 24.72Successful transactions: 258084Failed transactions: 0Longest transaction: 0.04Shortest 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 hitsAvailability: 100.00 %Elapsed time: 59.18 secsData transferred: 3.60 MBResponse time: 0.00 secsTransaction rate: 5315.51 trans/secThroughput: 0.06 MB/secConcurrency: 24.64Successful transactions: 314572Failed transactions: 0Longest transaction: 0.11Shortest transaction: 0.00
Разница в производительности ~18%.
- Запросы на 80 порт с переадресацией на
443 порт
Через HAProxy Прямое подключение ** SIEGE 4.0.4** Preparing 25 concurrent users for battle.The server is now under siege...Lifting the server siege...Transactions: 114804 hitsAvailability: 100.00 %Elapsed time: 59.44 secsData transferred: 0.66 MBResponse time: 0.01 secsTransaction rate: 1931.43 trans/secThroughput: 0.01 MB/secConcurrency: 24.78Successful transactions: 114824Failed transactions: 0Longest transaction: 1.03Shortest 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 hitsAvailability: 100.00 %Elapsed time: 59.80 secsData transferred: 19.99 MBResponse time: 0.01 secsTransaction rate: 2246.89 trans/secThroughput: 0.33 MB/secConcurrency: 24.74Successful transactions: 134374Failed transactions: 0Longest transaction: 0.08Shortest transaction: 0.00
Разница в производительности ~14.5%.
Как и предполагалось, наблюдается падение производительности при использовании решения с HAProxy, но оно не критическое для использования данной конфигурации в процессе разработки сайтов и обеспечения доступа к тестовым сборкам.
Ссылки
HAProxy
- Официальный сайт HSProxy
- Документация по HAProxy
- The Four Essential Sections of an HAProxy Configuration
- Официальный Docker образ HAProxy