Развертывание в контейнерах

Контейнерная модель развертывания Astra Automation использует виртуальные машины или физические серверы, на которых компоненты платформы запускаются в контейнерах. Такая модель не требует Kubernetes и подходит для инфраструктур, где нужно использовать контейнеры без внедрения отдельного кластера оркестрации.

В зависимости от требований бизнеса рекомендуется выбрать наиболее подходящую проверенную топологию.

Примечание

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

Сравнение топологий

Сравнение топологий развертывания платформы поможет принять правильное решение для вашего бизнеса.

Топология	Количество ВМ	Ключевые компоненты	Область применения
Базовая (Growth)	1	Все компоненты на одной ВМ: - Platform Gateway - Automation Controller - Private Automation Hub - Event-Driven Automation - PostgreSQL - Redis - Execution container	- Начальное внедрение - Демонстрационная или тестовая среда - Малые рабочие среды без требований к отказоустойчивости - Быстрое развертывание без Kubernetes
Уровень предприятия (Enterprise)	13+	Распределение контейнеров: - Дублирование основных компонентов - Внешняя СУБД PostgreSQL - Распределенная конфигурация Redis - Внешний балансировщик нагрузки - Исполняющие и промежуточные узлы сети Mesh	- Критически важные системы - Высокая доступность - Крупномасштабная автоматизация - Распределенное исполнение заданий - Соответствие корпоративным стандартам

Базовая топология

Базовая контейнерная топология обычно предполагает последующее масштабирование до уровня Enterprise (модель Growth). В этой топологии все компоненты платформы и служебные сервисы размещаются на одной виртуальной машине и запускаются в контейнерах.

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

Особенности реализации платформы:

• все компоненты платформы размещаются на одной ВМ и запускаются в контейнерах;

• пользователи и клиенты API обращаются к платформе через Platform Gateway по порту TCP 443;

• Platform Gateway перенаправляет запросы на контейнеры Automation Controller, Private Automation Hub и Event-Driven Automation;

• СУБД PostgreSQL размещается на той же ВМ и используется основными компонентами платформы для хранения собственных данных;

• Redis размещается на той же ВМ и работает в режиме standalone;

• Automation Controller взаимодействует с локальным контейнером Receptor через Unix-сокет, а задания выполняются в локальных контейнерах исполнения на той же ВМ;

• установочный узел не выделяется в отдельную ВМ.

Примечание

Внешним входом в базовой топологии является Platform Gateway. Остальные порты, показанные на схеме, обеспечивают внутреннее взаимодействие компонентов и не должны быть доступны пользователям и внешним приложениям напрямую.

Топология уровня предприятия

Контейнерная топология уровня предприятия используется для производственных сред, где требуется резервирование основных компонентов платформы, масштабирование плоскости исполнения и возможность обслуживания больших объемов автоматизации.

По составу узлов эта топология близка к топологии уровня предприятия на виртуальных машинах: основные компоненты дублируются, входящий трафик проходит через балансировщик нагрузки, а базы данных размещаются во внешней СУБД PostgreSQL. Отличие состоит в том, что компоненты платформы запускаются в контейнерах.

Особенности реализации платформы:

• дублирование основных компонентов – минимум 2 экземпляра Platform Gateway, Automation Controller, Private Automation Hub и Event-Driven Automation;

• внешний балансировщик нагрузки для Platform Gateway, например на основе HAProxy Load Balancer;

• внешняя СУБД PostgreSQL – отдельный сервер или кластер управления базами данных, доступный по стабильной точке подключения;

• распределенная конфигурация Redis на ВМ компонентов платформы, входящих в группу redis инвентаря;

• Redis не размещается на узлах СУБД PostgreSQL и исполняющих узлах;

• для исполнения заданий используется сеть Mesh с подключением нужного количества исполняющих узлов (Execution node), распределенных по управляемой инфраструктуре;

• при необходимости в состав сети Mesh включают промежуточные узлы (Hop node), которые обеспечивают связь между управляющими и исполняющими узлами в сложных или изолированных сетевых сегментах;

• необходим установочный узел (installation node), который не участвует в работе платформы, но выполняет развертывание и обновление всех ее компонентов.

Минимальный состав топологии уровня предприятия:

Количество	Компонент или узел	Назначение
2	Platform Gateway	Единая точка доступа к интерфейсам и API платформы
2	Automation Controller	Управление заданиями автоматизации и взаимодействие с плоскостью исполнения
2	Private Automation Hub	Хранение и предоставление коллекций Ansible и образов сред исполнения
2	Event-Driven Automation	Обработка событий и запуск автоматизации по правилам
2+	Execution node	Исполнение заданий в управляемых сегментах инфраструктуры
1+	Hop node	Маршрутизация трафика Automation Mesh при отсутствии прямой связи с исполняющими узлами
1	Внешняя СУБД PostgreSQL	Хранение данных основных компонентов платформы
1+	Балансировщик нагрузки	Распределение входящего HTTPS-трафика между узлами Platform Gateway
6	Узлы Redis	Распределенная конфигурация Redis на ВМ компонентов Platform Gateway, Private Automation Hub и Event-Driven Automation

Сеть Automation Mesh

Как и в других моделях задания передаются на исполнение по сети Automation Mesh от управляющих узлов к исполняющим через службу Receptor. На каждой ВМ, где установлены в контейнерах управляющий (control node), промежуточный (hop node) и исполняющий (execution node) узлы, служба Receptor запускается в отдельном контейнере.

Особенности реализации сети Mesh:

• Контейнер Receptor использует сетевой режим ВМ, которая принимает запросы на порте TCP 27199 и перенаправляет их на Receptor.

• Отдельная служба-приемник для входа в сеть Mesh не требуется: точкой входа на каждом узле является сам контейнер Receptor. Это отличает контейнерную модель от модели Kubernetes, где для входа в сеть Mesh используется выделенный модуль (pod) с сервисом Service и приемником Ingress.

• Узлы сети Mesh соединяются между собой по порту TCP 27199 с использованием взаимной аутентификации TLS (mTLS). При установлении соединения узлы проверяют TLS-сертификаты друг друга, а передаваемые данные шифруются.

• Automation Controller взаимодействует с локальным контейнером Receptor через общий Unix-сокет на узле, а не по сети.

• Промежуточный узел (hop node) маршрутизирует трафик сети Mesh между управляющими и исполняющими узлами, но не выполняет задания.

• Задания выполняются на исполняющих узлах (execution node) в локальных контейнерах исполнения (execution container).

Примечание

Соединение узлов сети Mesh задается в файле описания инвентаря через параметр peers. При отсутствии прямой связи с исполняющими узлами трафик сети Mesh маршрутизируется через промежуточные узлы (Hop node).

Сетевое взаимодействие

В контейнерной модели используются внешние и внутренние соединения. Доступ пользователей и API-клиентов осуществляется через Platform Gateway или внешний балансировщик нагрузки. Внутренние соединения используются для взаимодействия контейнеризированных компонентов платформы между собой, с PostgreSQL, Redis и узлами сети Mesh.

Основные соединения:

Источник	Назначение	Порт или интерфейс	Использование
Установочный узел	Узлы платформы	22	Подключение по SSH для установки, обновления и изменения конфигурации компонентов платформы
Пользователь или клиент API	Platform Gateway или балансировщик нагрузки	443	Внешний доступ к графическому интерфейсу и API платформы.
Балансировщик нагрузки	Platform Gateway	443	Передача входящего HTTPS-трафика на доступный узел шлюза.
Platform Gateway	Automation Controller	8080 / 8443	Внутреннее взаимодействие с компонентом автоматизации процессов.
Platform Gateway	Private Automation Hub	8081 / 8444	Внутреннее взаимодействие с компонентом контента автоматизации.
Platform Gateway	Event-Driven Automation	8082 / 8445	Внутреннее взаимодействие с компонентом обработки событий.
Platform Gateway, Automation Controller, Private Automation Hub, Event-Driven Automation	PostgreSQL	5432	Доступ компонентов к собственным базам данных.
Platform Gateway, Event-Driven Automation	Redis	6379	Клиентские подключения к Redis для служебного хранения данных, очередей и сессий
Узлы Redis	Другие узлы Redis	16379	Внутрикластерный обмен данными и состоянием между узлами Redis
Automation Controller	Локальный контейнер Receptor	Unix-сокет	Передача заданий и служебных данных локальному Receptor на той же ВМ.
Контейнер Receptor на управляющем узле	Контейнер Receptor на Execution node или Hop node	27199	Передача заданий и служебных данных между узлами Automation Mesh.
Hop node	Execution node	27199	Маршрутизация соединений Automation Mesh.

Примечание

Узлы Private Automation Hub включаются в группу redis для размещения экземпляров Redis, входящих в состав кластера. Это не означает, что контейнеры Private Automation Hub используют Redis как клиентское хранилище: членство узла в кластере Redis и клиентское подключение компонента к Redis – разные роли.