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

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

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

../../../_images/infra-prep-green.svg ../../../_images/copy-green.svg ../../../_images/pre-upgrade-blue.svg ../../../_images/upgrade-white.svg ../../../_images/post-upgrade-white.svg ../../../_images/verification-white.svg

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

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

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

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

Для встроенной СУБД утилита aa-setup выполнит обновление автоматически.

Для внешней СУБД необходимо убедиться в следующем:

  • На уровне кластера настроены следующие параметры БД:

    • DateStyle = 'ISO, DMY' или DateStyle = 'ISO,MDY'.

    • timezone = 'UTC'.

  • Пользователь БД имеет привилегии на выполнение следующих операций:

    • CREATE TABLE.

    • CREATE INDEX.

    • CREATE SEQUENCE.

    • CREATE SCHEMA.

Далее необходимо выполнить обновление вручную, согласно инструкции 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: своды правил, их активации и источники событий. Эти данные не будут перенесены автоматически и потребуют ручного восстановления после обновления.

  1. Создайте каталог для хранения резервных данных:

    mkdir -p /tmp/eda_backup/

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

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

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

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

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

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

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

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

  1. Остановите все активации сводов правил:

    • Через графический интерфейс:

      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

  2. На узле с развёрнутой БД выполните следующие команды для удаления БД:

    sudo su postgres
psql -p <automationedacontroller_pg_port>
DROP DATABASE <automationedacontroller_pg_database>;
\q

    Здесь:

    • <automationedacontroller_pg_port> – порт для подключения к СУБД;

    • <automationedacontroller_pg_database> – название БД.

  3. Только для топологии уровня предприятия с внешней СУБД создайте пустую БД для 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)#

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

  • назначения ролей, их определения и контекст;

  • составы команд.

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

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

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

  1. Создайте каталог для хранения резервных данных:

    mkdir -p /tmp/rbac_backup/

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

    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

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

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

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

    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

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

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

  1. Установите утилиту jq:

    sudo apt install jq

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

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

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

    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 "команд экспортировано"

Подготовка SAML/LDAP#

Выполните следующие шаги, если для Private Automation Hub и Automation Controller в Astra Automation версии 1.2 используется аутентификация SAML/LDAP.

Проверка формирования названия учетной записи#

Проверьте правила формирования username в Private Automation Hub и Automation Controller:

  • Private Automation Hub:

    curl -sk -u admin:<password> https://hub.example.com/api/galaxy/pulp/api/v3/users/ | \
     jq '.results[] | {username: .username, email: .email}'

  • Automation Controller:

    curl -sk -u admin:<password> https://controller.example.com/api/v2/me/ | \
  jq '{username: .username, email: .email}'

Если правила формирования username в Private Automation Hub и Automation Controller равны email, дальнейшее выполнение инструкции Проверка формирования названия учетной записи не требуется. Перейдите к следующему шагу.

Если правила формирования username в Private Automation Hub и Automation Controller отличаются, после миграции для одного пользователя будет создано две учетные записи. Для предупреждения такой ситуации измените правило формирования названия учетной записи для SAML/OIDC в Private Automation Hub:

  1. Перейдите в графический интерфейс Private Automation Hub.

  2. Выберите на панели навигации Настройки (Settings).

  3. Измените Username Claim на email для одного из следующих методов аутентификации:

    • SOCIAL AUTH OIDC KEY.

    • SAML.

Важно

Формирование username по новому правилу происходит только после авторизации пользователя в обновленной системе.

Для проверки корректного формирования username выполните следующую команду:

curl -sk -u admin:<password> https://hub.example.com/api/galaxy/pulp/api/v3/users/ | \
     jq '.results[] | {username: .username, email: .email}'

В выводе команды значения username и email должны совпадать, например:

{
  "username": "user@example.com",
  "email": "user@example.com"
}

Важно

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

Экспорт принадлежности к пространству имен#

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

  1. Экспортируйте связь пользователей с пространством имен Private Automation Hub в отдельный файл формата JSON:

    curl -sk -u admin:<password> \
  https://hub.example.com/api/galaxy/_ui/v1/my-namespaces/ \
  > /tmp/rbac_backup/hub_namespaces_membership.json

  2. Экспортируйте список всех пространств имен:

    curl -sk -u admin:<password> \
  https://hub.example.com/api/galaxy/_ui/v1/namespaces/ \
  > /tmp/rbac_backup/hub_namespaces.json

Список доменных групп для исключения#

Создайте список групп SAML, которые не должны становиться командами в Astra Automation:

  1. Получите все группы текущих пользователей Private Automation Hub:

    curl -sk -u admin:<password> \
  https://hub.example.com/api/galaxy/pulp/api/v3/users/ | \
  jq -r '.results[].groups[]' | sort -u \
  > /tmp/rbac_backup/hub_all_groups.txt

  2. Просмотрите полученный список и определите какие группы представляют реальные команды проекта, а какие – структуру домена.

    Примечание

    Группы, представляющие структуру домена – это группы, автоматически получаемые из LDAP или SAML, которые отражают внутреннюю организацию компании (например, отделы, подразделения или общие доменные роли), а не реальные проектные команды, работающие с контентом Private Automation Hub.

  3. Сохраните список групп, являющихся структурой домена, в отдельный файл :file:` /tmp/rbac_backup/hub_domain_groups_to_exclude.txt`.

Удаление внешних групп#

Группы, созданные из внешних источников (SAML/OIDC groups claim), должны быть удалены из Private Automation Hub до миграции из-за следующих особенностей:

  • при миграции все группы из Private Automation Hub становятся командами (teams) в Gateway;

  • связь Private Automation Hub с внешним источником аутентификации теряется;

  • после миграции эти группы не обновляются из SAML/OIDC, но продолжают существовать.

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

  1. Получите список всех групп Private Automation Hub:

    curl -sk -u admin:<password> \
  https://hub.example.com/api/galaxy/_ui/v1/groups/ \
  > /tmp/rbac_backup/hub_groups_full.json

  2. Определите источник каждой группы:

    jq '.results[] | {name: .name, pulp_id: .pulp_id}' \
  /tmp/rbac_backup/hub_groups_full.json

    Группы из внешних источников обычно имеют следующие отличительные признаки:

    • их названия совпадают с названием доменных групп;

    • большое количество таких групп (сотни групп);

    • структуру подразделений компании.

  3. Удалите внешние группы из Private Automation Hub.

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

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

    Пример удаления группы:

    • Через API:

      curl -sk -u admin:<password> -X DELETE \
  https://hub.example.com/api/galaxy/_ui/v1/groups/<group_id>/

    • Через графический интерфейс:

      1. Перейдите в графический интерфейс Private Automation Hub.

      2. Выберите на панели навигации Коллекции ‣ Пространства имен ‣ Разрешения (Collections ‣ Namespaces ‣ Permissions).

      3. Для каждого пространства имен проверьте группы.

      4. Удалите группы из внешних источников:

        • все доменные группы (Domain Users, Authenticated Users, и так далее);

        • структурные подразделения компании;

        • группы с большим количеством пользователей без явной роли в Private Automation Hub.

        Оставьте только следующие локальные группы:

        • группы, созданные вручную для управления конкретными пространствами имен;

        • группы с явными правами на коллекции;

        • небольшие группы для проектных команд.

Проверка#

Убедитесь, что общее количество групп значительно сократилось по сравнению с исходным состоянием и соответствует только локальным группам Private Automation Hub.

curl -sk -u admin:<password> \
  https://hub.example.com/api/galaxy/_ui/v1/groups/ | \
  jq '.count'

Проверьте список оставшихся групп:

curl -sk -u admin:<password> \
  https://hub.example.com/api/galaxy/_ui/v1/groups/ | \
  jq '.results[].name'

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

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