Как настроить контейнеры Docker за балансировщиком нагрузки?

Question

Мой отдел ИТ-инфраструктуры предоставил мне следующую настройку: Балансировщик нагрузки netscaler (lb) перед 3 виртуальными машинами (vm01, vm02, vm03).Каждая виртуальная машина была настроена с IIS.

Я установил Docker Engine на все три виртуальные машины и реплицировал 3 одинаковых контейнера (appcontainer1, appcontainer2, appcontainer3) на все 3 виртуальные машины.Каждый контейнер содержит приложение .NET Core Web API (api1, api2, api3).

Каждый контейнер настроен на предоставление своего порта 80 для доступа к API и сопоставлен с портом на виртуальной машине, где онбежит.Другими словами, appcontainer1 запускается с docker run -p 8091:80 ., appcontainer2 запускается с docker run -p 8092:80 ., а appcontainer3 запускается с docker run -p 8093:80 ..

Проблема, с которой я сталкиваюсь, заключается в том, как я вызываю свои веб-приложения изклиентская машина.Например, если бы я хотел напрямую позвонить ap1 на vm01 , я бы позвонил vm01.domain.com: 8091 , но как мне позвонитьlb.domain.com:8091 и правильно ли он разрешается на одной из виртуальных машин?

Грубо составленный рисованный чертеж ситуации:

• Настроить ли балансировщик нагрузки netscaler для обратного прокси-сервера и перенаправить портнаряду с виртуальными машинами?
• Нужно ли настраивать отдельную запись DNS для приложения (ap1.domain.com, ap2.domain.com, api3.domain.com) и настраивать IIS (или nginx или Apache) на каждой виртуальной машине, чтобы разрешить всоответствующий порт?
• Есть ли способ настроить Docker, чтобы сделать это?
• Я все делаю неправильно и все продумываю?
• Должен ли я использоватьвместо этого какая-то оркестровка контейнеров?
• Есть ли разумный способ сделать это, не мешая команде инфраструктуры переконфигурировать все?

Answer 1

Необходимо настроить каждый IIS на каждой виртуальной машине в качестве обратного прокси-модуля с модулем ARR (Application request маршрутизация).Есть несколько хитростей, которые вы можете использовать (МОЖЕТ Microsoft) во время этого процесса.Я не могу ничего сказать о балансировке нагрузки.Тем не менее, это не должно быть сложно настроить его для равномерного распределения нагрузки на машины.Все, что вам нужно, это сказать LB направить любой вызов lb.domain.com:XXXX на одну из виртуальных машин в циклическом порядке.Вы, вероятно, можете сделать это и для изменения порта, что позволит вам распределять трафик между контейнерами 3VM x3containers = 9.

Однако не рекомендуется выставлять сервер Kestrel в сети.Вместо этого поместите это позади IIS или чего-то еще.А чтобы настроить IIS для работы в качестве обратного прокси-сервера, вы можете либо создать 3 сайта и привязать их к соответствующим портам с минимальной конфигурацией, либо использовать один сайт, использующий IIS, и разрешить входящий запрос с помощью правил перезаписи.Честно говоря, IIS - это боль в использовании с докером.

НО что я на самом деле рекомендую, так это использовать swarm, если ваша ОС поддерживает его, и предоставлять один порт для каждой виртуальной машины.Это одно из:

• WS2019,
• WS2016 1709 или более поздней версии (в них нет графического интерфейса)
• Windows 10 1709 обновлений.

Рой все еще проблематичен в Windows: / Также он имеет очень неприятные, казалось бы, случайные ошибки, связанные с "localhost: PORT" и прочим.Например, я не могу получить доступ к своим контейнерам на моем сервере (WS2016, до 1709), используя комбинацию localhost: PORT.То же самое касается моей машины для разработки (последняя версия Win10), которая только недавно стала проблемой.Это было хорошо, прежде чем «что-то» произошло, и это перестало работать.

Если вы гибко выбираете, какой прокси использовать, я рекомендую взглянуть на nginx, Kubernetes и, если вы на экспериментальной стороне traefik, это позволяет вам уйти без использования инструмента оркестровки контейнера (т. Е. Роя))