Подготовка и первое развертывание целевой платформы

Подготовка и первое развертывание целевой платформы#

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

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

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

Описание инвентаря#

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

Для миграции описание инвентаря должно удовлетворять следующим требованиям:

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

  • Названия баз данных и их владельцев совпадают с исходной платформой. Описание инвентаря либо не задает переменные automation*_pg_database и automation*_pg_username, либо задает им те же значения, что и описание инвентаря исходной платформы.

  • Контроллер Event-Driven Automation входит в группу automationedacontroller.

  • Глобальные переменные admin_username и admin_password задают учетную запись администратора.

  • Переменная ansible_ssh_private_key_file содержит абсолютный путь к закрытому ключу SSH, так как утилиту развертывания запускают через sudo.

Пример описания инвентаря исходной платформы в базовой топологии модели развертывания из deb-пакетов:

[automationgateway]
gw.example.com

[automationcontroller]
ctrl.example.com

[automationcontroller:vars]
node_type=control
peers='execution_nodes'

[execution_nodes]
exec.example.com

[automationhub]
hub.example.com

[automationedacontroller]
eda.example.com

[database]
db.example.com

[all:vars]
ansible_ssh_private_key_file='/path/to/private/ssh/key'
ansible_user='admin'
ansible_python_interpreter=/usr/bin/python3

redis_mode=standalone

admin_email='admin@example.com'
admin_username='admin'
admin_password='AAp@ssW0rd'

# Platform Gateway
automationgateway_main_url='https://gw.example.com'
automationgateway_pg_host='db.example.com'
automationgateway_pg_database='automationgateway'
automationgateway_pg_username='automationgateway'
automationgateway_pg_password='gateDBpaS$12345'

# Automation Controller
pg_host='db.example.com'
pg_database='awx'
pg_username='awx'
pg_password='ctrlDBpaS$123456'

# Private Automation Hub
automationhub_pg_host='db.example.com'
automationhub_pg_database='automationhub'
automationhub_pg_username='automationhub'
automationhub_pg_password='hUbPa55I2345b'

# Контроллер Event-Driven Automation
automationedacontroller_pg_host='db.example.com'
automationedacontroller_pg_database='automationedacontroller'
automationedacontroller_pg_username='automationedacontroller'
automationedacontroller_pg_password='edapassword'

Пример описания инвентаря целевой платформы:

# Все компоненты целевой платформы на одном узле
[automationgateway]
aa.example.com

[automationcontroller]
aa.example.com

[automationhub]
aa.example.com

[automationedacontroller]
aa.example.com

# СУБД, развертываемая средствами платформы, на том же узле
[database]
aa.example.com

[all:vars]
ansible_ssh_private_key_file='/home/admin/.ssh/id_ed25519'
ansible_user='admin'
ansible_python_interpreter=/usr/bin/python3

admin_email='admin@example.com'
admin_username='admin'
admin_password='AAp@ssW0rd'

redis_mode=standalone

# Установка из офлайн-пакета
# bundle_install='true'

Целевая платформа использует названия баз данных и их владельцев по умолчанию, поэтому ее описание инвентаря не задает переменные automation*_pg_database и automation*_pg_username. При установке из офлайн-пакета раскомментируйте переменную bundle_install, как описано в инструкции для окружения без доступа к интернету.

Примечание

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

Передача миграционного архива#

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

Скопируйте миграционный архив и его контрольную сумму на узел целевой платформы, проверьте целостность и распакуйте архив:

scp ~/migration-export.tar.gz ~/migration-export.tar.gz.sha256 <target_host>:

ssh <target_host>
sha256sum -c migration-export.tar.gz.sha256
umask 077
tar xzf migration-export.tar.gz
cd migration-export && sha256sum -c --quiet sha256sum.txt && cd ~

Здесь <target_host> – доменное имя или IP-адрес узла целевой платформы.

Команду scp выполните на установочном узле исходной платформы, остальные команды – на узле целевой платформы. Команда sha256sum -c --quiet не выводит ничего, если все контрольные суммы совпали.

Первое развертывание#

В каталоге /opt/rbta/aa/astra-automation-setup/ запустите развертывание и передайте утилите файл с постоянными секретами исходной платформы:

sudo ./aa-setup --containerized \
  --inventory=</path/to/inventory> \
  -- --extra-vars @$HOME/migration-export/migration-preseed-secrets.yml

Здесь </path/to/inventory> – путь к описанию инвентаря целевой платформы.

Развертывание считается успешным, если для всех узлов в поле failed указано значение 0.

Утилита развертывания сохраняет секреты в хранилище секретов Podman при первом развертывании и при повторных запусках их не изменяет. Поэтому файл с секретами необходимо передать именно при первом развертывании. Если при первом развертывании утилита не получила этот файл, удалите целевую платформу с помощью аргумента --uninstall и разверните ее заново.

Важно

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

Проверка секретов#

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

cd ~/migration-export

check_secret() {
  expected=$(python3 -c 'import json, sys; print(json.load(open("migration-preseed-secrets.yml"))[sys.argv[1]], end="")' "$2" | sha256sum | cut -d ' ' -f 1)
  actual=$(podman secret inspect --showsecret --format '{{.SecretData}}' "$1" | tr -d '\n' | sha256sum | cut -d ' ' -f 1)
  if [ "$expected" = "$actual" ]; then echo "$1: OK"; else echo "$1: MISMATCH"; fi
}

check_secret controller_secret_key controller_secret_key
check_secret gateway_secret_key gateway_secret_key
check_secret hub_secret_key hub_secret_key
check_secret hub_database_fields __hub_database_fields
check_secret eda_secret_key eda_secret_key

Ожидаемый результат:

controller_secret_key: OK
gateway_secret_key: OK
hub_secret_key: OK
hub_database_fields: OK
eda_secret_key: OK

Если проверка выводит MISMATCH для какого-либо секрета, не продолжайте миграцию. Удалите целевую платформу и повторите первое развертывание с файлом секретов.