Запуск и завершение работы приложения на основе активности пользователя, прошедшего проверку подлинности

На предприятиях есть приложения и службы, которые не нужно запускать постоянно и которые имеют ограниченную пользовательскую базу (скажем, несколько человек).

Эти приложения можно закрывать и запускать либо по расписанию, либо по активности пользователя. Итак, мы говорим о сервисе по требованию (скажем, обернутом контейнером) и запуске и завершении работы узла.

Теперь, во-первых, упомянем, что причина, по которой я упоминаю аутентифицированную активность пользователя, заключается в том, что имеет смысл запускать и выключать на этой основе (т.е. не на основе сетевого трафика более низкого уровня). Можно представить себе корпоративный SSO (скажем, на основе OAuth 2).

Итак, мой вопрос: пытался ли кто-нибудь реализовать то, что я описал, с помощью Consul или Kubernetes?

В случае с Consul может быть так, что хранилище ключей-значений может использоваться для предоставления приложениям класса «Micro» (т. е. небольшой пользовательской базы) TTL, каждый раз, когда аутентифицированный пользователь запрашивает доступ к данному приложению класса «Micro». ТТЛ обновляется. В течение окна TTL мы хотим проверить работоспособность узлов, контейнеров и сервисов — вне окна мы этого не делаем (поскольку мы хотим сэкономить на операционных расходах).

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


person Nico de Wet    schedule 04.01.2016    source источник
comment
Если вы хотите управлять запуском/остановкой служб на основе аутентифицированных действий пользователя, имеет смысл реализовать это с помощью веб-перехватчиков.   -  person number5    schedule 05.01.2016
comment
На данном этапе, на стороне выключения, похоже, что зонд контейнера Kubernetes, который исследует соответствующую конечную точку HTTP (например, конечные точки Spring Boot Actuator), может быть одним из возможных действий. Конечная точка будет отображать количество аутентифицированных пользователей. Зонд должен быть с отслеживанием состояния, хотя для варианта использования отключения на основе TTL. Что касается выключения, то на жаргоне Kurbernetes мы бы либо закрыли один контейнер, либо под (набор контейнеров). Нужно продумать сценарий вебхуков.   -  person Nico de Wet    schedule 05.01.2016


Ответы (1)


В случае Kubernetes Документация по автомасштабированию Horizontal Pod содержит точный вариант использования, описанный в разделе Дальнейшие шаги. (т. е. эта функция находится в очереди и может быть реализована после версии 1.1. Kubernetes). Описание цитируемой функции (предложение Unidling) выглядит следующим образом:

Масштабируйте количество модулей, начиная с 0. Все модули можно отключить, а затем включить, когда в них возникнет потребность. Когда поступает запрос на обслуживание без модулей, kube-proxy создаст событие для автомасштабирования для создания нового модуля.

Так что, в принципе, то, что я описал, можно будет сделать в будущем с помощью Kubernetes, но сейчас это невозможно. Само по себе это не относится к требованию масштабирования только от 0 на основе активности пользователя, прошедшего проверку подлинности.

Стоит отметить, что независимо от кластера, on-demand активация контейнера на основе systemd. Это решение, конечно, не уменьшится до 0 без контролирующего процесса, но все же стоит отметить.

person Nico de Wet    schedule 06.01.2016