Astra Automation: архитектура центра автоматизации на базе Ansible

10.11.2026

Astra Automation — корпоративная платформа автоматизации, развиваемая «Группой Астра» на базе экосистемы Ansible. Архитектура решения построена по гибридной схеме с разделением плоскости управления и плоскости исполнения, что обеспечивает независимость автоматизации от привязки к одному сегменту сети. Для инженеров, имеющих опыт работы со стеком Ansible Linux, такая модель знакома, а для архитекторов инфраструктуры организации она означает гибкость размещения компонентов в соответствии с требованиями корпоративных сетей.

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

Предпосылки централизации автоматизации

В зрелых ИТ-ландшафтах накапливается значительный объём неуправляемых решений: плейбуки хранятся в личных репозиториях, задачи запускаются через планировщики ОС, отдельные скрипты размещаются на серверах, а критические знания концентрируются у отдельных специалистов. Автоматизация в таком состоянии распределена по сотрудникам, а не по организации. Следствия — невоспроизводимость операций, ограниченная возможность аудита, расхождение конфигураций между узлами и ненадёжность процедур восстановления после сбоев.

Центр автоматизации в составе Astra Automation охватывает полный жизненный цикл автоматизации: разработку и хранение Ansible-контента, выполнение заданий, анализ результатов и реакцию на события инфраструктуры. Платформа поддерживает управление узлами под Linux и Windows, сетевым оборудованием различных производителей, средствами виртуализации, облачными ресурсами и системами хранения данных. Развёртывание и эксплуатация возможны в закрытых контурах без доступа в интернет, что является обязательным условием применимости для организаций с регуляторными ограничениями.

Архитектура: разделение плоскостей управления и исполнения

Платформа разделена на control plane и execution plane. Плоскость управления образует Automation Controller — кластеризуемый оркестратор с веб-интерфейсом, REST API, приёмником webhook и ролевой моделью доступа (RBAC). Компонент ведёт инвентарные списки, включая динамические источники, управляет шаблонами заданий (Job Templates) и многоэтапными рабочими процессами (Workflows) с условной логикой, сохраняет историю выполнения и обеспечивает параллельное выполнение задач на сотнях узлов.

Плоскость исполнения включает узлы, выполняющие сценарии. Исполнительные узлы рекомендуется размещать в одном сегменте сети с управляемыми ресурсами: задачи выполняются локально относительно инфраструктуры, что снижает зависимость от каналов связи и межсетевых экранов. Средой выполнения служит Execution Environment — контейнер на базе Podman. Изоляция зависимостей обеспечивается фиксацией версий коллекций и модулей в образе независимо от установленных на узле библиотек. Промежуточные (hop) узлы выполняют функцию ретрансляторов в сегментированных сетях и обеспечивают связь с изолированными контурами, в том числе с DMZ.

Обе плоскости объединяются сетью прикладного уровня Automation Mesh — overlay-топологией с автоматическим обнаружением узлов. Топология связей между компонентами задаётся конфигурацией и не зависит от организации сетевой маршрутизации. Каждый основной компонент платформы — контроллер с плоскостью исполнения, приватный реестр и контроллер событийной автоматизации — располагает собственной базой данных. Единая точка входа (Platform Gateway) объединяет графический интерфейс и API всех компонентов за одним HTTPS-шлюзом.

Состав платформы: функциональные контуры

Функционально платформа состоит из взаимосвязанных компонентов, каждый из которых закрывает отдельный участок жизненного цикла автоматизации:

• Automation Controller — диспетчер задач: запуск автоматизаций, распределение нагрузки между исполнительными узлами, управление инвентарями, расписаниями и правами доступа;
• Private Automation Hub — корпоративное хранилище проверенных коллекций, ролей и образов сред исполнения с контролем версий и цифровыми подписями, совместимое с форматом Ansible Galaxy;
• Event-Driven Automation — событийный контур, запускающий сценарии по сигналам из систем мониторинга, SIEM, DLP и ITSM, а также по запланированным изменениям в инфраструктуре;
• Content Development Kit — средства разработки и отладки контента, включая Ansible Navigator для запуска сценариев в изолированных средах и Ansible Builder для сборки пользовательских образов;
• Automation Dashboard — аналитика выполнения заданий и экономической эффективности автоматизации ИТ (функциональность введена в версии 2.1).

Модель управления контентом двухуровневая. Облачный Automation Hub «Группы Астра» содержит сертифицированные коллекции и образы сред исполнения; приватный реестр в инфраструктуре заказчика синхронизирует этот контент при развёртывании и хранит собственные наработки организации. Для закрытых контуров такая модель обеспечивает единственный контролируемый источник инфраструктурного кода и воспроизводимый путь распространения коллекций до продуктивной среды.

Событийная автоматизация

Базовая модель Ansible предполагает инициирующий запуск: инженер выполняет плейбук и контролирует результат. Event-Driven Automation изменяет направление потока данных: платформа принимает события от внешних источников — webhook систем контроля версий, сообщений брокеров очередей, в том числе Kafka, алертов систем мониторинга — и по своду правил (rulebook) запускает соответствующий сценарий без участия оператора. Практический сценарий: система мониторинга фиксирует недоступность сервиса, правило оценивает событие, срабатывает сценарий восстановления — перезапуск сервиса, сбор диагностических данных, создание обращения в ITSM либо полное восстановление конфигурации.

Rulebook является самостоятельной сущностью с собственной логикой условий и действий, а не модифицированным плейбуком. При проектировании следует учитывать, что события рекомендуется принимать через контур EDA, а не вызывать API контроллера напрямую: в противном случае дедупликация, фильтрация и приоритизация сигналов должны быть реализованы отдельно. Реактивный контур обеспечивает сокращение времени простоев за счёт реагирования на инциденты до момента их обнаружения дежурной службой.

Автоматизация как управляемый процесс

Состав компонентов реализует модель полного цикла работы с Ansible: от разработки сценария до промышленной эксплуатации и оценки эффективности. Инструментарий разработки переводит автоматизацию ИТ из разрозненных наработок в управляемый процесс: контент версионируется, тестируется, подписывается и распространяется через реестры. Документация платформы охватывает структуру компонентов, регламенты работы с реестрами и своды правил событийного контура.

Типовые задачи, выполняемые через единый интерфейс платформы, включают:

• развертывание ПО, обновления приложений и патчинг операционных систем;
• управление серверами, сетевым оборудованием и облачными ресурсами независимо от вендора;
• применение политик безопасности, в том числе готовые hardening-роли по требованиям ФСТЭК и рекомендациям DevSec;
• оркестрация ИТ-процессов: сквозные workflow, связывающие несколько систем и команд, циклы аудита соответствия с автоматическим устранением отклонений;
• автоматизация сопровождения продуктов экосистемы: Astra Linux, ALD Pro, RuBackup, VMmanager, Tantor, RuPost, GitFlic.

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

Развёртывание, лицензирование, условия применимости

Платформа поддерживает несколько моделей развёртывания: установку из deb-пакетов на физический сервер или виртуальную машину, контейнерное развёртывание и запуск в кластере Kubernetes (механизм введён во второй версии вместе с диагностикой fast-fail при установке). Такой набор вариантов позволяет встраивать платформу в существующую архитектуру инфраструктуры организации без её пересмотра.

Лицензирование привязано к числу управляемых узлов: от пакетов на 50 до пакетов на 10 000 узлов, с подпиской на один или три года и уровнями технической поддержки от стандартной 8/5 до круглосуточной. Подписка включает доступ к сертифицированному контенту, обновления, патчи безопасности и обучающие материалы.

При оценке применимости учитываются два фактора. Во-первых, платформа не заменяет инженерную подготовку: необходимы описание целевого состояния инфраструктуры, перенос накопленных сценариев в корпоративную библиотеку и разработка регламентов выполнения задач; без этих мер централизация не даёт управленческого эффекта. Во-вторых, экономический эффект масштабируется нелинейно: при небольшом количестве узлов самостоятельное использование Ansible с репозиторием Git требует меньших затрат, однако при сотнях узлов, нескольких командах и регуляторных требованиях затраты на самостоятельное сопровождение открытых инструментов превышают стоимость подписки.

Позиционирование и направления развития

Разработчик позиционирует решение как первую в России корпоративную платформу Enterprise-уровня на базе Ansible — наиболее распространённой технологии автоматизации. Практическое значение этого факта заключается в доступе к экосистеме готовых модулей, коллекций и экспертизы сообщества: внедрение опирается на отраслевой стандарт, а не на проприетарные решения вендора. Для заказчиков, формирующих ландшафт на отечественном ПО, существенна интеграция с экосистемой «Группы Астра»: сертифицированные коллекции упрощают совместное внедрение и снижают риск рассогласования версий между компонентами.

Заявленная стратегия развития ориентирована на AI-центричную модель: ассистент в инструментах разработки предназначен для генерации плейбуков и снижения порога входа для новых специалистов, а аналитический контур — для преобразования статистики выполнения заданий в управленческие показатели. Данные функции следует рассматривать как направления развития, а не как реализованную функциональность.

По совокупности архитектурных решений, состава компонентов и сценариев применения Astra Automation корректно рассматривать как надстройку над Ansible, переводящую его из инструмента отдельных инженеров в корпоративный стандарт автоматизации. В этой роли — слоя управления над проверенной технологией — платформа соответствует задачам организаций, для которых автоматизация ИТ является обязательным элементом промышленной эксплуатации инфраструктуры.

Ваши замечания, пожелания