Особенности архитектуры#
Система автоматизации процессов имеет множество архитектурных особенностей, среди которых в первую очередь необходимо обратить внимание на взаимосвязь управляющих и исполняющих узлов.
Компоненты топологии#
Система автоматизации процессов Astra Automation построена на разделении функций управления и исполнения. Такой подход позволяет масштабировать автоматизацию, изолировать выполнение заданий от управляющих компонентов и адаптировать систему к различным сетевым и инфраструктурным условиям.
Архитектурно система состоит из двух логически независимых, но тесно связанных плоскостей:
плоскости управления (control plane);
плоскости исполнения (execution plane).
Плоскость управления#
Компонент Automation Controller реализует функции плоскости управления (control plane).
Он может быть установлен как отдельный узел или в виде кластера из нескольких узлов типа control для обеспечения отказоустойчивости и повышения производительности.
Пользователь может управлять ресурсами Automation Controller (описания инвентаря, проекты, задания, среды исполнения, политики доступа к ресурсам) с помощью следующих средств:
графическая консоль (веб-интерфейс);
REST API;
командный интерфейс (CLI);
специализированная коллекция Ansible.
Роль Automation Controller#
Automation Controller отвечает за организацию и координацию процессов автоматизации, но не выполняет сценарии напрямую (за исключением использования гибридных узлов). Его задачи включают:
планирование и постановку заданий;
выбор целевых узлов плоскости исполнения;
управление очередями и состояниями выполнения;
сбор результатов и ведение журналов;
аудит и контроль доступа.
Для хранения состояния, конфигураций и служебных данных плоскость управления использует отдельную базу данных. Доступ к базе данных имеют только компоненты плоскости управления. Узлы плоскости исполнения не взаимодействуют с базой данных напрямую и получают задания исключительно через Automation Controller.
Основные службы Automation Controller#
Каждый узел Automation Controller включает следующий набор служб:
Служба HTTP (HTTP service) обеспечивает доступ пользователей и внешних систем к управлению и мониторингу через веб-интерфейс и REST API.
Служба обратных вызовов (Callback receiver) агрегирует статусы и результаты выполнения задач в реальном времени для внутреннего использования и последующего анализа.
Диспетчер (Dispatcher) управляет системой очередей, распределяя задания между исполнительными узлами и контролируя их выполнение.
Redis выполняет функции оперативного хранения временных данных.
Syslog NG подготавливает и отправляет журналы событий и операций во внешние центры для мониторинга, аудита и поиска инцидентов.
В каждом узле контроллера действует система самовосстановления, реализованная с помощью сервиса supervisord (a process control system).
При сбое любой из служб эта система автоматически запускает заново соответствующий сервис или все сервисы Automation Controller в зависимости от степени влияния произошедшего отказа для восстановления работоспособности узла.
Automation Mesh#
Automation Mesh – это сеть прикладного уровня, обеспечивающая взаимодействие между плоскостью управления и плоскостью исполнения.
Automation Mesh определяет маршрут передачи управляющих команд и данных от Automation Controller к узлам плоскости исполнения и обратно. При нарушении сетевых соединений Mesh может автоматически перестроить маршрут между каждой парой взаимодействующих узлов через другие узлы сети Mesh. Это позволяет устанавливать соединение между двумя узлами, даже если между ними нет возможности установить прямой сеанс связи по TCP.
Каждый узел, участвующий в Automation Mesh, запускает процесс receptor.
Receptor отвечает за установление, поддержку и мониторинг сетевых соединений между узлами Mesh.
Соединения формируются на основе заранее заданной топологии. В зависимости от архитектуры маршрут от Automation Controller до исполняющего узла может быть прямым или через промежуточные узлы, роль которых обычно выполняют специализированные переходные узлы (hop nodes).
Инициатором соединения может выступать любой узел Mesh в зависимости от сетевых ограничений и настройки. Между каждой промежуточной парой узлов устанавливается постоянный сеанс связи по TCP.
Плоскость исполнения#
Плоскость исполнения (execution plane) представляет собой распределенную среду выполнения заданий от Automation Controller. Она объединяет узлы, которые непосредственно исполняют сценарии автоматизации в управляемой инфраструктуре.
Плоскость исполнения может размещаться как в том же окружении, что и Automation Controller, так и в удаленных или изолированных сегментах сети, как показано на схемах ниже. Основная задача плоскости исполнения – выполнение заданий максимально близко к управляемым системам.
Описание процесса добавления см. в описании операционных задач.
Исполняющие узлы#
Исполняющие узлы (execution nodes) являются конечными точками выполнения заданий автоматизации. Именно на них запускаются сценарии Ansible в изолированных средах исполнения (EE), реализованных в виде контейнеров, управляемых через Podman.
Исполняющие узлы не хранят состояние системы и не используют базу данных. Все задания, параметры и образы EE они получают от Automation Controller через Automation Mesh.
Размещение исполняющих узлов обычно ориентируется на близость к управляемой инфраструктуре. Это позволяет снизить сетевые задержки, уменьшить нагрузку на магистральные каналы и повысить устойчивость выполнения заданий. Горизонтальное масштабирование исполняющих узлов используется для увеличения производительности с помощью параллельного выполнения задач.
Переходные узлы#
Переходные узлы (hop nodes) используются для обеспечения соединений между сегментами сети внутри Automation Mesh. Они не выполняют сценарии автоматизации и не запускают EE.
Задача переходных узлов – обеспечить контролируемое и предсказуемое прохождение трафика между плоскостью управления и исполняющими узлами в сложных сетевых условиях: при наличии NAT, DMZ, межсетевых экранов или жесткой сегментации.
Как и исполняющие, переходные узлы не имеют доступа к базе данных и не хранят состояние заданий. Они получают управляющие команды исключительно через Mesh и участвуют только в транспортировке соединений.
Размещение компонентов и среда развертывания#
Выбор среды развертывания влияет прежде всего на плоскость управления. Automation Controller может быть развернут как на виртуальных машинах, так и в кластере Kubernetes.
Использование Kubernetes относится исключительно к центральной части системы автоматизации. В этом случае кластер Kubernetes используется для размещения компонентов плоскости управления и не определяет архитектуру плоскости исполнения. Automation Controller внутри Kubernetes может устанавливать соединения с другими узлами Mesh по собственной инициативе, но не предоставляет возможности устанавливать такое соединение со стороны этих узлов. Для обеспечения такой возможности предусмотрена возможность установки внутреннего переходного узла, который может принимать запросы на установление соединения от исполняющих узлов.
Плоскость исполнения, включая исполняющие и переходные узлы, как правило, развертывают на виртуальных машинах или физических серверах. Это позволяет размещать исполняющие узлы максимально близко к управляемой инфраструктуре, независимо от того, где находится Automation Controller.
Установление соединений в сети Mesh#
Чтобы узлы плоскости исполнения стали доступны для Automation Controller, необходимо явно определить их взаимное расположение, роли и направление установления соединений.
Процесс установления соединений зависит от среды развертывания плоскости управления, однако в обоих случаях опирается на описание топологии Mesh и запуск процедур ее создания.
Развертывание на ВМ#
В среде виртуальных машин формирование Automation Mesh выполняется на основе описания инвентаря. В описании инвентаря указываются узлы плоскости управления, исполняющие и переходные узлы, а также параметры их взаимодействия.
После внесения изменений в описание инвентаря выполняется сценарий установки или обновления системы.
В ходе его выполнения на узлах запускаются процессы receptor, устанавливаются необходимые соединения и формируется заданная топология Mesh.
Таким образом, добавление или изменение узлов Mesh в среде ВМ осуществляется централизованно в два этапа:
Запуск утилиты
aa-setup.Подробную инструкция по работе с утилитой
aa-setupсм. в разделе Развертывание Astra Automation.
Ниже приведены типовые примеры описания инвентаря для различных моделей установления соединений.
Пример 1. Соединение по инициативе плоскости управления.
Данный вариант используется в сетях, где управляющие узлы имеют прямую сетевую доступность к узлам плоскости исполнения. В этом случае инициатором соединения выступают узлы плоскости управления.
Пример логики топологии:
Automation Controller инициирует соединение с исполняющим узлом напрямую;
переходные узлы не используются.
Фрагмент описания инвентаря:
---
# Control plane
automationcontroller:
hosts:
ctrl1.example.com:
vars:
node_type: control
peers: execution_nodes
# Execution plane
execution_nodes:
hosts:
exec1.example.com:
При такой настройке Mesh строится по схеме control → execution.
Пример 2. Соединение по инициативе узлов плоскости исполнения.
Этот вариант применяется в частично изолированных сетях, где плоскость управления не имеет возможности установить сеанс связи по TCP с исполняющим узлам, однако в обратную сторону такая возможность есть. В этом случае инициаторами соединений выступают переходные и исполняющие узлы.
Пример логики топологии:
исполняющий узел устанавливает соединение с переходным узлом;
в зависимости от расположения переходного узла он устанавливает соединение с Automation Controller или наоборот.
Фрагмент описания инвентаря:
---
# Control plane
automationcontroller:
hosts:
ctrl1.example.com:
ctrl2.example.com:
vars:
node_type: control
peers: instance_group_local
# Execution plane
execution_nodes:
hosts:
exec1.example.com:
exec2.example.com:
exec3.example.com:
hop1.example.com:
# Execution nodes with direct connection to control nodes
instance_group_local:
hosts:
exec1.example.com:
exec2.example.com:
# Hop node
hop:
hosts:
hop1.example.com:
vars:
node_type: hop
peers: automationcontroller
# Remote execution node
instance_group_remote:
hosts:
exec3.example.com:
vars:
peers: hop
В этом случае Mesh строится по цепочке execution → hop → control.
Плоскость управления не принимает запросы на установление сеанса связи, а весь маршрут формируется за счет исходящих подключений от узлов плоскости исполнения.
Развертывание в Kubernetes#
При использовании Kubernetes плоскость управления развертывается внутри кластера, что накладывает ограничения на установление входящих соединений. В этом случае Automation Controller не принимает соединения от внешних узлов Mesh. Поэтому в топологии уровня предприятия рекомендуется добавлять один или более объектов Automation Mesh ingress, реализующих внутренние переходные узлы с возможностью установления соединения по запросам от внешних узлов.
При формировании Automation Mesh в Kubernetes используются две основные модели установления соединений, выбор которых определяется сетевой доступностью узлов и требованиями безопасности:
Соединение по инициативе плоскости управления.
Данная модель применяется, если кластер Kubernetes имеет прямую сетевую доступность к узлам плоскости исполнения.
В этом случае контроллер устанавливает постоянное соединение с исполняющими узлами напрямую или через переходные узлы.
Соединение по инициативе узлов плоскости исполнения.
Наиболее распространенный сценарий для корпоративных и изолированных сетей.
В этом случае возможны следующие варианты установления постоянных сеансов связи:
контроллер устанавливает соединение с внутренними переходными узлами, реализованными в виде отдельных Pod (без реплицирования);
исполняющие узлы устанавливают соединение с внешними или внутренними переходными узлами;
внешние переходные узлы устанавливают соединение с внутренними переходными узлами.
Для изменения сети Mesh путем подключения или отключения узлов плоскости исполнения используют следующие методы:
С помощью графической консоли Automation Controller, которая позволяет получить готовый сценарий и описание инвентаря для него.
Универсальный способ: описание требуемой топологии в файле описания инвентаря и выполнение сценария обновления Automation Mesh.
В обоих случаях первым шагом является подготовка файла описания инвентаря, а вторым – исполнение сценария с использование этого файла. Подробные пошаговые инструкции по подготовке инвентаря, выбору сценариев и их запуску приведены в описании операционных задач.
Ниже приведены типовые примеры описания инвентаря для различных моделей установления соединений.
Пример 1. Соединение по инициативе плоскости управления.
Этот вариант возможен, если кластер Kubernetes имеет прямую сетевую доступность к узлам плоскости исполнения. Инициатором соединения в этом случае выступает Automation Controller.
Пример логики топологии:
Automation Controller инициирует соединение с исполняющим узлом напрямую;
Mesh строится без переходных узлов.
Фрагмент описания инвентаря:
[execution_nodes]
exec-01 peers_from_control_nodes=true
---
execution_nodes:
hosts:
exec-01:
peers_from_control_nodes: true
Такой подход применяется в доверенных сетях или при наличии маршрутизации между кластером Kubernetes и управляемой инфраструктурой.
Пример 2. Соединение по инициативе узлов плоскости исполнения.
Наиболее распространенный сценарий для узлов, находящихся в DMZ – узлы плоскости исполнения находятся вне кластера и не могут принимать входящие соединения от Automation Controller. В этом случае необходимо использовать переходные узлы, размещенные внутри кластера Kubernetes.
Пример логики топологии:
исполняющий узел устанавливает соединение с переходным узлом (Mesh Ingress);
внутри кластера Kubernetes Automation Controller устанавливает постоянный сеанс связи с переходным узлом.
Фрагмент описания инвентаря:
[hop_nodes]
mesh-ingress receptor_address=2
[execution_nodes]
exec-remote hop_node_related=mesh-ingress peers_from_control_nodes=false
---
hop_nodes:
hosts:
mesh-ingress:
receptor_address: 2
execution_nodes:
hosts:
exec-remote:
hop_node_related: mesh-ingress
peers_from_control_nodes: false
В этом случае Mesh строится по схеме execution → hop → control.
Это позволяет подключать удаленные или изолированные узлы плоскости исполнения без открытия входящих соединений в кластер Kubernetes.
Переменная receptor_address указывает на идентификатор переходного узла, который можно определить запросом через API шлюза /api/controller/v2/receptor_addresses/.
Последовательность выполнения задания#
В Astra Automation выполнение задания представляет собой последовательность операций, в которой Automation Controller подготавливает рабочие данные задания, определяет целевой узел плоскости исполнения, передает подготовленный набор данных через Automation Mesh и принимает результаты выполнения обратно. Такая модель обеспечивает разделение плоскости управления и плоскости исполнения, изоляцию выполнения и централизованную фиксацию результатов. Фактическое выполнение сценария происходит на исполняющем узле в среде EE, а Automation Controller отвечает за подготовку задания, маршрутизацию, контроль состояния и хранение результатов.
Общая схема выполнения задания#
Ниже приведена схема, показывающая основные этапы прохождения задания от момента запуска до возврата результатов в Automation Controller.
Подготовка задания#
После запуска задания Automation Controller формирует набор данных, необходимый для последующего запуска на исполняющем узле. На этом этапе Automation Controller определяет параметры выполнения на основе шаблона задания, подготавливает сведения о проекте, файлы инвентаризации, учетные данные, дополнительные переменные и параметры выполнения и при необходимости синхронизирует проект из SCM.
В рамках этой подготовки Automation Controller формирует изолированный рабочий каталог задания /private_data_dir/.
Каталог обычно включает следующие данные:
файл сценариев автоматизации, указанный в шаблоне задания;
содержимое проекта, включая роли, модули и вспомогательные файлы;
файлы инвентаризации;
служебные файлы, необходимые для выполнения задания.
Другие сведения, необходимые для запуска задания, Automation Controller передает отдельно от содержимого рабочего каталога. К ним относятся учетных данные, дополнительные переменные и параметры выполнения.
Каталог /private_data_dir/ является рабочей областью при запуске конкретного задания.
В нем Automation Controller формирует частную копию рабочих данных, которую платформа использует только в рамках данного запуска.
Точный состав каталога зависит от типа задания, используемых учетных данных и настроек изоляции, однако во всех случаях /private_data_dir/ представляет собой локально подготовленный рабочий набор данных и не зависит от исходного расположения проекта и других ресурсов на стороне Automation Controller.
Важно
На исполняющий узел передается не ссылка на исходные ресурсы Automation Controller, а подготовленная копия данных задания. Исполняющий узел не использует каталог проекта на узле Automation Controller напрямую.
Выбор узла и передача задания#
После подготовки задания диспетчер Automation Controller определяет узел плоскости исполнения, на котором будет выполнен сценарий. Automation Controller учитывает доступные вычислительные ресурсы узла (capacity), принадлежность узла к соответствующей группе, текущее состояние узла, доступность требуемой среды EE, а также наличие маршрута до целевого узла внутри Automation Mesh. Таким образом, место выполнения задания определяется совокупностью логических, сетевых и ресурсных факторов.
После выбора узла Automation Controller формирует загрузочные данные (payload) задания для передачи через Receptor. В загрузочные данные включаются подготовленные рабочие данные задания, параметры его запуска и служебные метаданные, необходимые для доставки и выполнения задания на целевом исполняющем узле. В зависимости от типа учетных данных и параметров выполнения часть сведений передается в виде файлов рабочего каталога, а часть – через параметры запуска и переменные окружения. Передача выполняется через Automation Mesh, поэтому Automation Controller может не иметь прямую сетевую доступность до исполняющего узла, если внутри Mesh существует корректный маршрут. Если между узлами отсутствует прямая сетевая доступность, Automation Mesh может доставить задание через один или несколько промежуточных узлов. Промежуточные узлы не исполняют сценарий автоматизации и участвуют только в транспортировке данных и соединений внутри Mesh.
Примечание
Передача задания через Mesh не является эквивалентом обычного удаленного запуска по SSH. Automation Controller передает подготовленное описание задания и рабочие данные, после чего Receptor и worker-процесс выполняют запуск задания на целевом узле.
Подготовка среды и выполнение задания#
Исполняющий узел размещает полученные данные во временном рабочем каталоге и подготавливает среду исполнения. Если образ EE отсутствует локально, исполняющий узел перед фактическим запуском загружает его из реестра контейнеров. По умолчанию выполнение происходит в изолированной среде исполнения, реализованной в виде контейнера под управлением Podman. Внутри контейнера доступен каталог проекта, подготовленный для конкретного запуска задания. Администратор может подключить дополнительные каталоги узла путем явного указания списка каталогов. Порядок настройки см. в описании параметра Пути для доступа к изолированным заданиям (Paths to expose to isolated jobs).
Среда исполнения задает программное окружение для фактического запуска ansible-playbook.
Как правило, образ EE включает Ansible, ansible-runner, необходимые коллекции, интерпретатор Python, требуемые библиотеки и системные пакеты.
Состав программных зависимостей определяется образом EE, а не состоянием операционной системы исполняющего узла.
Это снижает зависимость результата от локальной конфигурации узла и повышает воспроизводимость выполнения.
Если требуемый образ EE отсутствует на исполняющем узле, перед фактическим запуском может потребоваться дополнительное время на его получение.
После подготовки среды исполнения на исполняющем узле запускается ansible-runner, который инициирует выполнение ansible-playbook внутри контейнера EE.
При запуске используются описания инвентаря задания, учетные данные, дополнительные переменные, параметры выполнения и зависимости, содержащиеся в образе EE.
Таким образом, среда выполнения определяется не состоянием исполняющего узла, а составом образа EE и данными, подготовленными Automation Controller.
При выполнении задания используются два различных типа сетевых взаимодействий:
между Automation Controller и узлами плоскости исполнения – передача задания, событий и результатов через Automation Mesh;
между исполняющим узлом и управляемыми узлами – непосредственное выполнение автоматизации средствами Ansible.
Возврат результатов и завершение#
Во время выполнения задания исполняющий узел направляет обратно в Automation Controller стандартный вывод и сообщения об ошибках, события выполнения Ansible, итоговый статус задания и служебную информацию, используемую для мониторинга и аудита. Automation Controller принимает эти данные, отображает ход выполнения в интерфейсе, сохраняет результаты в базе данных и регистрирует сообщения в журналах для аудита. Это позволяет получать сведения о выполнении задания в реальном времени, несмотря на то, что само выполнение происходит на удаленном исполняющем узле.
После завершения задания исполняющий узел останавливает выполнение, платформа может удалить временные данные в соответствии с настройками, а Automation Controller фиксирует итоговый статус. Automation Controller делает результаты выполнения доступными для просмотра, анализа и аудита. Итоговый статус задания зависит от результата выполнения и может отражать, например, успешное завершение, ошибку выполнения или принудительную остановку.
Передаваемые данные и изоляция#
На исполняющий узел передаются не только параметры запуска, но и набор рабочих данных, необходимых для выполнения задания. Обычно Automation Controller передает следующие данные:
копию проекта;
файлы инвентаризации;
дополнительные переменные;
служебные файлы рабочего каталога;
сведения, необходимые для запуска в выбранной среде исполнения, за исключением самого образа EE.
Automation Controller также передает учетные данные, дополнительные переменные и параметры выполнения, необходимые для запуска задания.
На исполняющий узел не передаются:
прямой доступ к базе данных Automation Controller;
исходный каталог проекта на стороне Automation Controller как часть его файловой системы;
пользовательская сессия веб-интерфейса;
произвольные каталоги исполняющего узла, если они не подключены явно;
состояние других заданий, выполняемых системой.
Такое разделение повышает безопасность и предсказуемость выполнения, поскольку исполняющий узел получает только тот набор данных, который требуется для конкретного запуска задания.
При запуске задания платформа использует переменные окружения, которые определяют параметры работы ansible-runner и ansible-playbook, настройки изоляции и поведение вывода.
Настройки изоляции определяют базовый каталог подготовки рабочих данных, перечень дополнительных каталогов, которые могут быть доступны внутри контейнера, и режим работы среды исполнения.
По умолчанию платформа ограничивает выполнение рамками подготовленного рабочего каталога, что снижает риск доступа к посторонним данным исполняющего узла.
Важно
Чувствительные данные не должны выводиться в стандартный вывод задания. Параметры среды выполнения и настройки отображения результата используются в том числе для уменьшения риска раскрытия секретов в журнале выполнения.
Особенности запуска и диагностики#
Задержка запуска или сбой задания могут быть связаны не только с самим сценарием, но и с одним из предшествующих этапов. К типовым причинам задержек и ошибок относятся отсутствие доступного маршрута внутри Automation Mesh, недоступность выбранного исполняющего узла, ожидание освобождения ресурсов на узле, необходимость предварительной загрузки образа EE, ошибка подготовки проекта, описания инвентаря или учетных данных, а также ошибка соединения между исполняющим узлом и управляемыми системами.
При анализе проблем целесообразно различать:
ошибки планирования и доставки задания;
ошибки подготовки среды исполнения;
ошибки самого сценария автоматизации;
ошибки сетевого доступа к управляемой инфраструктуре.
Основные особенности выполнения задания#
Для выполнения задания в Astra Automation характерны следующие особенности:
задание подготавливается на стороне Automation Controller как самостоятельная рабочая единица;
исполняющий узел получает копию данных задания, а не доступ к исходным ресурсам Automation Controller;
запуск выполняется в изолированной среде исполнения;
Automation Mesh отделяет транспортировку задания от логики его планирования и контроля;
исполняющие и промежуточные узлы не используют базу данных плоскости управления;
результаты и состояние выполнения централизованно фиксируются в Automation Controller;
сетевой путь доставки задания и сетевой путь выполнения автоматизации являются разными архитектурными контурами.