2017-01-11 4 views
0

При попытке переноса приложения, которое работает на докере, Swarm локально в Azure Container Service. Я поражен частью балансировки нагрузки Azure. Локально у меня есть экземпляр контейнера HAproxy, работающий на Swarm Master и несколько веб-контейнеров. Веб-контейнеры только что открыли порты, и они не отображаются на машинах, на которых они работают. Контейнер HAproxy сопоставил порт с мастером и внутренне разговаривает с моими веб-контейнерами для балансировки нагрузки. Это дает мне рычаги для запуска любого количества контейнеров с ограниченным числом рабочих в Docker Swarm. В лазурном сервисе контейнера я вижу, что балансировщик нагрузки Azure будет разговаривать только с отображаемыми портами, это означает, что я могу запускать только один контейнер на одного агента или я сохраняю внутренний контейнер нагрузки в своих контейнерах, что подразумевает, что пользователи будут проходить через 2 балансировщика нагрузки, прежде чем ударить мое приложение.Azure Container Services Port Load Balancer

Не идеальный сценарий, когда мое приложение использует липкие сеансы. Итак, очевидно, что заявление Microsoft «Все работает так же в контейнерах Azure» идет за броском? Каковы доступные решения или я делаю что-то неправильно здесь?

Привет, Harneet

+0

Если у вас есть два агента, у вас будет два vms в пуле агентов, а не два контейнера в пуле. Поэтому я думаю, что у вас может быть много контейнеров и правильно выбрать ресурсы виртуальных машин для агентов, для которых вам понадобится возможность - И после этого пусть ACS предоставит LB обработку балансировки без необходимости HAProxy. – hB0

ответ

0

Раствор в ACS практически идентичны. Используйте HAProxy и поговорите с Azure LB. Единственное различие заключается в том, что вы не будете запускать прокси-сервер на хозяине, у вас будет Swarm, разверните его для агента для вас.

Вы не должны действительно загружать рабочие нагрузки на своих мастеров. Что бы вы сделали, если у вас есть DDoS-атака и, к примеру, не можете связаться со своими мастерами. Наличие Swarm для развертывания прокси-сервера означает, что вы также можете настроить swarm для проверки работоспособности прокси-сервера.

Вы могли бы, если бы вы действительно захотели, запустить прокси-сервер на главном компьютере, как и сейчас. Решение будет таким же, если Azure LB обеспечивает публичное соединение с прокси-сервером так же, как и в настоящее время.

+0

Это не звучит слишком убедительно, каждый запрос передается через 2 балансировщика нагрузки перед ударом по фактическому веб-приложению. Также, что происходит с несколькими приложениями в кластере, можно добавить несколько балансировщиков нагрузки в Azure для прослушивания разных приложений в одном рою. –

+0

Ну, трафик должен как-то попасть в сети Azure. Мы обнаруживаем, что большинство клиентов торгуют дополнительным сетевым хопом для возможности переноса загрузок контейнеров в любую инфраструктуру. Тем не менее, те клиенты, которые хотят минимизировать сетевые перелеты, могут использовать Azure Traffic Manager, который будет LB через отдельные контейнеры в кластере. – rgardler

+0

К сожалению, я должен был также упомянуть Application Gateway как опцию, так как это дешевле ;-) – rgardler

Смежные вопросы