Назад | Перейти на главную страницу

Nginx с сервером приложений для балансировки нагрузки докеров (php)

Я пока не нашел решения, поэтому спрашиваю здесь:

Это ситуация, в которой я блокирую решение для:

Мы планируем архитектуру, которая содержит следующие компоненты

  1. Контейнер Docker (автоматическая балансировка нагрузки, если этого требует нагрузка) Сервер приложений, который обрабатывает входящие данные (импорт, внутреннее хранилище, веб-API)
  2. Сервер очереди
  3. Контейнер Docker (автоматическая балансировка нагрузки по мере необходимости) Приложение, которое обрабатывает каждый элемент в очереди и сохраняет его на эластичном сервере поиска и в базе данных MySQL (ES используется для запросов и вывода для клиентов)
  4. Docker Container (автоматическая балансировка нагрузки, если этого требует нагрузка) Приложение, обрабатывающее сбор исходящих данных

У меня почти все полностью настроено. Единственное, для чего у меня нет решения, это балансировка нагрузки на Frontend (Frontend Nginx Server). Мне это нужно только для связи с 1 и с 4. Их количество может варьироваться, поэтому Nginx должен знать, сколько контейнеров существует. Обработка сеансов работает (Redis Backend) (протестировано с балансировкой нагрузки на 8 серверах приложений и инструментом стресс-тестирования). Но я понятия не имею, как обрабатывать связь между различным количеством серверов приложений и Nginx. Если бы кто-нибудь мог дать мне подсказку, как это настроить. Любой ключ к решению этой проблемы приветствуется.

Крис

opensvc предлагает решение для этого https://docs.opensvc.com/latest/agent.configure.gobtw.html

на главной странице есть демонстрация такого кластера

Почему я предлагаю это решение:

  • opensvc кластер можно настроить для использования частного решения для управления DNS в масштабе кластера. На основе PowerDNS кластер поддерживает записи DNS всех opensvc сервисы, развернутые в кластере. Как только создается новый док-контейнер, новый SRV записи появляются в карте DNS.

  • в такой настройке вам также необходимо развернуть cni+weave иметь частный растянутый сетевой IPAM, работающий по всему кластеру, чтобы предоставлять частный IP-адрес новым контейнерам.

  • opensvc Завершите картину развертыванием входного шлюза. С одной стороны, он содержит общедоступный IP-адрес, к которому подключаются конечные пользователи приложения, а с другой стороны, он поддерживает список всех контейнеров докеров, фактически обслуживающих приложение.

  • Все это делается динамическим путем добавления opensvc janitoring docker-контейнер, который прослушивает события кластера (например, «новый контейнер создан») и автоматически настраивает входной шлюз для добавления еще одного docker-контейнера в бэкэнд.