Руководтсво администратора/разработчика

Документация

Компоненты/сервисы

Прокси-сервис

Прокси-сервис запускается на одном из хостов и обеспечивает свазаннность всех других работающих сервисов, а также другие сервисные функции.


Для чего

Один из главных связующих сервисов, который отвечает за работу кластера в целом.

  1. Маршрутизация запросов между сервисами
  2. Маршрутизация запросов пользователей для каждого из проектов, запущенного в рамках развернутого кластера Buidbox
  3. REST API для операции с сервисами (остановка/запуск/перезагрузка)
  4. Мониторинг работоспособного состояния сервисов и поддержания заданного количества реплик каждого из сервисов.
  5. Масштабирование кластера при изменении нагрузки на сервисы


Как работает

Прокси-сервис используется только в корневом сервисе, который имеет соответствующие настройки.

Прокси-сервис опрашивает все запущенные дочерние сервисы (Workplace, Api и другие сторонние сервисы) и веб-приложения (Apps) и составляет карту соответствия адресов и портов.

Напомним: Каждый сервис функционирует на отдельном порту и является самостоятельным и независимым сервисом.

Взаимодействие сервисов с прокси возможно в ручном и автоматическом режиме.

В ручном режиме назначения порта, на клиентском сервисе явно прописываются порты, которые будут использованы сервисом (например мы можем указать, что Workplace будет работать на порту 8090). В этом случае необходимо знать какие сервисы на каких портах размещаются, для того, чтобы не было конфликта при запуске сервисов на порты, которые уже запущены. Данный режим подходит для отладки, а также в том случае, если нужно сохранить явную привязку одного из сервисов на порту. Хосты и диапазоны, который указанны в настройках прокси-сервера и которые постоянно сканирует прокси-сервис, должно соответствовать диапазону, из которого запрашивается порт клиентского сервиса, т.е. если мы указали прокси-сервису сканировать диапазон 8000-8100, а укажем порт 8101, то соответственно этот сервис не будет обнаружен прокси-сервисом и информация о нем не попадет в карту маршрутизации.

В автоматическом режиме назначения порта клиентский сервис делает запрос на прокси-сервис с просьбой зарезервировать порт из указанного диапазона (диапазон передается в качестве параметра запроса). Данный диапазон указан по-умолчанию при автоматически при создании сервиса и настраивается администратором.

Если один прокси-сервис обслуживает несколько хостов, то клиентский сервис одного хоста, должен запрашивать резервирование порта из диапазона портов, указанных для данного хоста.


Резервирование порта

При запуске клиентского сервиса в режиме автоматического назначения портов

При автоматическом запуске сервисов, необходимо обеспечить выделение порта, которые не будет пересекаться в дальнейшем на хосте с другими сервисами и не будет занят другим сервисов при старте.

Для этих целей существует механизм резервирование порта на прокси-сервисе в момент старта клиентского сервиса.

Перед стартом сервис отправляет запрос на резервирвоание порта, отправив запрос с указанием того диапазона портов, из которых он готов получить порт.

Прокси-сервис получив запрос на резервирование:

  1. Составляет карту занятых портов на всех опрашиваемых им хостах
  2. Циклически обходит переданный диапазон и проверяет на отсутствие порта в списке занятых портов другими сервисами.
  3. Если порт свободен, заносит в список блокировки с указанием времени снятия блокировки с порта (по-умолчанию 2 минуты)
  4. Если в течение этого интервала клиентский сервис поднялся, прокси успеет его опросить и добавить информацию о новом сервисе в карту портов сервисов, в противном случае данный порт будет отдан другому клиентскому сервису при запросе на резервирование порта.

Внимание! Если на разных хостах используется один и тот же диапазон портов, то при резервировании порт будет занят единожды, т.е. выделен один раз одному из сервисов на хостовой машине и как следствие на другом хосту этот порт использован быть не может (только при ручном назначение)


Настройка

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

При настройке сервера необходимо указать:

  • порт (например: 80) -  порт, на котором ваш сервер будет принимать запросы пользователей и на который может быть настроен внешний прокси-сервер (при необходимости)
  • конфигурации серверов - json-документ, в котором указан список сереров, на которых происходит опрос портов для построения карты.

Настройка прокси-сервиса на опрос двух хостов

[
      {"host":"host1.buildbox.app","portfrom":8100,"portto":8200,"protocol":"http"},
      {"host":"host1.buildbox.app","portfrom":8300,"portto":8500,"protocol":"http"}
]

Здесь настроен один из сервисов в режиме прокси-сервиса, он будет принимать на порту 8080 входящие запросы и обходить порты хостов host1.buildbox.app и host2.buildbox.app на придмет определения работающих на них клиентских сервисов.

Настройка клиентского сервиса

Здесь показано, чо сервис использует автоматическое определения рабочего порта из интервала портов 8100-8200. Запрашивать резервирование порта сервис будет у сервиса buildbox (local) proxy.


Шлюз запуска сервисов

REST API для операций с сервисами

Прокси-сервис выполняет важную задачу - он позволяет запускать/останавливать и перезагружать сервисы на хостах, использую балансировщики нагрузки.

Устроено это так:

В данном примере показан механизм запуска новых сервисов.

1. - входящий запрос на запуск нового сервиса
2. - (красная линия) - прокси опрашивает загрузчики (которые расположены на каждом хосте на предмет нагрузки на сервер). Запрос к Хосту 1 показал, что данный сервер более загружен по ресурсам (интеграционная величина из CPU, память, диск), чем Хост 2.
2. - (зеленая линия) - загрузчик Хоста 2 передал свои показания загруженности ресурсов.
3. - прокси сделал запрос на создание сервиса на более свободном Хосте, отправив на Загрузчик Хоста 2 запрос о создании сервиса.
4. - Загрузчик создал сервис

Механизм перезагрузки осуществляется через завершения и дальнейший запуск сервиса.

Внимание! При перезагрузки сервиса будет происходить естественная ребалансировка (перераспределение) сервисов между хостами исходя из текущего состояния загруженности хостов на момент перезагрузки.

Также существует возможность запуска сервиса на конкретном хосте. Для этого надо отправить запрос не на прокси, а на Загрузчик непосредственного Хоста.

Более подробно с командами запуска/остановки и перезагрузки сервиса можете посмотрет здесь.


Контроль запущенных копий

Гарантированное количество запущенных работоспособных копий (реплик) сервисов

Каждый сервис может иметь параметр, который указывает необходимое количество копий данного сервиса в рамках кластера Buildbox.

Этот параметр может быть указан для каждого сервиса запущенного проекта, а также для приложения или стороннего сервиса.

Например:

Прокси-сервис гарантирует поддержание заданного количества запущенных копий и в случае падения одного из сервисов автоматически поднимает подобный сервис.

Минимальное количество копий сервиса равно один (1). Если вы укажите в параметре "Поддерживать копий" ноль (0), но запустите сервис, то сервис будет запущен в одном экземпляре, о в случае падения сервиса автоматически стартоваться не будет.


Масштабирование кластера

Автоматическое отслеживание нагрузки, поддержание сервисов в рабочем состоянии и масштабирование сервисов

Самой базовой процедурой является поддержание заявленного количества запущенных и работающих процессов. Для этих целей сервис сравнивает заявленное количество копий сервиса с заявленным и в случае необходимости стартует дополнительные копии.

Отметим, что при старте платформы или сервиса всегда стартует одна копия, далее Proxy постепенно увеличивает заданное количество работающих сервисов до необходимого.

Запуск каждой дополнительной копии осуществляется через интервал 10-20 секунд для промежуточного контроля работоспособности кластера.