Обзор Astra Configuration Manager – чего не хватало ALD Pro

Управлять современной инфраструктурой на Astra Linux — задача не из простых. Одного домена и групповых политик недостаточно, если тебе нужно не просто завести пользователей, а держать под контролем всё: от списка «железа» для каждой машины до установленного ПО, от массового обновления ОС до переустановки софта на десятках рабочих станций без физического доступа. В реальности всё это оборачивается множеством  скриптов, таблиц в Excel и флешками, которые кто-то обязательно потеряет. Можно ли этого избежать? Кажется, что да…

Привет! Меня зовут Александр Усов, я системный инженер в К2Тех. Хочу поделиться опытом и рассказать про новый продукт экосистемы «Группы Астра» — Astra Configuration Manager (ACM). Это программный комплекс, предназначенный для централизованного управления компьютерами под управлением операционной системы Astra Linux. Система ориентирована на использование в инфраструктурах различного масштаба, включая защищённые среды, и построена по клиент-серверной архитектуре.

Решение дополняет возможности ALD Pro и закрывает те задачи, которые раньше оставались за бортом. Расскажу своими словами: что умеет ACM, из каких компонентов состоит, как лицензируется, чем отличается от Astra Automation и DCImanager, и самое главное — как вместе с ALD Pro он помогает на практике системным администраторам управлять ИТ-инфраструктурой. 

Зачем нужен ACM и при чём тут ALD Pro?

Если вы уже работали с продуктами «Группы Астра» , то наверняка слышали про ALD Pro — это средство централизованного управления доменом и базовыми инфраструктурными сервисами на Linux (мы подробно рассказывали об этом в Хабра-статье «Как мы внедряем ALD Pro: подробный обзор решения, кейсы и лайфхаки для крупных ИТ-инфраструктур»). 

Казалось бы, вопрос управления инфраструктурой в ALD Pro решен, но зачем в портфеле «Группы Астра» появляется новая система управления ACM?

Представьте типичную картину: парк из сотен машин на Astra Linux (рабочие станции сотрудников и серверы). ALD Pro отлично справляется с задачами единого входа, групповыми политиками для настройки конфигурации ОС и рабочего окружения пользователей. Но что делать с инвентаризацией «железа» и софта? Как, например, получить список всего установленного ПО на компьютерах, включая версии; отследить, кто из пользователей накатил лишний пакет; или как инвентаризировать состав аппаратного обеспечения на рабочих станциях? В этом случае приходилось либо вручную опрашивать машины, либо писать скрипты «на коленке». Согласитесь, не самая весёлая затея, особенно когда начальник срочно требует от тебя подготовки отчета для бюджетирования ИТ-инфраструктуры, или когда решения активно развиваются и приходится адаптировать свои наработки под новые версии.

Другой пример: обновление и установка ПО. В Windows-мире многие привыкли к System Center Configuration Manager (SCCM) или тому же WSUS — нажал кнопку, и по домену разлетелись обновления ПО. Как мы писали в предыдущей статье, для обновления ПО и ОС в случае ALD Pro требуется написание собственных сценариев, а в случае ACM данная функциональность работает из коробки.

Astra Configuration Manager (ACM) как раз родился, чтобы закрыть эту нишу. Он дополняет ALD Pro: берёт на себя инвентаризацию оборудования и ПО, установку и обновление ОС и приложений на компьютерах, учёт лицензий Astra Linux и прочие задачи управления конфигурациями. Проще говоря, если ALD Pro — это глава вашей инфраструктуры (пользователи, доступы, политики конфигурации), то ACM — ее «завхоз»: он знает, что у вас где установлено, следит за состоянием софта и железа и может массово ставить/обновлять/удалять приложения и системы по команде.

Связка ALD Pro + ACM фактически даёт аналог тандема Microsoft Active Directory + System Center Configuration Manager, только в реалиях Astra Linux. 

Ключевые возможности ACM

Что же конкретно умеет Astra Configuration Manager? Перечислю главные фишки решения:

• Сегменты для распределённой инфраструктуры. Большой плюс ACM в том, что он рассчитан на работу в географически распределённых сетях. Есть понятие сегментов ACM, которые позволяют вынести часть функционала на удалённые площадки. Например, у вас есть главный офис и филиалы. Вы можете поднять основной сервер ACM в центре, а в каждом филиале — легковесный сервер управления агентами (по сути, локальный Salt-master) и локальный сервер репозиториев. Эти сегменты подключаются к основному серверу, но на месте обслуживают своих «клиентов». Это даёт несколько преимуществ: снижается нагрузка на каналы связи (файлы установки и обновлений раздаются локально), повышается скорость и надёжность (даже если связь с центральным узлом временно пропадёт, сегмент продолжит управлять своими машинами). Масштабирование тоже внушительное — один сервер управления агентами ACM может держать до ~8000 клиентов, а добавляя сегменты, можно нарастить парк хоть до сотен тысяч. По сути, ACM готов к крупным внедрениям: выделил отдельные хосты для базы, брокера сообщений, сервера отчетов, распределил репозитории, серверы управления агентами и установки ОС по сегментам, и вперёд.

• Веб-портал управления. ACM предоставляет веб-портал, где видны все ваши машины, их состояние, выполненные задачи. В любой момент можно узнать статус агента на компьютере, актуален ли на нём набор ПО, успешно ли выполнилась последняя задача установки. Проще говоря, ACM постепенно становится единым «пультом управления» парком машин, где доступны и инвентаризация, и управление жизненным циклом ПО, и удалённое выполнение команд. 

• Интеграция с ALD Pro для доступа к ACM с использованием доменных учетных записей. На этапе установки основного сервера ACM в конфигурационном файле указывается доменная учетная запись (УЗ) администратора сервера управления, которая может быть как локальной, так и доменной УЗ (предварительно сервер необходимо ввести в домен). После развертывания, при первичном входе нового пользователя в интерфейс ACM под доменной УЗ пользователь получит минимальные привилегии в интерфейсе без возможности даже чтения какой-либо информации. 

Данная УЗ появится в портале управления, после чего главный администратор сможет назначить ей необходимые роли/привилегии.

• Ролевая модель ACM. Решение позволяет гибко настраивать набор возможностей управления системой. На каждый раздел в веб-интерфейсе управления есть возможность гранулярного делегирования прав, в том числе возможность предоставлять права на конкретные объекты (репозитории ПО, коллекции, профили и т.д.).

• Централизованная инвентаризация. ACM автоматически собирает детальные сведения о каждом управляемом компьютере: характеристики «железа» (процессор, память, диски, периферия и т.д.) и список установленного программного обеспечения. Достаточно установить на машину агент ACM — и она тут же отчитается в общую базу данных. Интеграция с Astra Linux реализована так, что всё работает «из коробки»: никаких дополнительных «костылей», всё уже совместимо. Вся информация сразу доступна через удобный интерфейс — можно искать и экспортировать инвентарные данные.

• Динамические коллекции. На основании данных инвентаризации можно собирать динамические группы компьютеров, соответствующих указанным правилам. Далее эти динамические группы могут использоваться для назначения профилей управления (для установки/удаления ПО), а также профилей обновления ОС. 

• Отчеты. В новой версии ACM 1.3.0 появилась возможность построения отчетов по инвентарным данным. Например, можно строить отчеты о том, на скольких ноутбуках  не хватает оперативки, у какого  процента пользователей мало места на диске, и какие версии ПО установлены в системе. Есть возможность, используя сервис отчетов на базе Apache Superset, создавать отчеты под нужды конкретной задачи/организации, например, с разбивкой по установленным версиям ОС и обновлениям, отчеты по готовности инфраструктуры к переходу на новую версию ОС, готовить «паспорта сервера/рабочей станции» для аудита ИБ и т.п.), применять различные фильтры и группировки. Так как сбор инвентарных данных выполняется регулярно, то если пользователь, скажем, изъял планку памяти или установил какой-то пакет, ACM это зафиксирует при следующем обновлении данных инвентаризации и покажет изменения в отчете. 

• Учёт лицензий Astra Linux — отдельный момент. ACM умеет учитывать лицензии операционной системы Astra Linux на всех подключенных машинах. В крупных организациях это важно, чтобы не выйти за пределы купленных лицензий. ACM соберет с каждого компьютера сведения о типе лицензии ОС Astra Linux и позволит сформировать отчёт о том, какие лицензии используются в инфраструктуре. Больше никаких табличек с ручным учетом.

• Собственные репозитории ПО. Конечно, для управления ПО нужен и источник пакетов. ACM решает это с помощью компонента «Репозиторий» на базе reprepro. Администратор может добавлять в ACM свои Debian-репозитории (например, локальное зеркало Astra Linux, а также репозиторий с внутренним ПО организации). Эти репозитории связываются с профилями: при применении профиля агент понимает, откуда тянуть нужные пакеты. Управление репозиторием осуществляется через веб-интерфейс и файловую систему сервера управления ACM — можно добавлять пакеты, обновлять их версии. 

• Управление программным обеспечением и запуск команд — пожалуй, самые востребованные функции ACM. Теперь можно из единого центра устанавливать, обновлять и удалять ПО на группах машин, а также исполнять команды/скрипты. В ACM для этого вводится понятие «профилей управления». Проще говоря, вы создаете профиль с набором пакетов (например, «Стандартный софт для бухгалтерии» или «Набор разработчика»), а затем назначаете профиль на коллекцию компьютеров. ACM сам проследит, чтобы на всех этих машинах нужные пакеты были установлены (а лишние удалены). Причём не важно, включена ли машина сейчас: как только она появится в сети, агент получит задачу дотянуть или убрать пакеты согласно профилю. При этом зачастую бывает недостаточно просто установить/удалить пакет, нужно еще выполнить дополнительные действия: настроить права доступа, установить сертификаты, выполнить команды инициализации установленного ПО, добавить ярлыки на рабочий стол — всё это и многое другое можно сделать с помощью шагов выполнения команды или скрипта, добавленных в цепочку шагов профиля. Функции обновления ПО тоже выполняются централизованно: например, вендор выпустил новую версию корпоративного приложения — вы её добавили в репозиторий ACM, обновили профиль и все выбранные ПК её получили. Это огромный шаг вперёд по сравнению с ручным обновлением или распространением самописных скриптов.

• Установка операционной системы по сети (PXE). ACM умеет разворачивать Astra Linux по сети на bare metal или виртуальную машину. Для объединения настроек при установке ОС по сети в ACM введено понятие «профилей первичной установки». Это позволяет заранее задать разные конфигурации установки для разных типов устройств — например, отдельные профили для офисных ноутбуков, рабочих станций или серверов. Всё разворачивается автоматически, без лишней ручной настройки на месте.

Профиль включает файл ответов для установщика preseed (Первичная настройка ОС, например: настройка языка, выбор раскладки клавиатуры, настройка временного пояса, разбивка диска и т.д.) и скрипт postinstall настройки (Настройка окружения ОС после установки, например: настройка сетевых репозиториев, окружения ОС). ACM установит Astra Linux из указанных репозиториев, применит нужный профиль и даже сразу подключит машину к себе как управляемую. Вуаля — через некоторое время «голое» железо превращается в рабочую станцию с нужным базовым ПО, да ещё и под управлением ACM. Это особенно выручает при массовом вводе техники или переустановке ОС — больше не нужно лично подходить к каждому компьютеру с флешкой в руках.

• Обновление ОС — ещё одна боль, которую лечит ACM: обновление версий самой операционки. Допустим, у вас парк на Astra Linux 1.7, а вышла версия 1.8 — миграция вручную на сотнях машин та ещё задача. В ACM (начиная с версии 1.2) появилась функция управления обновлением ОС. Можно централизованно запланировать и накатить минорные обновления (например, с 1.7.5 до 1.7.6), в том числе обновления безопасности или даже обновить ОС до следующего релиза (с 1.7 до 1.8) на группе машин. Разумеется, всё это с контролем статусов — вы всегда увидите, где обновление прошло успешно, а где упало с ошибкой. В случае чего, можно удалённо подключиться и выполнить ручное обновление.

Как видите, спектр возможностей достаточно широк. Причём важно отметить, что  ACM ориентирован не только на пользовательские ПК и ноутбуки, но и на серверы. 

Архитектура, состав системы, лицензирование ACM

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

Компоненты ACM состоят из systemd-сервисов, каждый из которых отвечает за свою часть: управление конфигурациями, управление инфраструктурой, авторизация, портал и т.д. Веб-интерфейс (портал) написан на ReactJS и общается с бэкендом посредством REST API. Внутри бэкенда — Python (FastAPI + uvicorn) для сервисов, PostgreSQL для хранения данных, RabbitMQ в роли брокера сообщений. 

Сильной стороной архитектуры ACM является высокая гибкость в развертывании, что позволяет адаптировать архитектуру под разные инсталляции. Размещение компонентов ACM может быть как консолидированным (все сервисы на одном сервере), так и территориально распределенным, с использованием выделенных серверов для разных компонентов ACM. Рассмотрим типовые конфигурации системы:

Ниже приведен пример распределенной архитектуры с несколькими сегментами:

Более подробное описание компонентов ACM представлено в таблице:

Особое сердце ACM — это платформа управления агентами, построенная на базе SaltStack. Фактически внутри ACM используется Salt-master, а на каждом управляемом узле — Salt-minion (агент ACM). Salt выбран не случайно — он хорошо подходит для задач постоянного управления конфигурацией. В отличие от Ansible (о нём чуть позже), Salt работает по модели «агент-сервер» и не зависит от доступности управляемых АРМов, а также отлично масштабируется за счёт асинхронной обработки задач. 

Вся тяжёлая работа — сбор инвентаризации, установка ПО, проверка состояний — выполняется агентом на машине, а центральный сервер координирует и вносит результаты в базу данных. Такой подход удобен для работы с пользовательскими АРМ, так как задачи будут выполняться при включении АРМ.

Лицензирование ACM — вопрос, который волнует многих практиков не меньше, чем технические нюансы. Здесь модель следующая: продукт лицензируется по клиентским устройствам. То есть приобретаются лицензии на каждое управляемое устройство. Сроки действия лицензий можно выбрать — на 1, 2, 3 года или бессрочно. Важно, что лицензии на ОС (например, Astra Linux для серверов и компьютеров) идут отдельно. ACM занимается учётом лицензий, но не заменяет необходимости купить ОС для АРМ и серверов. Зато с ACM у вас появляется чёткое понимание того, сколько лицензий ОС Astra Linux задействовано и где.

ACM vs. Astra Automation vs. DCImanager

Может показаться, что некоторые возможности ACM дублируются с другими продуктами Астры. Мне самому вначале вспомнился известный мем: мол, «Постойте, у нас ведь уже Astra Automation умел управлять ОС, и DCImanager вроде тоже инвентаризировать ОС… не дублируем ли функциональность?» Давайте расставим всё по местам — кто есть кто и для каких задач предназначен, потому что сходство внешнее есть, а назначение у этих продуктов разное.

Функциональный обзор решений

Функциональный обзор решений: ACM, Astra Automation и DCImanager — где чьи сильные стороны.

Astra Automation — это платформа автоматизации, появившаяся чуть раньше. Она основана на Ansible и реализует подход «инфраструктура как код» (IaC): администраторы описывают состояние серверов, сетевого оборудования и облачных ресурсов с помощью playbook’ов и ролей, а платформа обеспечивает массовое и контролируемое применение изменений. Astra Automation поддерживает автоматизацию для Linux, Windows, сетевых устройств, облаков, интегрируется с отечественными сервисами безопасности, эффективна для изолированных или критических инфраструктур. Стоит отметить, что платформа рассчитана на инженеров с DevOps-экспертизой и дает гибкий, централизованный и безопасный инструментарий автоматизации ИТ-задач. Можно сказать, что это инструмент в руках администратора/инженера, который сам конструирует нужные конфигурации инфраструктуры. Например, если нужно перезапустить сервис на сотне машин или развернуть сложный кластер по шагам — Astra Automation для этого идеально подходит.

Astra Configuration Manager, напротив, стремится предоставить удобные абстракции для типовых админских задач. Его философия — поменьше ручного кода, побольше готовых решений «из коробки»: вот тебе инвентаризация, вот профили ПО с автоматической настройкой, вот кнопка «установить ОС». То есть порог входа ниже: даже администратор, не знакомый с Ansible или Salt, разберётся через веб-интерфейс, как поставить пакет на 50 машин. При этом ACM менее гибкий в произвольных сценариях, чем Astra Automation: он рассчитан на определенный круг задач (инвентаризация, софт, обновления). Но разработчики уже идут навстречу — добавляют новые функциональности, например кастомные отчеты, дополнительные настройки при установке и обновлении ПО. 

Можно сказать, что ACM и Astra Automation решают похожие задачи, но с разными объектами управления:

• ACM управляет ОС и прикладным ПО на АРМ и серверах;

• Astra Automation предназначен для автоматизации и оркестрации ИТ-инфраструктуры в гетерогенных средах.

И да, небольшое техническое отличие: Astra Automation (Ansible) не требует агентов на машинах, он подключается по SSH и запускает задачи, а ACM использует постоянно работающий агент (acm-salt-minion). Из-за этого Astra Automation хорош для развертывания, обновления и настройки сложных конфигураций, а ACM — для постоянного отслеживания и поддержания желаемого состояния компьютеров.

DCImanager — продукт другого происхождения (разработка ISPsystem) и у него своя ниша: управление и мониторинг состояния физических серверов, околосерверного оборудования и инфраструктуры дата-центров. DCImanager умеет обнаруживать серверное «железо», управлять питанием, выполнять PXE-загрузку для установки ОС и прочие задачи уровня дата-центров. В чем-то он действительно пересекается с ACM. Например, через DCImanager тоже можно автоматически установить операционку на сервер (как и через ACM), но фокус DCImanager — на «железе» и низкоуровневых вещах: он оперирует стойками, коммутаторами, портами, IPLoM (IPMI), следит за вышедшими из строя компонентами и т.п. При этом на том, что сервер установлен и передан в эксплуатацию, DCImanager, по сути, свою задачу выполнил. В дальнейшем управлении ОС сервера (настройка ОС, установка ПО, инвентаризация) он уже не участвует, но занимается мониторингом состояния оборудования, контролем его исправности и управлением аппаратными настройками. Вот тут на сцену и выходит ACM, который обеспечивает дальнейшее управление и конфигурирование сервера. Иначе говоря, DCImanager — это управление и мониторинг железа и сетевого оборудования, а ACM — дальнейшее управление ОС сервера в течение всей его службы.

Что если в инфраструктуре есть и то, и другое, и третье? В больших организациях так и бывает: могут совместно использоваться все три инструмента. И это нормально — они дополняют друг друга. Например, в дата-центре: DCImanager следит за физическим парком оборудования в ЦОД, Astra Automation отвечает за автоматизацию развертывания, управления и поддержания состояния ИТ-инфраструктуры (серверов, сетевого оборудования, программного обеспечения), а ACM — за соблюдение базовых корпоративных стандартов (наборы пакетов, политика обновлений, учёт лицензий). В филиалах и на рабочих станциях: DCImanager там не нужен вовсе, Astra Automation подходит для настройки  серверов и сетевого оборудования, а ACM станет основным инструментом ИТ-отдела для поддержки и управления АРМ.

В выборе решения главное — понимать границы применения. Три человека-паука, когда присмотримся, оказываются разными героями: один — DevOps-инженер, использующий Astra Automation для автоматизированного управления серверной, сетевой и облачной ИТ-инфраструктурами, другой — администратор ЦОД, использующий DCImanager для ввода в эксплуатацию bare metal серверов и контроля их состояния, третий — системный администратор, настраивающий АРМ для пользователей. Вместо конкуренции — сотрудничество: каждый работает на своём участке.

ALD Pro + ACM в деле (пример из жизни)

Вернусь к связке ALD Pro + ACM, которая, на мой взгляд, является ключевой для экосистемы Astra. Приведу практический пример. Представим компанию, которая мигрирует с Windows на Astra Linux (довольно частый в последние годы кейс). Необходимо настроить централизованное управление, подобное тому, как это раньше делалось с Active Directory + SCCM. Мы установили контроллер домена ALD Pro: создали пользователей, группы, настроили политики (например, парольные политики, монтирование сетевых ресурсов — всё это ALD Pro умеет). Далее на очереди — подготовка парка новых рабочих станций с Astra Linux. Вот тут на сцену вышел ACM.

Развёртывание рабочих станций. Мы подняли основной сервер ACM на Astra Linux в главном офисе, а также серверы управления, репозиториев и установки ОС по сети в филиалах (сегменты ACM). Загрузили на сервер репозиториев образы Astra Linux и настроили профили установки ОС по сети с нужными параметрами (авторазметка диска, установка набора базовых пакетов, и т.д.). Новые АРМ в филиалах подключили к сети, они по PXE получили профиль установки ОС от локального сервера установки ОС по сети в сегменте ACM, который отреплицировался с основного сервера ACM. Для первичной установки ОС новые ПК обращаются к локальному серверу репозиториев в сегменте, который выступает в виде кэширующего сервера: первое обращение за пакетом ПО переадресовывается к серверу репозиториев в основном сегменте, а затем локальный сервер сегмента будет отдавать данный пакет ПО из кеша.

Включение в домен. После первичной установки ОС компьютеры появились в системе управления ACM (так как агент автоматически устанавливается при запуске скрипта “postinstall”). К сожалению, ACM не поддерживает автоматический ввод АРМ в домен при развертывании по сети, как предусмотрено, например, в ALD Pro, но я подготовил скрипт для автоматизированного ввода в домен. Этот скрипт описан в статье про ALD Pro. Его также можно использовать и в связке с ACM. После развертывания ОС администратор просто запустил скрипт, указав необходимые параметры в интерактивном режиме (УЗ администратора домена, пароль, FQDN рабочей станции).

Установка прикладного ПО. Для разных отделов мы подготовили структуру директорий (аналог подразделений в ALD Pro), добавили репозитории с прикладным ПО и для их установки создали профили управления. Например, для бухгалтеров профиль включает пакет «1С», криптобиблиотеки, специальные шрифты; для разработчиков — Git, Docker, редакторы; для обычных пользователей — базовый профиль (браузер, офис, мессенджер, почтовый клиент). Эти профили назначили соответствующим директориям в ACM и система сама распространила пакеты ПО на компьютеры. Пока сотрудники осваивали новую ОС на рабочих станциях, на них уже прилетело всё нужное ПО без нашего участия. При первичной установке «тяжелого» ПО на локальных серверах репозиториев закешировались пакеты ПО с основного сервера, что сильно уменьшило нагрузку на каналы связи.

Обновление ОС. По истечении месяца вышло новое обновление ОС Astra Linux. Благодаря встроенной функциональности ACM нам было достаточно скачать новые версии репозиториев ОС и создать профиль обновления. Мы выделили пилотную группу АРМ и применили к ней этот профиль. После чего в течении дня на выбранных АРМ прошёл апдейт ОС. В разделе «Результаты» мы отслеживали статус выполнения, а в случае неудачных попыток мы их видели и могли устранить возникшее препятствие, либо выполнить ручное обновление АРМ. Когда на пилотной группе проверили, что обновление не нарушает работу приложений пользователей, накатили его на остальные компьютеры.

Для получения статистики о количестве обновленных АРМ в инфраструктуре, мы использовали сервис отчетов ACM (на базе Apache Superset) со стандартным дашбордом, отображающим версии ОС на АРМ.

Управление конфигурациями и поддержание порядка. 

Для повседневного управления конфигурациями на АРМ мы использовали ALD Pro, в котором из коробки доступно множество шаблонов групповых политик для наиболее востребованных административных задач. Также есть возможность создавать свои групповые политики, про что я уже рассказывал в статье про ALD Pro. ACM, в свою очередь, следит за порядком в инфраструктуре, проводя регулярные инвентаризации, например, на паре АРМ мы обнаружили нехватку места и постороннее ПО, которое пользователю установил локальный администратор сегмента. 

Результат. Сочетание ALD Pro и ACM позволило добиться централизованной управляемости, сопоставимой с Windows-инфраструктурой. Главное — админы получили прозрачный обзор всего парка и рычаги воздействия на него: сразу видно, где порядок, а где требуется внимание администратора и удаленное решение проблем. И всё это — средствами отечественных программных продуктов, интегрированных между собой из коробки.

Заключение

ACM ещё молод, но активно развивается. Судя по дорожной карте, в ближайших версиях он станет ещё функциональнее. В будущем обещают доступ к рабочему столу пользователей прямо из ACM (чтобы можно было удалённо помочь или проконтролировать. Как TeamViewer, но встроенный и безопасный). Планируют добавить поддержку других отечественных ОС помимо Астры (РЕД, Альт). Также ждем расширенные отчёты по инвентаризации, новые механизмы переустановки ОС без боли и дальнейшую интеграцию с ALD Pro и другими системами.

Лично мне импонирует, что разработчики прислушиваются к сообществу. Многие возможности (например, выполнение произвольных команд при установке ПО, динамические группы компьютеров по условиям) появились именно по запросам админов, испытавших первые версии. Видно стремление сделать инструмент практичным для повседневной работы, а не только «на бумаге».

Если у вас остались вопросы или есть свой опыт с похожими системами— добро пожаловать в комментарии, обсудим. Мне самому интересно, как это выглядит со стороны читателей: сошёлся ли пазл из ALD Pro + ACM в единое целое? По моему опыту — да. И теперь в экосистеме Astra закрываются практически все базовые потребности администрирования. Но обсуждение делает нас всех только сильнее 😉