Версия 2.1

Версия 2.1#

Дата выпуска: 11.09.2026
Тип выпуска: стабильная версия

Примечание

Перед переходом на новую версию ознакомьтесь с порядком перехода с версии 2.0 и известными проблемами.

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

Главное#

Следующие обновления представляются наиболее важными:

  • Automation Dashboard – новый компонент, выполняющий анализ эффективности внедрения платформы автоматизации.

  • Контейнеризированная установка – новая модель развертывания Astra Automation.

  • Ролевой доступ к Activity Stream – ограничение просмотра потока активности на основе ролей согласно требованиям ФСТЭК России (см. доступ к журналам).

  • Расширение предварительной проверки инвентаря и его описания (Fast Fail) до начала развертывания платформы или ее обновления.

  • Исправления уязвимостей в системе безопасности.

  • Улучшение утилиты aa-setup, включая новый аргумент --ask-vault-pass, ротацию журналов, унификацию переменной admin_username, проверку кавычек в описании инвентаря.

  • Завершение технической поддержки версии 1.1 – жизненный цикл поддержки Astra Automation 1.1 истек согласно правилам.

  • Завершение поддержки Astra Linux Special Edition 1.7.7, 1.7.8 и 1.8.3 – утилита развертывания версии 2.1 останавливает работу на этих версиях при проверке совместимости ОС, а поддерживаемые версии перечислены в составе платформы.

Новые возможности и улучшения#

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

Automation Dashboard#

В платформу добавлен новый компонент – система аналитики, выполняющая анализ эффективности внедрения платформы автоматизации. Установка нового компонента является необязательной в процессе развертывания платформы. При желании систему аналитики можно установить позже, запустив утилиту развертывания aa-setup с указанием соответствующего аргумента.

Система обеспечена следующими дополнительными возможностями:

  • регистрация событий информационной безопасности в формате CEF;

  • локализация интерфейса на русский язык;

  • интеграции с GitFlic через webhook receiver;

  • возможность удаления (uninstall).

Изменения в развертывании платформы#

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

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

  • обеспечивает более простое и быстрое развертывание, в том числе в ЗПС;

  • в базовой топологии является самым легковесным вариантом развертывания;

  • развертывание платформы осуществляют с помощью утилиты aa-setup, используя те же правила описания инвентаря, что и для модели развертывания на виртуальных машинах или физических серверах из deb-пакетов;

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

Утилита развертывания aa-setup#

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

  • Обеспечение однократного ввода пароля для расшифровки конфиденциальных данных, хранимых с помощью Ansible Vault:

    • Повышает удобство и степень безопасности.

    • Добавлен аргумент --ask-vault-pass, благодаря которому aa-setup запрашивает пароль для Ansible Vault только один раз и использует его для всех операций, требующих доступа к зашифрованным данным.

  • Ротация журналов при каждом запуске:

    • Устраняет недостатки использования единого файла журналов при нескольких запусках утилиты aa-setup, предотвращая неконтролируемый рост этого файла.

    • При каждом запуске утилита создает новый файл для хранения журнала, сохраняя предыдущий c добавлением к его названию суффикса, обозначающего порядковый номер запуска, например setup.log.2. По умолчанию количество файлов не превышает 5. Для изменения этого предела предусмотрен аргумент --log-rotation-limit (-lrt). При достижении лимита самый старый файл удаляется.

  • Переход к единой паре реквизитов для доступа к платформе:

    • Упрощает процесс установки и управления платформой, повышает безопасность.

    • Ранее для доступа к различным компонентам платформы требовалось использовать разные реквизиты, что усложняло администрирование. Теперь администраторы используют единую пару admin_username и admin_password для доступа ко всем компонентам. Наличие этой пары в описании инвентаря входит в процесс предварительной проверки (Fast Fail).

  • Пропуск ненужных долгих операций:

    • Ускоряет повторные запуски aa-setup, пропуская шаги миграции, копирование содержимого установочного пакета без доступа к интернету и установку deb-пакетов.

    • Для пропуска этих операций предусмотрен аргумент --fast (-F).

  • Поддержка отдельного сертификата TLS для взаимодействия шлюза платформы с внешним балансировщиком:

    • Позволяет использовать независимый сертификат TLS для балансировщика.

    • Для указания сертификата и связанного с ним ключа в описании инвентаря предусмотрены переменные automationgateway_external_ssl_cert и automationgateway_external_ssl_key. Обе задают вместе, иначе установка прерывается на предварительной проверке.

Предварительная проверка инвентаря и его описания (Fast Fail)#

При запуске утилиты aa-setup для развертывания, миграции или обновления платформы происходит предварительная проверка инвентаря и его описания на соответствие требованиям, изложенным в документации. В новой версии добавлены следующие проверки, предназначенные для специалистов по развертыванию и администрированию платформы и доступные сразу после установки пакета для развертывания Astra Automation:

  • синхронизация системного времени на всех узлах;

  • сетевая доступность между компонентами;

  • наличие требуемого объема свободного дискового пространства на установочном узле;

  • наличие и корректность параметра automationgateway_main_url;

  • доступность базы данных Automation Gateway;

  • корректность применения кавычек в описании инвентаря.

Automation Controller#

Произведены улучшения в функциональности Automation Controller, доступные сразу после обновления платформы на новую версию:

  • Изменение порядка аргументов в опросе для типов «Множественный выбор» и «Одиночный выбор из списков» при создании и настройке шаблона заданий:

    • Предназначено для разработчиков заданий.

    • Позволяет гибко управлять порядком вариантов ответа в опросе (survey).

    • Порядок аргументов теперь можно изменять без повторного создания запроса на ввод переменной.

    • Новая возможность доступна сразу после обновления платформы на новую версию.

  • Интеграция с GitFlic:

    • Предназначена для команд разработки и DevOps.

    • Позволяет получать и обрабатывать события из GitFlic от сервиса webhook.

    • Для этого в графической консоли контроллера добавлен пункт GitFlic в выпадающем списке Webhook service.

    • Новая возможность доступна сразу после обновления платформы на новую версию.

Event-Driven Automation#

В Event-Driven Automation (EDA) снято ограничение на прием событий из Apache Kafka:

  • Предназначено для команд, использующих EDA с Kafka.

  • Устраняет искусственный потолок на количество получаемых событий.

  • Доступно сразу после обновления платформы на новую версию.

Content Development Kit#

Утилита Ansible Navigator в составе Content Development Kit (CDK) теперь по умолчанию использует Execution Environment (EE) версии 2.0 вместо EE 1.0:

  • Предназначено для разработчиков контента и авторов коллекций.

  • Обеспечивает совместимость с актуальной средой выполнения Astra Automation 2.x.

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

Коллекции#

Созданы новые и обновлены существующие коллекции Ansible, доступные в Automation Hub.

  • astra.brestng:

    • Новая коллекция для управления облачной платформой ПК СВ «Брест» нового поколения.

  • astra.gitflic:

    • Новая коллекция для развертывания GitFlic Server и GitFlic Runner, а также управления проектами, членством и исполнителями через REST API. Включает роли server и runner и модули gitflic_project, gitflic_membership, gitflic_user_ssh_key и другие.

  • astra.litellm:

    • Новая коллекция для развертывания и настройки LiteLLM Proxy, а также декларативного управления моделями, виртуальными ключами API, командами и пользователями. Включает роль proxy_server и модули model, key, team, user, budget и другие.

  • astra.ald_pro:

    • Добавлена переменная aldpro_client_ou для размещения компьютера в указанном подразделении (OU) при вводе в домен (ALD Pro 3.0.0+).

    • Для подсистемы replica добавлена поддержка ролей Global Catalog и PKI-Proxy в модулях subsystem, dc_info и в роли replica.

    • Добавлена поддержка ALD Pro 3.3.0: обновлена матрица совместимости и добавлен путь обновления с версии 3.2.0 до версии 3.3.0.

    • Значение aldpro_version по умолчанию изменено на 3.3.0.

    • Добавлены модули:

      • policy_update – выполнение обновления политик на контроллере домена;

      • dnsconfig – управление глобальной конфигурацией DNS FreeIPA;

      • subsystem_info – получение статуса подсистем ALD Pro.

    • Реализовано обновление контроллера и подсистем (audit, cups, dhcp, mon, pxe, repo, smb) с проверкой допустимости перехода по матрице совместимости (переменная aldpro_upgrade_matrix).

    • Добавлены переменные для контроля времени ожидания и повторов операций: aldpro_subsystem_status_retries, aldpro_subsystem_retry_timeout, aldpro_controller_state_check_retries, aldpro_client_nm_reconnect_timeout, aldpro_ldap_wait_retries и другие.

    • Добавлена проверка версии Astra Linux Special Edition при развертывании серверной группы (переменная aldpro_server_os_matrix). Попытка установки ALD Pro на более старую версию операционной системы завершается понятным сообщением об ошибке. Начиная с ALD Pro 3.3.0 серверная группа поддерживает развертывание на Astra Linux Special Edition 1.8.

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

    • Исправлено чтение списков API ALD Pro, возвращаемых постранично: ранее обрабатывались только первые 25 записей, что приводило к неполным спискам компьютеров, групп и подсистем в больших доменах.

    • Исправлены идемпотентность регистрации подсистем, обработка разрывов соединения с API ALD Pro, порядок обновления контроллера и ряд ошибок установки подсистем и клиентов.

    • В ветвь 1.0.x (LTS) перенесено исправление проверки клиента домена в модуле subsystems: на доменах с более чем 25 компьютерами проверка завершалась ошибкой, а сравнение имен узлов выполнялось по подстроке (версии 1.0.4 и 1.0.5).

  • astra.astralinux:

    • Добавлены опции модуля astra_migrate: nesting_upgrade, upgrade_ssh_port и in_place.

    • Добавлена поддержка Astra Linux Special Edition 1.8.6.

    • Исправлена передача опций force и self-upgrade в утилиту astra-console-upgrade.

  • astra.ceph:

    • Исправлен аварийный отказ задачи lvcreate при развертывании на сервере без установленной операционной системы (bare metal) и на Astra Linux Special Edition 1.7.4.UU1.

  • astra.chrony:

    • Добавлена поддержка Astra Linux Special Edition 1.7.10 и 1.8.6.

  • astra.cups:

    • Добавлена поддержка Astra Linux Special Edition 1.7.10 и 1.8.6.

  • astra.dhcp:

    • Добавлена поддержка Astra Linux Special Edition 1.7.10 и 1.8.6.

  • astra.etcd:

    • Добавлена переменная etcd_enable_v2 для поддержки клиентов, использующих устаревший протокол v2 (например, Patroni).

    • Добавлены переменные etcd_listen_address и etcd_advertise_address для раздельного задания адреса прослушивания и объявляемого адреса.

    • Добавлена проверка минимальной версии Astra Linux Special Edition (1.7.2) с понятным сообщением об ошибке.

    • Добавлены типовые наборы переменных и примеры описания инвентаря для конфигураций без TLS и с взаимной аутентификацией (mTLS).

    • Исправлено разрешение peer-адресов в ETCD_INITIAL_CLUSTER для кластеров из нескольких узлов.

    • В образ устанавливается пакет etcd-client, предоставляющий утилиту etcdctl.

    • Добавлена поддержка Astra Linux Special Edition 1.8.6.

  • astra.haproxy:

    • Добавлена поддержка секций listen (переменная haproxy_listen), объединяющих frontend и backend, с параметрами bind, mode, balance, server и другими.

    • Добавлены параметры SSL для bind и параметры проверки взаимного TLS (mTLS) для default-server.

    • Добавлена сборка PEM-пакетов из сертификата и ключа (переменная haproxy_ssl_bundles).

    • Добавлено автоматическое восстановление сервиса после сбоя через systemd (переменные haproxy_service_restart_enabled, haproxy_service_restart, haproxy_service_restart_sec).

    • Исправлен тип переменной haproxy_global_daemon, из-за которого директива daemon не попадала в конфигурацию.

  • astra.iscsi:

    • Добавлена поддержка Astra Linux Special Edition 1.7.10 и 1.8.6.

  • astra.keepalived:

    • Изменено значение nopreempt по умолчанию на false. Теперь работает приоритетный режим, при котором VIP-адрес всегда указывает на исправный узел с наивысшим приоритетом.

    • Исправлен шаблон keepalived.conf. Теперь enable_script_security генерируется как флаг без значения, а priority можно переопределить для отдельного экземпляра VRRP.

    • В документацию роли добавлены готовые конфигурации для кластеров PostgreSQL.

  • astra.nfs:

    • Добавлена поддержка Astra Linux Special Edition 1.7.10 и 1.8.6.

  • astra.ocfs2:

    • Добавлена поддержка Astra Linux Special Edition 1.7.10 и 1.8.6.

  • astra.postgresql:

    • Добавлен режим внешнего управления, который устанавливает PostgreSQL без создания и запуска основного кластера из состава пакета.

    • Добавлены настраиваемые профили безопасности Astra Linux Special Edition для ac_ignore_maclabel и pdpl-user с mswitch, включая поддержку внешнего конфигурационного файла.

    • Добавлена поддержка Astra Linux Special Edition 1.8.6.

    • Удален пакет libpq-dev. Теперь библиотека libpq5 устанавливается как зависимость пакета postgresql.

    • Исправлен перезапуск после переконфигурации. Теперь процесс ожидает появления SSL-сертификата, на который указывает новая конфигурация.

  • astra.rabbitmq:

    • Добавлена поддержка Astra Linux Special Edition 1.8 (режимы Orel, Voronezh и Smolensk).

    • В Astra Linux Special Edition Smolensk (MAX) служебной учетной записи rabbitmq назначается уровень целостности PARSEC, необходимый для работы rabbitmqctl (добавлена зависимость от astra.astralinux).

    • Исправлено название переменной rabbitmq_node_prefix.

  • astra.repo_mirror:

    • Добавлена поддержка Astra Linux Special Edition 1.7.10 и 1.8.6.

  • astra.rubackup:

    • Добавлена переменная rubackup_version. Значение по умолчанию – последняя доступная версия RuBackup.

    • Добавлен модуль postgresql для управления конфигурацией RuBackup PostgreSQL Universal.

    • Добавлены модули pg_dump_database и pg_dump_table для управления конфигурацией RuBackup PG_dump.

  • astra.rupost:

    • Версия RuPost 4.2.2 добавлена в матрицу совместимости.

    • Значение переменной rupost_version по умолчанию изменено на 4.2.2.

  • astra.termidesk:

    • Добавлены матрицы последовательного обновления Termidesk (переменная termidesk_upgrade_matrix) и переменная termidesk_upgrade_reboot для управления перезагрузкой после обновления.

    • Роли автоматически определяют установленную версию пакета и выбирают установку, обновление или пропуск действия.

    • Добавлена поддержка Termidesk 7.0.1 на Astra Linux Special Edition 1.8.2.UU1 (Orel).

    • Удалены роли astra.termidesk.gateway и astra.termidesk.common.

Зависимости коллекций Ansible (например, коллекции community.*) теперь размещаются на публичном Automation Hub. Это позволяет разрешать зависимости при установке коллекций и сборке образов сред исполнения без обращения к внешнему Ansible Galaxy.

Среда исполнения#

Произведены следующие изменения в образах среды исполнения.

Образ aa-minimal-ee:

  • Образ переведен на новый базовый образ с поддержкой Astra Linux Special Edition 1.8.6.

  • Ansible Core устанавливается из репозитория операционной системы.

  • Устранены лишние предупреждения при запуске EE и DE на Astra Linux Special Edition 1.8.5 и новее.

Образ aa-full-ee:

  • Образ переведен на новый базовый образ с поддержкой Astra Linux Special Edition 1.8.6.

  • Добавлены коллекции:

    • astra.brestng;

    • astra.gitflic;

    • astra.litellm.

  • Обновлены следующие коллекции:

    • astra.aa_controller,

    • astra.ald_pro,

    • astra.astralinux,

    • astra.ceph,

    • astra.chrony,

    • astra.cups,

    • astra.dhcp,

    • astra.etcd,

    • astra.haproxy,

    • astra.hardening,

    • astra.iscsi,

    • astra.keepalived,

    • astra.nfs,

    • astra.ocfs2,

    • astra.postgresql,

    • astra.rabbitmq,

    • astra.repo_mirror,

    • astra.rubackup,

    • astra.rupost,

    • astra.termidesk,

    • orionsoft.zvirt.

Образ aa-control-ee перебазирован на новую версию aa-minimal-ee.

Образ aa-minimal-de перебазирован на новую версию aa-minimal-ee.

Образ aa-full-de:

  • перебазирован на новую версию aa-minimal-ee;

  • обновлена коллекция ansible.eda до версии 2.10.0;

  • добавлен пакет libpq5 и закреплены версии Python-пакетов (jsonschema, psycopg и других), совместимые со средой выполнения платформы.

Безопасность#

  • Профили безопасности Redis – глобальная переменная redis_security задает раскладку подключений Redis одним из трех профилей: default, hardened или hardened_nopass (см. Профиль безопасности).

    В профиле default – конфигурации по умолчанию – локальные экземпляры Redis на узлах Automation Controller и Private Automation Hub переведены с локального порта TLS на сокет Unix без пароля и доступны только процессам своего узла. Раскладка по умолчанию меняется только для новых развертываний: при обновлении существующего стенда утилита развертывания определяет его текущую раскладку и сохраняет ее.

Исправление ошибок#

Ниже перечислены наиболее значимые исправления.

Утилита aa-setup#

Внесены следующие исправления в утилиту aa-setup:

  • Исправлено поведение утилиты при использовании совместно аргументов --os-compatibility-update и --file для изменения матрицы совместимости из файла. Ранее запуск утилиты с этими аргументами завершался аварийно.

  • Исправлена процедура развертывания платформы с подключением к внешнему балансировщику, FQDN которого указывался с помощью переменной automationgateway_main_url. Ранее по умолчанию утилита создавала в настройках платформы ссылку на балансировщик, которая содержала ошибочно порт TCP 8443 вместо 443.

  • Исправлено поведение процесса Fast Fail в среде Ansible Core 2.18, так чтобы он выполнял все проверки независимо от количества обнаруженных ошибок. Ранее процесс прерывался при обнаружении первой ошибки без выполнения последующих проверок.

  • Исправлена некорректная ссылка на страницу документации в сообщениях процесса Fast Fail.

  • Исправлен процесс проверки того, что порты HTTP/HTTPS, необходимые для работы компонентов платформы на соответствующих узлах, не заняты какими либо сервисами или процессами на этих узлах.

  • Обеспечена сборка резервной копии в каталоге, указанном аргументом -b. Ранее в версии 2.0, резервная копия в указанном каталоге не создавалась.

Platform Gateway#

Внесены следующие исправления в шлюзе платформы:

  • Исправлено отображение полного списка существующих ролей пользователя при добавлении ему новых ролей. Ранее администратору, даже с ролью Organization Admin, при добавлении роли какому-нибудь пользователю, не были видны роли, которые уже были назначены этому пользователю ранее.

  • Обеспечена доступность методов RBAC контроллера EDA в точке доступа api/eda/v1/. Ранее эти методы не показывались.

  • Исправлены шрифты кириллицы в графической консоли.

  • Обеспечена нормальная скорость отрисовки графических панелей на вкладках Jobs и Templates. Ранее этот процесс длился долго, до 10 сек.

Automation Controller#

Внесены следующие исправления в Automation Controller:

  • В графической консоли обеспечено присутствие поля Лимит (Limit) в закладке Подробности (Details) задания. Ранее в версии 2.0 это поле отсутствовало.

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

  • В графической консоли восстановлено отображение сведений о ветке SCM в закладке Подробности (Details) задания. Ранее в версии 2.0 это поле отсутствовало.

  • В графической консоли в списке ролей исправлен перевод на русский язык роли Audit Organization, название которой несет императивный смысл и должно интерпретироваться как Аудит организации. Ранее это было ошибочно переведено как «Аудиторская организация».

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

Private Automation Hub#

Внесены следующие исправления в Private Automation Hub:

  • Исправлена ошибка синхронизации предустановленного репозитория aa-certified с внешним репозиторием на Automation Hub.

  • Исправлена ошибка аутентификации при локальном подключении к API узла реестра.

  • Исправлена ошибка разрыва сеанса связи (logout) при локальном подключении к Private Automation Hub.

Устранение уязвимостей#

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

  • setuptools

  • jackson-databind

  • jinja2

  • ansible-core

  • Django

  • aiohttp

  • awx

  • aa-setup

  • eda-server

  • aa-gateway

  • ansible-ui

Известные проблемы#

В версии 2.1 обнаружены следующие недостатки:

  • При установке Automation Dashboard из установочного пакета без доступа к интернету (offline bundle) утилита aa-setup проверяет сертификат Automation Gateway, даже если в описании инвентаря указано dashboard_ssl=false. Если сертификат шлюза выпущен центром сертификации, который отсутствует в системном хранилище доверенных сертификатов узла шлюза, установка завершается ошибкой CERTIFICATE_VERIFY_FAILED на задаче Query gateway admin user. До исправления этого поведения необходимо явно отключить проверку сертификата, указав в описании инвентаря:

    aap_auth_provider_check_ssl=false

  • Утилита aa-setup заменяет ранее настроенные образы Default Job Execution Environment и Control Plane Execution Environment на стандартные образы целевой версии, если при обновлении платформы (aa-setup --upgrade) эти параметры не переданы повторно явно. После обновления узлы Automation Controller и сети Mesh не могут получить подставленный образ, поэтому запуск сценариев в ранее настроенном Default Job Execution Environment завершается ошибкой. До исправления этого поведения при выполнении обновления необходимо повторно передать оба ранее настроенных образа явно:

    ./aa-setup -p ~/ --upgrade \
  --repo-url "<repo_url>" \
  --default-job-ee "<default_job_ee>" \
  -- -e "control_plane_execution_environment=<control_plane_ee>"

    Здесь:

    • <repo_url> – адрес репозитория пакетов целевой версии платформы;

    • <default_job_ee> – образ, ранее настроенный как Default Job Execution Environment;

    • <control_plane_ee> – образ, ранее настроенный как Control Plane Execution Environment.

  • При удалении платформы, установленной из репозитория deb-пакетов или из установочного пакета без доступа к интернету, утилита aa-setup может прерваться на удалении пользователя eda. Команда userdel возвращает код 8, поскольку у пользователя остается процесс в podman-scan.service. Последующие компоненты, включая установленный Automation Dashboard, при этом не удаляются.

    До исправления этого поведения непосредственно перед полным удалением платформы необходимо остановить сервисы и процессы EDA на каждом узле группы automationedacontroller. В оболочке Bash от имени root выполните:

    mapfile -t eda_units < <(
  {
    systemctl list-unit-files --type=service --no-legend |
      awk '$1 ~ /^automation-eda-controller.*\.service$/ {print $1}'
    systemctl list-units --type=service --all --no-legend |
      awk '$1 ~ /^automation-eda-controller.*\.service$/ {print $1}'
  } | sort -u
)

systemctl disable --now "${eda_units[@]}" || true
systemctl stop "${eda_units[@]}" || true
systemctl mask --runtime "${eda_units[@]}" || true

systemctl disable --now podman-scan.service || true
systemctl stop podman-scan.service || true
systemctl mask --runtime podman-scan.service || true

loginctl disable-linger eda || true
loginctl terminate-user eda || true

eda_uid=$(id -u eda)
for _ in $(seq 1 30); do
  pgrep -u "$eda_uid" >/dev/null 2>&1 || break
  pkill -KILL -u "$eda_uid" || true
  sleep 1
done

test -z "$(pgrep -u "$eda_uid" || true)"

    Ожидаемый результат: последняя команда завершается с кодом 0 на каждом узле EDA, то есть процессов пользователя eda не осталось. Если проверка завершается ошибкой, необходимо устранить оставшиеся процессы до запуска удаления. После успешной проверки на всех узлах EDA выполните на установочном узле из каталога с aa-setup:

    sudo ./aa-setup --uninstall -y --plain

    Предупреждение

    Эти команды предназначены только для подготовки к полному удалению платформы. Они останавливают EDA и отключают автоматический запуск его сервисов и podman-scan.service. Перезагрузка не отменяет действие disable --now.

    Если удаление платформы прервано и ее решено оставить, отключенные сервисы необходимо вернуть в работу, иначе после перезагрузки они не запустятся. Восстановление обычно выполняют позже и в новой оболочке, поэтому команды заново получают список сервисов EDA. На каждом узле EDA от имени root выполните:

    mapfile -t eda_units < <(
  {
    systemctl list-unit-files --type=service --no-legend |
      awk '$1 ~ /^automation-eda-controller.*\.service$/ {print $1}'
    systemctl list-units --type=service --all --no-legend |
      awk '$1 ~ /^automation-eda-controller.*\.service$/ {print $1}'
  } | sort -u
)

systemctl unmask "${eda_units[@]}" || true
systemctl enable --now "${eda_units[@]}"

systemctl unmask podman-scan.service || true
systemctl enable --now podman-scan.service

loginctl enable-linger eda

    Ожидаемый результат: systemctl is-enabled для перечисленных сервисов возвращает enabled.

  • При резервном копировании платформы, развернутой в контейнерах, командой sudo ./aa-setup -b --containerized архив создается от имени root и недоступен для чтения учетной записи, вызвавшей sudo. Если установлен Automation Dashboard, этой учетной записи также недоступно содержимое каталога /var/backups/astra-automation/ и отдельный архив Automation Dashboard. Операция резервного копирования при этом может завершиться успешно.

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

    backup_user='<account>'
backup_group=$(id -gn "$backup_user")
backup_path='/var/backups/astra-automation'
backup_archive="$backup_path/astra-automation-backup-<timestamp>.tar.gz"

sudo chown "$backup_user:$backup_group" "$backup_path" "$backup_archive"
sudo chmod 0750 "$backup_path"
sudo chmod 0600 "$backup_archive"

    Здесь:

    • <account> – учетная запись, вызвавшая резервное копирование через sudo, которой необходимо прочитать или скопировать архив;

    • <timestamp> – метка времени в названии созданного архива. Названия файлов выводит команда sudo ls -l /var/backups/astra-automation/.

    Если установлен Automation Dashboard, в той же оболочке дополнительно выполните:

    dashboard_archive="$backup_path/astra-automation-dashboard-backup-latest.tar.gz"
sudo chown "$backup_user:$backup_group" "$dashboard_archive"
sudo chmod 0600 "$dashboard_archive"

    Итоговый архив собирается в каталоге backup_dest на установочном узле, и именно его путь подставляют в backup_path. По умолчанию это /var/backups/astra-automation/, а другой каталог задают позиционным аргументом после -b, например sudo ./aa-setup -b /opt/backups/, или переменной backup_dest. Каталог backup_dir, в котором узлы компонентов держат промежуточные файлы, для доступа к резервной копии менять не нужно, и по умолчанию он совпадает с backup_dest (см. резервное копирование). Изменение владельца основного архива также обеспечивает доступ к нему через указывающую на него символическую ссылку. Ожидаемый результат: выбранная учетная запись может просмотреть каталог и прочитать созданные архивы. Режим доступа 0750 для каталога и 0600 для архивов сохраняет ограниченный доступ к резервным копиям. После следующего резервного копирования через sudo может потребоваться повторное изменение владельца и режима доступа.

Переход на версию 2.1 с версии 2.0#

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

Платформа на виртуальных машинах (deb-пакеты)#

Платформу, развернутую на виртуальных машинах из deb-пакетов, переводит на версию 2.1 утилита развертывания aa-setup версии 2.1 с аргументом --upgrade. Утилита обновляет все компоненты платформы за один запуск, повторное развертывание не требуется.

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

  1. Проверьте версию Astra Linux Special Edition на каждом узле платформы:

    cat /etc/astra_version

    Утилита развертывания версии 2.1 поддерживает только версии Astra Linux Special Edition, перечисленные для версии 2.1 в составе платформы, и прерывает обновление на предварительной проверке, если хотя бы один узел работает на другой версии. Если узел работает на Astra Linux Special Edition 1.7.7, 1.7.8 или 1.8.3, до перехода обновите на нем операционную систему до версии, которую поддерживают обе версии платформы (1.7.9.UU1 для узлов на Astra Linux Special Edition 1.7, 1.8.4 или 1.8.5 для узлов на Astra Linux Special Edition 1.8). После обновления операционной системы убедитесь, что платформа версии 2.0-upd2 работает, и только затем переходите к следующему шагу.

  2. Подключите на установочном узле репозиторий пакетов Astra Automation версии 2.1 и установите из него утилиту aa-setup версии 2.1 (пакет astra-automation-setup).

  3. Запустите обновление:

    sudo ./aa-setup --upgrade

    Если на платформе настроены собственные образы Default Job Execution Environment и Control Plane Execution Environment, передайте их при обновлении повторно, как описано в известных проблемах.

  4. При необходимости установите новый компонент Automation Dashboard отдельным запуском aa-setup с аргументом --dashboard-only.

Платформа в кластере Kubernetes#

Платформу версии 2.0-upd2, развернутую в кластере Kubernetes, переводят на версию 2.1 операторы платформы без повторного развертывания. После установки операторов новой версии и обновления манифеста приложения они переводят компоненты платформы на образы новой версии, развертывают Automation Dashboard и импортируют в Private Automation Hub контент новой версии. Порядок подготовки, размещения образов, обновления и проверки приведен в инструкции по обновлению в Kubernetes. Перед началом работ ознакомьтесь со списком известных проблем обновления в Kubernetes.