Экспорт данных исходной платформы

Экспорт данных исходной платформы#

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

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

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

Состав миграционного архива#

Экспорт создает каталог ~/migration-export/ следующего состава:

migration-export/
   db/
      automationgateway.pgc
      awx.pgc
      automationhub.pgc
      automationedacontroller.pgc
   controller/
      custom_configs/
   migration-preseed-secrets.yml
   manifest.yml
   sha256sum.txt

Здесь:

  • db/*.pgc – дампы баз данных в формате custom утилиты pg_dump;

  • controller/custom_configs/ – пользовательские настройки Automation Controller из каталога /etc/tower/conf.d/;

  • migration-preseed-secrets.yml – постоянные секреты компонентов в виде переменных для утилиты развертывания;

  • manifest.yml – описание исходной и целевой платформ;

  • sha256sum.txt – контрольные суммы файлов каталога.

Архив ~/migration-export.tar.gz упаковывает этот каталог, а файл ~/migration-export.tar.gz.sha256 содержит контрольную сумму архива.

Остановка служб исходной платформы#

Чтобы компоненты не изменяли данные в базах во время создания дампов, остановите службы компонентов исходной платформы. Службу PostgreSQL не останавливайте, так как она необходима для создания дампов.

ssh <source_gateway_host> 'sudo systemctl stop automation-gateway-proxy automation-gateway.target'
ssh <source_controller_host> 'sudo systemctl stop automation-controller'
ssh <source_hub_host> "sudo systemctl stop 'pulpcore*'"
ssh <source_eda_host> "sudo systemctl stop 'automation-eda-controller*'"

Здесь:

  • <source_gateway_host> – доменное имя или IP-адрес узла Platform Gateway исходной платформы;

  • <source_controller_host> – доменное имя или IP-адрес управляющего узла Automation Controller исходной платформы;

  • <source_hub_host> – доменное имя или IP-адрес узла Private Automation Hub исходной платформы;

  • <source_eda_host> – доменное имя или IP-адрес узла контроллера Event-Driven Automation исходной платформы.

Если компонент развернут на нескольких узлах, выполните соответствующую команду на каждом из них.

Создание дампов баз данных#

Создайте каталог миграционного архива и сохраните в нем дампы баз данных:

umask 077
mkdir -p ~/migration-export/db ~/migration-export/controller/custom_configs

for db in automationgateway awx automationhub automationedacontroller; do
  ssh <source_db_host> "cd / && sudo -u postgres pg_dump -F c $db" > ~/migration-export/db/$db.pgc
done

ls -l ~/migration-export/db/

Здесь <source_db_host> – доменное имя или IP-адрес узла СУБД исходной платформы.

Команда cd / необходима, так как пользователь postgres не может перейти в домашний каталог пользователя SSH и без нее pg_dump выводит предупреждение could not change directory.

Размер каждого файла в выводе команды ls должен быть больше нуля.

Сохранение пользовательских настроек Automation Controller#

Сохраните файлы пользовательских настроек Automation Controller:

ssh <source_controller_host> \
  "sudo tar -C /etc/tower/conf.d -cf - --wildcards 'custom_*.py' 2>/dev/null" \
  | tar -C ~/migration-export/controller/custom_configs -xf -

ls ~/migration-export/controller/custom_configs/

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

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

Порядок переноса:

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

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

  3. Сверьте значение каждой настройки на целевой платформе с файлом из архива.

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

Сохранение постоянных секретов#

Компоненты шифруют часть данных в базах постоянными секретами. Если целевая платформа получит другие секреты, она не сможет расшифровать восстановленные данные. Например, контроллер Event-Driven Automation в этом случае возвращает ошибку InvalidToken.

Сохраните секреты исходной платформы в файл переменных для утилиты развертывания, не выводя их значения в терминал:

umask 077
cd ~/migration-export

read_file() {
  ssh "$1" "sudo cat $2"
}

read_hub_secret_key() {
  ssh "$1" 'sudo python3 -' <<'EOF'
import ast

with open("/etc/pulp/settings.py") as f:
    for line in f:
        if line.startswith("SECRET_KEY"):
            print(ast.literal_eval(line.split("=", 1)[1].strip()), end="")
            break
EOF
}

export CONTROLLER_SECRET_KEY="$(read_file <source_controller_host> /etc/tower/SECRET_KEY)"
export GATEWAY_SECRET_KEY="$(read_file <source_gateway_host> /etc/astra-automation/gateway/SECRET_KEY)"
export HUB_SECRET_KEY="$(read_hub_secret_key <source_hub_host>)"
export HUB_DATABASE_FIELDS="$(read_file <source_hub_host> /etc/pulp/certs/database_fields.symmetric.key)"
export EDA_SECRET_KEY="$(read_file <source_eda_host> /etc/astra-automation/eda/SECRET_KEY)"

python3 - <<'EOF'
import json
import os

secrets = {
    "controller_secret_key": os.environ["CONTROLLER_SECRET_KEY"],
    "gateway_secret_key": os.environ["GATEWAY_SECRET_KEY"],
    "hub_secret_key": os.environ["HUB_SECRET_KEY"],
    "__hub_database_fields": os.environ["HUB_DATABASE_FIELDS"],
    "eda_secret_key": os.environ["EDA_SECRET_KEY"],
}
empty = [name for name, value in secrets.items() if not value]
if empty:
    raise SystemExit("Empty secrets: " + ", ".join(empty))
with open("migration-preseed-secrets.yml", "w") as f:
    json.dump(secrets, f, indent=2)
EOF

unset CONTROLLER_SECRET_KEY GATEWAY_SECRET_KEY HUB_SECRET_KEY HUB_DATABASE_FIELDS EDA_SECRET_KEY

Сценарий записывает файл migration-preseed-secrets.yml в формате JSON, который утилита развертывания читает как YAML. Если сценарий не прочитал хотя бы один секрет, он завершается сообщением Empty secrets с перечнем пустых значений. В этом случае проверьте путь к файлу секрета на соответствующем узле и повторите команды.

Создание описания миграции#

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

cat > ~/migration-export/manifest.yml <<'EOF'
---
migration:
  source_install_type: vm
  target_install_type: containerized
  platform_version: <platform_version>
  date: <YYYY-MM-DD>
source_nodes:
  gateway: <source_gateway_host>
  controller: <source_controller_host>
  hub: <source_hub_host>
  eda: <source_eda_host>
  db: <source_db_host>
target_node: <target_host>
EOF

Здесь:

  • <platform_version> – версия Astra Automation исходной и целевой платформ;

  • <YYYY-MM-DD> – дата миграции;

  • <target_host> – доменное имя или IP-адрес узла целевой платформы, на котором в базовой топологии находятся все ее компоненты.

Упаковка архива#

Рассчитайте контрольные суммы и упакуйте каталог в архив:

cd ~/migration-export
find . -type f ! -name sha256sum.txt -print0 | sort -z | xargs -0 sha256sum > sha256sum.txt

cd ~
tar czf migration-export.tar.gz migration-export
sha256sum migration-export.tar.gz > migration-export.tar.gz.sha256
chmod 600 migration-export.tar.gz migration-export.tar.gz.sha256

sha256sum -c migration-export.tar.gz.sha256

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

migration-export.tar.gz: OK

При русской локали команда выводит ЦЕЛ вместо OK.

Запуск служб исходной платформы#

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

ssh <source_gateway_host> 'sudo systemctl start automation-gateway.target automation-gateway-proxy'
ssh <source_controller_host> 'sudo systemctl start supervisor automation-controller'
ssh <source_hub_host> 'sudo systemctl start pulpcore-api pulpcore-content $(systemctl list-units --all --no-legend --plain "pulpcore-worker@*" | awk "{print \$1}")'
ssh <source_eda_host> 'sudo systemctl start automation-eda-controller.target nginx'

Systemd останавливает службы supervisor на узле Automation Controller и nginx на узле контроллера Event-Driven Automation вместе со службами компонентов, но при их запуске не запускает, поэтому команды указывают их явно. Команда запускает рабочие процессы Private Automation Hub по названиям, которые выводит systemctl list-units, так как шаблон pulpcore-worker@* не действует на остановленные службы.

Важно

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