Управление топологией системы автоматизации операций

Содержание

Управление топологией системы автоматизации операций#

Топология системы не является статичной и может изменяться по мере роста инфраструктуры, увеличения нагрузки или изменения требований безопасности. К таким изменениям относятся подключение новых узлов, добавление переходных узлов или адаптация Automation Mesh к изменившимся сетевым условиям. Платформа поддерживает централизованное управление топологией без ее повторного развертывания.

Архитектурные особенности Automation Mesh и моделей соединений подробно рассмотрены в описании архитектуры.

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

Топология на базе ВМ#

В среде виртуальных машин Automation Mesh формируется на основе описания инвентаря для утилиты aa-setup. В описании инвентаря указывают:

управляющие узлы;
исполняющие узлы;
переходные узлы (при необходимости);
параметры взаимодействия между ними.

После изменения описания инвентаря выполняют обновление сети Mesh и ее узлов путем запуска aa-setup.

Для добавления плоскости исполнения в топологию на базе ВМ выполните следующие шаги:

Убедитесь, что исполняющие и переходные (при наличии) узлы подготовлены согласно требованиям.
Обновите описание инвентаря.

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

Топология в кластере Kubernetes#

При использовании Kubernetes плоскость управления развертывается внутри кластера, что накладывает ограничения на установление входящих соединений. В этом случае узлы плоскости исполнения не устанавливают прямые входящие соединения к Automation Controller.

Добавление плоскости исполнения может выполняться двумя способами:

добавление отдельных узлов с помощью графического интерфейса;
централизованное добавление нескольких узлов с использованием ansible-navigator.

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

Исполняющему узлу требуется Podman, так как через него запускаются контейнеры сред исполнения при выполнении заданий. Требования к узлу приведены в описании подготовки топологии: базовой и уровня предприятия.

Важно

Сценарии установки и обслуживания узлов выполняются в среде исполнения (параметр --eei утилиты ansible-navigator) с помощью коллекции astra.receptor из указанного образа. Deb-пакеты Receptor также поставляются в образе среды исполнения. Версия платформы, для которой собран образ, указана в суффиксе тега; например, тег 1.2.0-aa2.0 соответствует платформе версии 2.0. Используйте образ aa-full-ee с суффиксом своей версии платформы. Образ, собранный для другой версии платформы, содержит коллекцию astra.receptor неподходящей версии, поэтому сценарий может завершиться ошибкой. Из нескольких версий образа с одинаковым суффиксом используйте последнюю. Если добавляемые узлы функционируют на Astra Linux Special Edition 1.7, используйте вариант образа с дополнительным суффиксом ansible2.15, например тег 1.0.0-aa2.0-ansible2.15, так как версия Ansible Core из основного варианта образа несовместима с Python 3.7 этой операционной системы. Подробности приведены в примечаниях к выпуску. Обновление платформы не затрагивает уже подключенные узлы, поэтому повторно запускать сценарий после обновления не требуется; при следующем запуске сценария используйте актуальную версию образа.

Добавление одиночных узлов#

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

Убедитесь, что исполняющий узел подготовлен согласно требованиям, включая доступ к реестру образов и доверие его сертификату.
Перейдите в графическую консоль Astra Automation.
На панели навигации выберите Автоматизация процессов ‣ Инфраструктура ‣ Узлы (Automation Execution ‣ Infrastructure ‣ Instances) и начните добавлять узел, нажав на кнопку Создать исполняющий узел (Create instance).
В окне Создать исполняющий узел (Create instance) настройте следующие поля:
- Название узла (Host name): название узла, конвертируемое в IP-адрес через DNS или файл /etc/hosts;
- Порт прослушивания (Listener port): 27199;
- Тип узла (Instance type): Исполнение (Execution);
- Опции (Options): выберите все опции: Включить исполняющий узел (Enable instance), Управляется политикой (Managed by policy) и Узлы-пиры с управляющих узлов (Peers from control nodes).
Нажмите кнопку Создать исполняющий узел.
В открывшемся окне нажмите кнопку Загрузить пакет (Download bundle) для выгрузки установочного пакета.
Распакуйте этот пакет на установочный узел.
Перейдите в распакованный каталог.
Убедитесь, что в файле описания инвентаря inventory.yml правильно настроены следующие параметры (согласно настройкам в добавляемом узле):
- ansible_user – название учетной записи с административными привилегиями, например, admin.
- ansible_ssh_private_key_file – путь к приватному ключу SSH для этой учетной записи, например, ~/.ssh/id_ed25519.
  
  Альтернативный способ передачи ключей SSH см. в следующем шаге.
Если на предыдущем шаге значение параметра ansible_ssh_private_key_file не было задано, необходимо запустить агент SSH и добавить в него ключи доступа к узлам плоскости исполнения:
```
eval $(ssh-agent -s)
ssh-add <path_to_ansible_ssh_private_key_file>
```
Утилита ansible-navigator использует запущенный агент SSH для аутентификации при подключении к исполняющим узлам.
Выполните сценарий настройки узла:
```
ansible-navigator run install_receptor.yml \
   -i inventory.yml \
   --eei hub.astra-automation.ru/aa-2.0/aa-full-ee:1.2.0-aa2.0 \
   -m stdout
```
Образ среды исполнения в команде приведен для иллюстрации. Подставьте актуальную версию образа aa-full-ee для своей версии платформы согласно правилу выбора образа. Состав образов описан в справочнике образов. Образ можно получить из облачного реестра Automation Hub (при доступе к интернету), из приватного реестра развернутой платформы либо из офлайн-пакета CDK.

Офлайн-пакет CDK содержит архивы образов в каталоге /opt/rbta/aa/CDK-setup/aa-ee-images/, а его установщик загружает эти архивы только в хранилище Podman пользователя root. Утилита ansible-navigator ищет образ в хранилище Podman пользователя, запускающего команду, поэтому загрузите образ в хранилище своего пользователя, выполнив команду podman load без sudo:
```
sudo cat /opt/rbta/aa/CDK-setup/aa-ee-images/aa-full-ee.tar | podman load
```
Команда выводит название загруженного образа в строке Loaded image. Укажите это название вместе с тегом в параметре --eei и добавьте к команде запуска сценария параметр --pp never, так как утилита по умолчанию загружает образ с тегом latest из реестра даже при наличии локальной копии.

По завершении выполнения сценария выводится строка вида:
```
PLAY RECAP **********************************************************************************************
remote-execution  : ok=71   changed=40   unreachable=0    failed=0    skipped=10   rescued=0    ignored=0
```
В графической консоли платформы убедитесь, что состояние добавленного узла стало Ready.

Если узел остается в состоянии installed, причину ищите в журнале службы Receptor на самом узле – см. примечание в инструкции по подключению группы узлов.

Добавление группы узлов в плоскости исполнения#

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

Убедитесь, что исполняющие и переходные узлы (при наличии) подготовлены согласно требованиям, включая доступ к реестру образов и доверие его сертификату.
Подготовьте приватный ключ SSH, который предоставляет пользователю доступ к добавляемым узлам с привилегиями администратора.
Создайте токен доступа для пользователя admin:
1. В графической консоли перейдите в Управление доступом ‣ Пользователи (Access Management ‣ Users).
2. В списке пользователей выберите admin.
3. Переключитесь на вкладку Токены (Tokens) и нажмите кнопку Создать токен (Create token).
4. В поле Область (Scope) выберите Писать (Write).
5. Нажмите внизу кнопку Создать токен (Create token). Сохраните токен в надежном месте, поскольку после закрытия окна он не будет более доступен.
Подготовьте файл описания инвентаря, например inventory.yml, следующего вида:
```
---
all:
  vars:
    ac_host: "https://aa.demo.example.com"
    ac_token: "6JShbAmkz9k5QyMKGX6ZUGTCjfZzJs"
    ansible_ssh_common_args: "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null"

  children:
    hop_nodes:
      hosts:
        hop-node-01:
          ansible_host: 10.177.93.56
          ansible_user: admin
          ansible_ssh_private_key_file: keys/id_ed25519
    execution_nodes:
      hosts:
        exec-node-01:
          ansible_host: 10.177.93.13
          ansible_user: admin
          ansible_ssh_private_key_file: keys/id_ed25519
          hop_node_related: "hop-node-01"
          peers_from_control_nodes: false
```
Файл содержит настройки общих переменных и настройки параметров доступа для переходных узлов (группа hop_nodes) и исполняющих узлов (группа execution_nodes). В файле необходимо задать следующие переменные в соответствии с параметрами добавляемых узлов:
- ac_host: URL к шлюзу платформы.
- ac_token: подготовленный токен для пользователя admin.
- ansible_host: IP-адрес соответствующего узла.
  
  Укажите эту переменную только в том случае, если доступ к узлу осуществляется по IP-адресу, а не по его FQDN.
- ansible_user: название учетной записи с привилегиями администратора на соответствующем узле.
- ansible_ssh_private_key_file: путь к приватному ключу SSH для этой учетной записи.
  
  Альтернативный способ передачи ключей SSH см. в следующем шаге.
- hop_node_related (требуется, если подключение выполняется через переходный узел (hop node)): параметр подключения к переходному узлу – значение inventory_hostname или идентификатор receptor_address, если переходный узел уже существует.
- peers_from_control_nodes: true, если узел подключается напрямую к плоскости управления, или false, если через переходный узел.
  
  Примечание
  
  Если одновременно заданы переменные hop_node_related и peers_from_control_nodes=true, то приоритет будет иметь peers_from_control_nodes. Это значит, что исполняющий узел будет подключен напрямую к контроллеру.
Важно

Параметры топологии – hop_node_related и peers_from_control_nodes – применяются только при первом подключении узла. Для уже добавленного узла повторный запуск сценария их не изменяет: сценарий завершается успешно, но узел продолжает использовать прежнее подключение. Чтобы изменить топологию работающего узла, удалите его запись в Automation Controller и подключите узел заново.

Если требуется подключить создаваемые исполняющие узлы к переходным узлам, размещенным внутри кластера Kubernetes (Mesh Ingress), в переменной hop_node_related необходимо указать идентификатор receptor_address используемого переходного узла. Идентификаторы переходных узлов можно получить через API шлюза /api/controller/v2/receptor_addresses/.

Переходный узел внутри кластера не создается при развертывании платформы автоматически. Если список receptor_addresses пуст, сначала создайте объект Mesh Ingress, применив манифест ресурса AutomationControllerMeshIngress командой kubectl apply. Для работы Mesh Ingress контроллер ingress-nginx кластера должен быть запущен с поддержкой SSL passthrough (см. Установка контроллера Ingress): без нее TLS-соединение завершается на ingress-контроллере и узлы не подключаются.

Пример описания инвентаря для подключения к нескольким внутренним переходным узлам:
--- all: vars: ac_host: "https://aa.demo.example.com" ac_token: "ggkosnvL6tXUUzBNP2xXaceXaFcu4J" ansible_ssh_common_args: "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" children: execution_nodes: hosts: exec-node-01: ansible_host: 10.205.213.3 ansible_user: admin ansible_ssh_private_key_file: keys/id_ed25519 hop_node_related: "4" peers_from_control_nodes: false exec-node-02: ansible_host: 10.205.213.7 ansible_user: admin ansible_ssh_private_key_file: keys/id_ed25519 hop_node_related: "5" peers_from_control_nodes: false
Если на предыдущем шаге значение параметра ansible_ssh_private_key_file не было задано, необходимо запустить агент SSH и добавить в него ключи доступа к узлам плоскости исполнения:
```
eval $(ssh-agent -s)
ssh-add <path_to_ansible_ssh_private_key_file>
```
Утилита ansible-navigator использует запущенный агент SSH для аутентификации при подключении к исполняющим и переходным узлам.
Выполните сценарии настройки и подключения узлов:
```
ansible-navigator run /usr/share/ansible/collections/ansible_collections/astra/receptor/playbooks/install_multiple_nodes.yml \
   -i inventory.yml \
   --eei hub.astra-automation.ru/aa-2.0/aa-full-ee:1.2.0-aa2.0 \
   -m stdout
```
Образ среды исполнения в команде приведен для иллюстрации. Подставьте актуальную версию образа aa-full-ee для своей версии платформы согласно правилу выбора образа. Состав образов описан в справочнике образов. Образ можно получить из облачного реестра Automation Hub (при доступе к интернету), из приватного реестра развернутой платформы либо из офлайн-пакета CDK.

Офлайн-пакет CDK содержит архивы образов в каталоге /opt/rbta/aa/CDK-setup/aa-ee-images/, а его установщик загружает эти архивы только в хранилище Podman пользователя root. Утилита ansible-navigator ищет образ в хранилище Podman пользователя, запускающего команду, поэтому загрузите образ в хранилище своего пользователя, выполнив команду podman load без sudo:
```
sudo cat /opt/rbta/aa/CDK-setup/aa-ee-images/aa-full-ee.tar | podman load
```
Команда выводит название загруженного образа в строке Loaded image. Укажите это название вместе с тегом в параметре --eei и добавьте к команде запуска сценария параметр --pp never, так как утилита по умолчанию загружает образ с тегом latest из реестра даже при наличии локальной копии.

По завершении выполнения сценария Ansible выводит типовую секцию PLAY RECAP.
В графической консоли платформы убедитесь, что появились новые узлы плоскости исполнения и их состояние Ready. Для этого на панели выберите следующие окна:
- Автоматизация процессов ‣ Инфраструктура ‣ Узлы (Automation Execution ‣ Infrastructure ‣ Instances) для просмотра списка узлов, например:
- Автоматизация процессов ‣ Инфраструктура ‣ Представление топологии (Automation Execution ‣ Infrastructure ‣ Topology View) для просмотра топологии, например:

Примечание

Если узел не переходит в состояние Ready и остается в состоянии installed, то причину можно определить только с помощью журнала службы Receptor на самом узле, так как в графической консоли платформы ошибки подключения не отображаются:

journalctl -u receptor

Удаление узла плоскости исполнения#

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

Отключите узел переключателем Включенный (Enabled) в разделе Автоматизация процессов ‣ Инфраструктура ‣ Узлы (Automation Execution ‣ Infrastructure ‣ Instances) графической консоли либо запросом PATCH {"enabled": false} к ресурсу узла. Отключение необходимо, так как контроллер продолжает назначать включенному узлу новые задания. Дождитесь завершения выполняющихся на узле заданий; поле jobs_running ресурса узла показывает их количество.
Остановите службу на узле и отключите ее автоматический запуск:
```
sudo systemctl disable --now receptor
```
Удалите пакеты Receptor:
```
sudo apt purge receptor receptorctl
```

Удалите локальный репозиторий пакетов, оставшийся после установки узла:

sudo rm -f /etc/apt/sources.list.d/receptor-offline.list /etc/apt/preferences.d/receptor-offline.pref
sudo rm -rf /tmp/receptor_packages

Сертификаты узла и ключ проверки подписи заданий сохраняются в каталоге /etc/receptor: при повторном подключении узел использует их снова, без повторного выпуска. Файл конфигурации службы удаляется вместе с пакетом – при повторном подключении он будет создан заново.

Важно

После удаления службы узел остается зарегистрированным в Automation Controller. Если узел больше не используется, выведите его из эксплуатации. Для этого в графической консоли платформы в разделе Автоматизация процессов ‣ Инфраструктура ‣ Узлы (Automation Execution ‣ Infrastructure ‣ Instances) удалите запись узла – платформа переведет узел в состояние deprovisioning и затем уберет запись самостоятельно. Через REST API то же действие выполняется запросом PATCH {"node_state": "deprovisioning"} к ресурсу /api/controller/v2/instances/<id>/; метод DELETE для записей узлов не поддерживается. Если плоскость управления в момент запроса недоступна, запрос завершается ошибкой – повторите его позже.

Обновление и восстановление узлов плоскости исполнения#

Узлы плоскости исполнения обслуживаются отдельно от остальных компонентов платформы. Обновление платформы и восстановление ее из резервной копии их не затрагивают.

Восстановление платформы из резервной копии. Резервная копия платформы не включает состояние узлов плоскости исполнения: настройки службы Receptor и сертификаты хранятся на самих узлах и в восстановлении не нуждаются. Регистрация узлов, удостоверяющий центр сети Mesh и ключи проверки подписи заданий входят в резервную копию платформы и восстанавливаются вместе с ней.

Поведение узлов после восстановления зависит от того, изменился ли адрес переходного узла внутри кластера (Mesh Ingress), с которым работали узлы:

Восстановление рядом с работающей исходной платформой, в том же кластере. Адреса сети Mesh в восстановленной базе данных остаются прежними, поэтому восстановленная платформа автоматически входит в ту же сеть Mesh, что и платформа, с которой снята резервная копия (далее – исходная платформа): внешние узлы отображаются в восстановленной платформе в состоянии Ready и обслуживают обе платформы одновременно. Задания, запущенные в восстановленной платформе, выполняются на тех же узлах, что и до создания резервной копии. Перед проверкой восстановленной платформы отключите в ней внешние исполняющие узлы (переключатель Включенный (Enabled) в списке узлов или запрос PATCH {"enabled": false} к ресурсу узла) либо выведите их из эксплуатации. Отключение затрагивает только базу данных восстановленной платформы и на работу узлов с исходной платформой не влияет.
Восстановление в другом кластере или взамен утраченной исходной платформы. Адрес Mesh Ingress меняется, поэтому узлы, устанавливающие соединение к платформе (peers_from_control_nodes: false), продолжают обращаться по прежнему адресу и отображаются в восстановленной платформе как недоступные. Узлы, соединение к которым устанавливает плоскость управления (peers_from_control_nodes: true), восстановленный контроллер подключает напрямую по их прежним адресам. Если адреса достижимы из нового кластера, такие узлы будут обслуживать и восстановленную, и исходную платформу – отключите их в восстановленной платформе, как описано выше.

Повторный запуск сценария подключения недоступный узел не вернет: узел уже зарегистрирован в восстановленной базе данных, а параметры топологии применяются только при первом подключении узла. Сценарий завершится успешно, но узел продолжит обращаться по прежнему адресу. Для возврата узла в сеть Mesh выполните следующие действия:
1. Создайте сервис Mesh Ingress в восстановленной платформе, если он еще не создан.
2. Выведите узел из эксплуатации в восстановленной платформе, как описано в инструкции по удалению.
3. Подключите узел заново тем способом, которым он был добавлен: сценарием подключения с идентификатором нового переходного узла в hop_node_related либо выгрузкой нового установочного пакета из графической консоли.

Результат проверяют не по коду возврата сценария, а по состоянию узла в графической консоли платформы (Автоматизация процессов ‣ Инфраструктура ‣ Узлы / Automation Execution ‣ Infrastructure ‣ Instances) – узел должен перейти в состояние Ready, а конфигурация Receptor на узле содержать адрес нового Mesh Ingress.