Действия перед обновлением

Содержание

Действия перед обновлением#

На этой стадии происходит сохранение данных платформы, которые не могут быть перенесены на новую версию Astra Automation автоматически. Позже эти данные потребуется восстановить на обновленной платформе.

Перед запуском процесса обновления Astra Automation до версии 2.0 необходимо выполнить ряд подготовительных шагов:

Подготовка PostgreSQL.
Подготовка Event-Driven Automation.
Экспорт ролевых привязок (RBAC).
Актуализация инвентаря.

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

Подготовка PostgreSQL#

Astra Automation версии 2.0 поддерживает только PostgreSQL 15. Если текущая версия платформы использует PostgreSQL версии ниже указанной, перед началом обновления ее необходимо обновить.

Для встроенной СУБД утилита aa-setup выполнит обновление автоматически.
Для внешней СУБД необходимо выполнить обновление вручную, согласно инструкции PostgreSQL.

Для проверки текущей версии СУБД выполните команду:

psql -U <pg_user> -h <pg_host> -p <pg_port> -d awx -c "SELECT version();"

Здесь:

<pg_user> – название учетной записи администратора СУБД.
<pg_host> – IP-адрес или FQDN СУБД;
<pg_port> – порт для подключения к СУБД.

Подготовка Event-Driven Automation#

База данных контроллера Event-Driven Automation версии платформы 1.2 не совместима с версией 2.0. Необходимо сохранить конфигурацию, удалить старую базу данных и создать новую.

Сохранение конфигурации#

Перед удалением базы данных необходимо сохранить текущие объекты Event-Driven Automation: своды правил, их активации и источники событий. Эти данные не будут перенесены автоматически и потребуют ручного восстановления после обновления.

Создайте каталог для хранения резервных данных:
```
mkdir -p /tmp/eda_backup/
```

Сохраните своды правил:

curl -sk -u admin:<password> https://eda.example.com/api/eda/v1/rulebooks/ > /tmp/eda_backup/rulebooks.json

Сохраните активации сводов правил:

curl -sk -u admin:<password> https://eda.example.com/api/eda/v1/activations/ > /tmp/eda_backup/activations.json

Сохраните источники событий:

curl -sk -u admin:<password> https://eda.example.com/api/eda/v1/event-streams/ > /tmp/eda_backup/event_sources.json

Остановка активаций и удаление БД#

Старая база данных должна быть удалена, для этого выполните следующие шаги:

Остановите все активации сводов правил:
- Через графический интерфейс:
  1. Перейдите в графический интерфейс Event-Driven Automation.
  2. Выберите на панели навигации Активации сводов правил (Rulebook Activations).
  3. В строке каждой активации переведите переключатель активности свода правил в положение Выключено.
- Через API:
  
  Остановите все активации сводов правил, используя следующий цикл:
```
curl -sk -u admin:<password> https://eda.example.com/api/eda/v1/activations/ | \
  jq -r '.results[].id' | while read id; do
    curl -sk -u admin:<password> -X POST \
      https://eda.example.com/api/eda/v1/activations/$id/disable/
  done
```
На узле с развёрнутой БД выполните следующие команды для удаления БД:
```
sudo su postgres
psql -p <automationedacontroller_pg_port>
DROP DATABASE <automationedacontroller_pg_database>;
\q
```
Здесь:
- <automationedacontroller_pg_port> – порт для подключения к СУБД;
- <automationedacontroller_pg_database> – название БД.
Только для топологии уровня предприятия с внешней СУБД создайте пустую БД для Event-Driven Automation после ее удаления:
```
CREATE DATABASE <automationedacontroller_pg_database> WITH OWNER <automationedacontroller_pg_username>;
```
Здесь:
- <automationedacontroller_pg_database> – название новой БД;
- <automationedacontroller_pg_username> – название учетной записи администратора СУБД.

Подготовка нового узла#

Для подготовки нового узла СУБД скопируйте файл /etc/astra_automation.version c существующего узла Event-Driven Automation на новый в каталог /etc/:

scp /etc/astra_automation.version <user>@<host>:/etc/

где:

<user> – название учетной записи пользователя целевого узла Event-Driven Automation;
<host> – FQDN или IP-адрес целевого узла Event-Driven Automation.

Экспорт ролевых привязок (RBAC)#

Перед миграцией необходимо экспортировать следующие настройки из текущей платформы:

назначения ролей, их определения и контекст;
составы команд.

Это требуется для восстановления данных вручную после миграции.

Экспорт ролей#

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

Создайте каталог для хранения резервных данных:
```
mkdir -p /tmp/rbac_backup/
```

Сохраните назначения ролей:

curl -sk -u admin:<password> https://controller/api/v2/role_user_assignments/ > /tmp/rbac_backup/role_user_assignments.json

curl -sk -u admin:<password> https://controller/api/v2/role_team_assignments/ > /tmp/rbac_backup/role_team_assignments.json

Сохраните определения ролей:

curl -sk -u admin:<password> https://controller/api/v2/role_definitions/ > /tmp/rbac_backup/role_definitions.json

Сохраните контекст:

curl -sk -u admin:<password> https://controller/api/v2/organizations/ > /tmp/rbac_backup/organizations.json

curl -sk -u admin:<password> https://controller/api/v2/teams/ > /tmp/rbac_backup/teams.json

curl -sk -u admin:<password> https://controller/api/v2/users/ > /tmp/rbac_backup/users.json

Экспорт состава команд пользователей#

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

Установите утилиту jq:
```
sudo apt install jq
```

Получите список всех команд:

curl -sk -u admin:<password> https://controller.example.com/api/v2/teams/ | \
  jq -r '.results[] | .id' > /tmp/team_ids.txt

Экспортируйте членов каждой команды:

while read team_id; do
  echo "Экспорт Team ID: $team_id"

  # Информация о команде
  curl -sk -u admin:<password> \
    "https://controller.example.com/api/v2/teams/$team_id/" \
    > "/tmp/rbac_backup/team_${team_id}_info.json"

  # Члены команды
  curl -sk -u admin:<password> \
    "https://controller.example.com/api/v2/teams/$team_id/users/" \
    > "/tmp/rbac_backup/team_${team_id}_users.json"

  # Роли команды
  curl -sk -u admin:<password> \
    "https://controller.example.com/api/v2/teams/$team_id/roles/" \
    > "/tmp/rbac_backup/team_${team_id}_roles.json"
done < /tmp/team_ids.txt

Проверка#

Проверьте экспортированные данные с помощью следующих команд:

echo "=== Статистика RBAC ==="
echo "Назначения пользователям: $(jq '.count' /tmp/rbac_backup/role_user_assignments.json)"
echo "Назначения командам: $(jq '.count' /tmp/rbac_backup/role_team_assignments.json)"
echo "Команд: $(jq '.count' /tmp/rbac_backup/teams.json)"

echo -e "\n=== Экспорт команд ==="
ls -1 /tmp/rbac_backup/team_*_users.json | wc -l
echo "команд экспортировано"

Актуализация инвентаря#

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