Обзор архитектуры

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

Структура платформы

Состав платформы, взаимодействие ее компонентов и интеграция с внешней средой представлены на следующей схеме:

К платформе относятся следующие компоненты:

• Объединенный интерфейс (шлюз) платформы (Platform Gateway) предоставляет единую точку доступа к графическому веб-интерфейсу и API основных компонентов платформы (Automation Controller, Private Automation Hub и Event-Driven Automation) по протоколу HTTPS (при необходимости можно HTTP) для пользователей и программ. Внутреннее взаимодействие компонентов платформы также осуществляется через этот шлюз.

• Контроллер автоматизации (Automation Controller) образует плоскость управления (control plane) на основе кластера. Он предоставляет пользователю удобные средства управления через графический веб-интерфейс, вызовы API, командный интерфейс (CLI, command-line interface) и специальную коллекцию Ansible.

• Плоскость исполнения (Execution plane) является частью общего кластера, объединяющей узлы, которые выполняют задания контроллера. Особенности плоскости исполнения:

  • Она обеспечивает эффективное управление распределенной инфраструктурой путем расположения узлов в одном сегменте сети с узлами управляемой инфраструктуры.

  • Непосредственным исполнителем сценариев автоматизации является среда исполнения (EE, Execution Environment), выполненная в виде контейнера Podman.

  • Контроллер позволяет назначать различные задания на исполнение определенным группам узлов плоскости исполнения, а также выполнять их с помощью указанных образов EE.

• Сеть прикладного уровня (Automation Mesh, overlay) объединяет плоскость управления и плоскость исполнения в единый кластер распределенного управления. Настройки платформы позволяют гибко определять связи (топологию) между компонентами этих плоскостей.

• Automation Hub является облачным реестром инфраструктурного кода для реализации требуемых задач автоматизации. В состав реестра входят различные типы инфраструктурного кода:

  • сертифицированные коллекции Ansible для выполнения различных задач автоматизации;

  • образы среды исполнения Ansible.

• Собственный (приватный) реестр инфраструктурного кода (Private Automation Hub) позволяет организации использовать контент, предоставляемый через Automation Hub или другие источники, а также хранить и использовать собственный контент и образы среды исполнения. При создании собственного реестра в процессе развертывания платформы он получает контент из Automation Hub.

• Комплект средств разработки (CDK, Content Development Kit) содержит необходимые инструменты для организации полноценного процесса разработки собственного инфраструктурного кода и образов среды исполнения. Созданные артефакты следует сохранять в собственном реестре инфраструктурного кода.

• Служба управления событиями (Event-Driven Automation) позволяет отслеживать события, возникающие в различных компонентах инфраструктуры пользователя. Применение этой службы приводит к существенному снижению объема ручной работы, а также к быстрому и своевременному реагированию на изменившуюся ситуацию в инфраструктуре. Контроллер EDA активирует специальные контейнеры DE (Decision Environment) для активации сводов правил по обработке событий.

• Средства аналитики (Analytics) собирают данные о работе контроллера и формируют отчеты для оценки эффективности процессов автоматизации.

  Примечание

  Компонент находится в стадии разработки и временно недоступен.

Интеграция

Компоненты платформы взаимодействуют с различными внешними системами:

• Источники проектов (Projects) – это внешние системы управления исходным кодом (SCM, Source Code Management), из которых компоненты платформы получают проекты автоматизации. Поддерживаются VCS Git (рекомендуется) и Subversion. Проекты содержат основное описание процессов автоматизации:

  • наборы сценариев (playbooks) для Automation Controller;

  • своды правил (rulebooks) для Event-Driven Automation.

• Внешние источники коллекций (не приведены на схеме) могут понадобиться для загрузки дополнительных коллекций в приватный реестр. Наиболее известным источником является общедоступный реестр Ansible Galaxy.

• Управляемая инфраструктура (Managed IT infrastructure) объединяет все управляемые узлы, к которым планируется применение сценариев автоматизации. Она может быть структурно и географически распределенной. В соответствии с этим узлы плоскости исполнения распределяются так, чтобы быть ближе к управляемым узлам, то есть внедряются в локальные сети, где расположены управляемые узлы.

Объединенный интерфейс

Независимо от способа развертывания платформа предоставляет единый набор интерфейсов для различных типов операторов платформы.

Виды интерфейсов

Для администраторов и конечных пользователей платформа предоставляет следующие способы взаимодействия:

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

• API (Application Programming Interface) является базовым интерфейсом, через который реализуются все остальные виды интерфейсов. Прямое управление платформой через API необходимо для программного управления без вмешательства операторов.

• CLI (Command Line Interface) позволяет использовать командную строку для управления платформой с помощью клиента CLI – утилиты awx.

Для службы технической поддержки доступны дополнительные утилиты:

• awx-manage предоставляет ряд возможностей по внутренним настройкам, диагностике и другим функциям поддержки локально на узле, входящем в Automation Controller.

• pulpcore-manager предоставляет возможности по управлению Private Automation Hub, такими как техническая поддержка базы данных, управление привилегиями пользователей, очистка контента, проверка работоспособности и генерация токена доступа.

Обзор графического интерфейса

Графический интерфейс построен в соответствии со структурной схемой платформы. Он имеет явно выраженное деление на разделы:

• Автоматизация процессов (Automation Execution) – создание и управление заданиями по автоматизации процессов в управляемых узлах с помощью проектов автоматизации, предоставляющих сборники сценариев автоматизации (playbooks). Создание ресурсов автоматизации и их применение реализуется через Automation Controller.

• Обработка событий (Automation Decision) – автоматизация процессов по событиям с помощью проектов, предоставляющих своды правил (rulebooks). Создание ресурсов по обработке событий и их применение реализуется через контроллер Event-Driven Automation.

• Контент автоматизации (Automation Content) – хранение и распределение коллекций Ansible и образов сред исполнения. Эти действия реализуются путем настройки Private Automation Hub и загрузки в него необходимого контента.

Сеть

С помощью сети прикладного уровня с автоматическим обнаружением узлов (Automation Mesh) кластер Astra Automation объединяет узлы разных типов в две плоскости – плоскость управления (control plane) и плоскость исполнения (execution plane). При объединении узлов в сеть происходит настройка связей между узлами плоскостей напрямую или через промежуточные узлы.

Плоскость управления представляет собой Automation Controller и состоит из управляющих и гибридных (объединение функций управления и исполнения) узлов, а плоскость исполнения – из промежуточных и исполняющих узлов.

Узлы кластера объединяются в сеть с помощью службы рецепторов (receptor), установленной на каждом узле.

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

Организация данных

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

Базы данных

Каждый основной компонент платформы (Automation Controller совместно с плоскостью исполнения, Private Automation Hub и контроллер EDA) имеет собственную базу данных. Все они создаются на базе СУБД PostgreSQL. Поскольку узлы плоскости исполнения могут быть распределены по сетям управляемой инфраструктуры, необходимо уделять особое внимание доступности базы данных для них.

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

При развертывании СУБД средствами платформы необходимо выделить для нее отдельный узел, который не должен использоваться для других целей.

Astra Automation не имеет встроенной поддержки кластеризации СУБД. Это значит, что высокую доступность СУБД следует обеспечить самостоятельно.

Использование внешней СУБД накладывает следующие ограничения:

• Astra Automation не поддерживает автоматическое переключение на новый мастер-узел в случае переключения мастера в кластере СУБД.

• Не рекомендуется использовать менеджеры соединений типа pgBouncer.

• Нельзя использовать менеджер соединений в режиме «Transaction pooling».

Репозитории

Помимо базы данных, используемой для внутренних целей, Private Automation Hub хранит также данные, необходимые для других компонентов платформы, в отдельных реестрах. К этим реестрам относятся следующие:

• Реестр коллекций обеспечивает Automation Controller коллекциями Ansible для использования их в различных проектах. Кроме того, потребителями коллекций являются различные утилиты Ansible, среди которых следует выделить Ansible Builder, который создает образы сред исполнения с включенными в них коллекциями.

• Реестр образов контейнеров обеспечивает Automation Controller и Event-Driven Automation соответственно образами сред исполнения и сред принятия решений.

Для хранения данных можно использовать одно из следующих решений:

• сервер NFS с монтированием устройства хранения к каждому узлу кластера Private Automation Hub;

• объектное хранилище S3.

Рабочее окружение

Astra Automation можно развернуть в двух различных окружениях:

• на виртуальных машинах или физических серверах (последний вариант практически не используется);

• в контейнерной среде под управлением Kubernetes.

Существуют ключевые различия между развертыванием на виртуальных машинах и в контейнерах:

Критерий	Виртуальные машины (VM)	Kubernetes
Архитектура развертывания	Монолитная; сервисы платформы размещаются на отдельных VM	Микросервисная; сервисы платформы работают в подах на основе контейнеров
Масштабируемость	Требует ручного управления масштабированием VM	Автоматическое масштабирование через механизмы Kubernetes
Обновление платформы	Проверенные Ansible playbooks, медленная миграция	Обновления выполняются через операторы Kubernetes, быстрая миграция с быстрым откатом при необходимости
Управление и мониторинг	Используются стандартные средства Linux и сторонние агенты	Встроенные средства мониторинга (Prometheus, Grafana), централизованное управление журналами
Устойчивость к сбоям	Основывается на архитектуре высокой доступности (HA, High Availability) с применением внешних балансировщиков	Встроенный перезапуск и размещение подов в автоматическом режиме (self-healing)
Управление ресурсами	Явное выделение CPU, RAM, Disk для каждой VM	Динамическое выделение ресурсов, политика обеспечения качества обслуживания (QoS, Quality of Service ), политика предпочтений размещения подов на узлах кластера (node affinity)
Интеграция с DevOps	Требует настройки CI/CD вне платформы (Jenkins, GitLab)	Легкая интеграция с GitOps, WebHooks, конвейерами CI/CD Kubernetes
Сетевые особенности	Виртуальные сети, ручная настройка сетевых экранов (firewall)	Сетевые политики, автоматическое обнаружение сервисов (service discovery)