Написанию этого небольшого руководства предшествовало нескольких недель мучений с попытками работы над проектами, когда было необходимо чтобы был запущен контейнер с сайтом для работы, контейнеры с тестовыми сборками, чтобы тестировщики могли безопасно для основных данных проверить новые возможности системы, а так же сборки техподдержке для изучения работы с системой в условиях приближенных к "боевым".
Помимо этого должен был работать служебный 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 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-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.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
Ниже приведены результаты тестирования.
- Запросы на 80 порт без переадресации
Через 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%.
- Запросы на 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 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, но оно не критическое для использования данной конфигурации в процессе разработки сайтов и обеспечения доступа к тестовым сборкам.
Ссылки
HAProxy
- Официальный сайт HSProxy
- Документация по HAProxy
- The Four Essential Sections of an HAProxy Configuration
- Официальный Docker образ HAProxy
devopg
как понимаю это нафик не нужно исли используешь докер сварм, там автоматическая балансировка идет сервисов
inblank Автор
Мне кажется, что swarm это не то. Была нужна не кластеризация с балансировкой трафика, а доступ к нескольким сервисам по одному
внешнему интерфейсу и порту. Для каждого сервиса используется свой docker образ (где на базе php 5.6, где на 7.4) и свои тома,
проброшенные на локальные папки хост машины, но хост машина одна. Как переправить трафик с 80 порта хост системы в один из
работающих контейнеров с рамках swarm? Я пока не понимаю.
Apokalepsis
Если для каждого сервиса используется своя сборка — не рассматривали использование — jwilder/nginx-proxy? Я им закрыл туже задачу + легко прикручивается автоматическая выдача сертификатов letsencrypt.
inblank Автор
Да, по советам в комментариях смотрю jwilder/nginx-proxy и traefik. Спасибо.