Статьи

Балансировка нагрузки — недостающая часть мира контейнеров (часть 2)

Август 31, 2017

В моем предыдущем сообщении в блоге я описал, как легко запустить балансировщик нагрузки с помощью tutum/haproxyизображения. Однако в реальном случае использования требуется больше элементов управления поведением балансировщика нагрузки. Я собираюсь поговорить о некоторых продвинутых темах в этой статье, но перед тем как начать, я хотел бы представить концепцию «службы», которая служит базовым блоком сборки нашего балансировщика нагрузки tutum/haproxy.

Сервис против Контейнера

Что такое сервис?

Служба — это группа контейнеров, которые работают с одинаковыми параметрами на одном и том же образе. Например, если вы запускаете docker run -d tutum/hello-world3 раза, вы можете сказать, что 3 созданных контейнера принадлежат одной и той же службе.

Почему Сервис?

Концепция сервиса идеально соответствует функции балансировщика нагрузки — балансировщик нагрузки отправляет запросы тому же серверу приложений, который является контейнером приложений в мире докеров. Например, если мы свяжем сервис A (содержащий 3 контейнера) и сервис B (содержащий 2 контейнера) с балансировщиком нагрузки, балансировщик нагрузки будет балансировать трафик на 3 контейнерах при доступе к сервису A и на 2 контейнерах при доступе к сервису B соответственно ,

Как настроить сервисы?

  1. Как и в случае с tutum/haproxy, основным строительным блоком Tutum являются сервисы. Это означает, что если вы запускаете свое приложение с помощью Tutum, служба вашего приложения была изначально настроена Tutum.
  2. Если вы работаете tutum/haproxyвне tutum, скажем, используя только docker, псевдоним ссылки вашего контейнера приложения имеет значение. Любой псевдоним ссылки имеет тот же префикс, за которым следует «-», и целое число считается из той же службы. Например, web-1и web-2из службы web, но web1и web2из двух разных служб web1и web2.

Виртуальный хост и виртуальный путь

Виртуальный хост

Когда вы связываете несколько служб веб-приложений tutum/haproxy, вы можете указать переменную среды VIRTUAL_HOSTв службах веб-приложений, чтобы при доступе к балансировщику нагрузки с другим именем хоста вы все равно могли получить доступ к различным службам. Вот пример:

docker run -d --name web1-1 -e VIRTUAL_HOST="www.example.com" <your_app_1>
docker run -d --name web1-2 -e VIRTUAL_HOST="www.example.com" <your_app_1>
docker run -d --name web2 -e VIRTUAL_HOST="app.example.com" <your_app_2>
docker run -d --link web1-1:web1-1 --link web1-2:web1-2 --link web2:web2 -p 80:80 tutum/haproxy

Когда вы получаете доступ http://www.example.com, tutum/haproxyвы переводите ваше первое приложение на балансировку в двух экземплярах, а когда вы получаете доступ app.example.com, вы переходите во второе веб-приложение.

Виртуальный путь

Помимо доменного имени, вы также можете указать haproxy, чтобы он выбирал службы на основе пути к URL, к которому вы обращаетесь. Например, если для вашего приложения установлено значение -e 'VIRTUAL_HOST=*/static/, */static/*, все URL-адреса, с которых начинается путь static, перейдут в этот сервис. Точно так же, если вы укажете -e 'VIRTUAL_HOST=*/*.php, все запросы на URL-адрес, который заканчивается, .phpбудут направлены в вашу службу приложений php.

Для получения дополнительной информации об использовании VIRTUAL_HOST, пожалуйста, смотрите Github: tutum / haproxy .

Сродство и сессионная липкость

Есть три переменных окружения , которые можно использовать , чтобы установить сродство и сеанс липкость в ваших прикладных услугах: BALANCE, APPSESSIONа COOKIE:

  1. Set BALANCE=source. Когда он установлен, HAProxy будет хэшировать IP-адрес посетителя. Это гарантирует, что посетитель с тем же IP-адресом всегда может быть отправлен в один и тот же контейнер приложения. Работает как для tcpрежима, так и для httpрежима.
  2. Set APPSESSION=<appsession>. HAProxy использует сеанс приложения, чтобы определить, к какому контейнеру приложения должен быть направлен посетитель. Работает только для httpрежима. Возможное значение <appsession>может быть JSESSIONID len 52 timeout 3h.
  3. Set COOKIE=<cookie>. Подобно appsession, он использует куки-файлы, чтобы определить, к какому контейнеру приложения должен подключиться посетитель. Возможное значение <cookie>может быть SRV insert indirect nocache.

Проверьте HAProxy: appsession и HAProxy: cookie для получения дополнительной информации.

Прекращение нескольких сертификатов SSL

Как уже упоминалось в предыдущей статье, вы можете активировать завершение SSL, просто добавив SSL_CERTв tutum/haproxy. Но во многих случаях у вас может быть несколько сертификатов SSL, связанных с разными доменами. Например, у вас есть сертификат A с общим именем prod.example.comи сертификат B с staging.example.com. Вы ожидаете, что когда пользователь получает доступ prod.example.com, HAProxy завершает SSL с сертификатом A, а SSL staging.example.comзавершается с сертификатом B. Чтобы достичь этого, вам нужно только установить две переменные среды SSL_CERTи VIRTUAL_HOSTпараметры в службах приложений:

docker run -d --name prod -e SSL_CERT="<cert_A>" -e VIRTUAL_HOST="https://prod.example.com" <prod_app>
docker run -d --name staging -e SSL_CERT="<cert_B>" -e VIRTUAL_HOST="https://staging.example.com" <staging_app>
docker run -d --link prod:prod --link staging:staging -p 443:443 tutum/haproxy

Балансировка загрузки TCP

tutum/haproxyhttpпо умолчанию работает в режиме, но также имеет возможность балансировки нагрузки TCP-соединений с помощью переменных среды, TCP_PORTSустановленных в службе приложения. Ниже приведен пример:

docker run -d --name web -e VIRTUAL_HOST=www.example.com --expose 80 <web_app>
docker run -d --name git -e VIRTUAL_HOST="https://git.example.com" -e SSL_CERT="<cert>" -e TCP_PORTS=22 --expose 443 --expose 22 <git_app>
docker run -d --link web:web --link git:git -p 443:443 -p 22:22 -p 80:80 tutum/haproxy

В приведенном выше примере, когда вы заходите http://www.example.com, вы посещаете свой <web_app>; при доступе https://git.example.comвы перейдете <git_app>с SSL-терминацией. Кроме того, порт 22 доступен по TCP-соединению.

tutum/haproxyтакже поддерживает SSL-терминацию по TCP. Чтобы включить его, вместо настройки TCP_PORTS=22просто установите TCP_PORTS=22/sslвместе с SSL_CERT.

Резюме

В приведенных выше разделах мы представили несколько основных примеров расширенных функций tutum/haproxy. Использование этих функций в сочетании друг с другом может быть очень мощным.

45
Share: