[Разработка веб-сайтов, PHP] Использование HAProxy и Docker на машине разработчика при разработке сайтов
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Написанию этого небольшого руководства предшествовало нескольких недель мучений с попытками работы над проектами, когда было необходимо чтобы был запущен контейнер с сайтом для работы, контейнеры с тестовыми сборками, чтобы тестировщики могли безопасно для основных данных проверить новые возможности системы, а так же сборки техподдержке для изучения работы с системой в условиях приближенных к "боевым".
Помимо этого должен был работать служебный 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
Docker
===========
Источник:
habr.com
===========
Похожие новости:
- [CMS, JavaScript, Разработка веб-сайтов, Хостинг] От небольшого вики-портала до хостинга
- [JavaScript, Node.JS, Программирование, Разработка веб-сайтов] Руководство по Express.js. Часть 3 (перевод)
- [Разработка веб-сайтов, Разработка мобильных приложений, Разработка под e-commerce] Каждый третий айтишник в России — самоучка
- [Разработка веб-сайтов, Программирование, Разработка мобильных приложений] Как захватить новую страну за 3 недели
- [JavaScript, Node.JS, Разработка веб-сайтов] Компоновщик в JavaScript (перевод)
- [Разработка веб-сайтов, Python, Программирование, C++] Разработка python module, чтобы продакшн радовал
- [Open source, Разработка веб-сайтов, Обработка изображений, Математика] Конвертируем TeX в SVG: опенсорс-решение в помощь образовательным проектам
- [API, Разработка веб-сайтов, Open source, JavaScript, Микросервисы] Путь к Федеративному GraphQL (перевод)
- [DevOps, Kubernetes, Серверное администрирование, Системное администрирование] Обновлённый анонс обновлённых интенсивов: Kubernetes oт альфы до омеги
- [ReactJS, JavaScript, Разработка веб-сайтов] React: слоты как у сына маминой подруги
Теги для поиска: #_razrabotka_vebsajtov (Разработка веб-сайтов), #_php, #_haproxy, #_docker, #_dockercompose, #_razarbotka_sajtov (разарботка сайтов), #_razrabotka_vebsajtov (
Разработка веб-сайтов
), #_php
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 23:15
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Написанию этого небольшого руководства предшествовало нескольких недель мучений с попытками работы над проектами, когда было необходимо чтобы был запущен контейнер с сайтом для работы, контейнеры с тестовыми сборками, чтобы тестировщики могли безопасно для основных данных проверить новые возможности системы, а так же сборки техподдержке для изучения работы с системой в условиях приближенных к "боевым".  Помимо этого должен был работать служебный 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.
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 Приведенная конфигурация для 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 Ниже приведены результаты тестирования.
Разница в производительности ~18%.
Разница в производительности ~14.5%.
Ссылки HAProxy
Docker =========== Источник: habr.com =========== Похожие новости:
Разработка веб-сайтов ), #_php |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 23:15
Часовой пояс: UTC + 5