Перейти к содержанию

Обновление платформы

Процедура обновления развёрнутого DataHUB на новую версию релиза. Подразумевает, что платформа уже стоит по Быстрому старту и переведена в production-режим по Production настройке.

Перед началом сделайте резервную копию

Любое обновление начинается с актуального бэкапа PostgreSQL и копии /etc/datahub/. См. Резервное копирование. Не пропускайте этот шаг даже для патч-релизов.

Что приходит в новой версии

Релиз поставляется в виде архива datahub-full-v<MAJOR>.<MINOR>.<PATCH>.zip той же структуры, что и при первичной установке:

  • images/*.tar.gz — обновлённые Docker-образы сервисов;
  • deployment/<block>/docker-compose.yml — могут содержать изменения (новые порты, новые переменные, новые сервисы);
  • deployment/<block>/.env.template — может содержать новые переменные;
  • manifest.lock.yml — фиксация версий и хешей образов;
  • modules/1c-cf.zip — обновлённая подсистема 1С (если есть изменения);
  • docs/ — обновлённая офлайн-копия документации.

Перед обновлением имеет смысл прочитать Релизы / Изменения платформы и особенно Breaking Changes для целевой версии.

Общий алгоритм

  1. Создать бэкап PostgreSQL и архив /etc/datahub/.
  2. Распаковать новый релиз и загрузить новые образы.
  3. Сравнить новые .env.template с действующими .env — добавить новые переменные.
  4. Сравнить новые docker-compose.yml с действующими — перенести значимые изменения.
  5. Остановить backend (он не должен работать на старой схеме при применении миграций).
  6. Запустить flyway — применить миграции схемы.
  7. Запустить новый backend, frontend, nginx.
  8. Проверить healthcheck'и, ключевые сценарии, логи.
  9. (При проблемах) Откатиться по плану ниже.

1. Бэкап

Резервная копия БД:

sudo docker exec -t postgres pg_dump -U "$POSTGRES_USER" -d DataHUB -F c -f /tmp/datahub-pre-upgrade-$(date +%F).dump
sudo docker cp postgres:/tmp/datahub-pre-upgrade-$(date +%F).dump /var/backups/datahub/

Архив конфигов и сертификатов:

sudo tar -czf /var/backups/datahub/etc-datahub-pre-upgrade-$(date +%F).tar.gz -C /etc datahub

Подробнее — в Резервном копировании.

2. Загрузка нового релиза

Распаковать новый архив поставки в домашний каталог:

unzip datahub-full-v<NEW_VERSION>.zip -d ~/

Перейти в распакованный каталог:

cd ~/datahub-full-v<NEW_VERSION>

Загрузить все новые образы:

sudo docker load -i images/backend-mono.tar.gz
sudo docker load -i images/flyway.tar.gz
sudo docker load -i images/frontend.tar.gz
sudo docker load -i images/nginx.tar.gz
sudo docker load -i images/pg-admin.tar.gz
sudo docker load -i images/postgres.tar.gz
sudo docker load -i images/rabbitmq.tar.gz
sudo docker load -i images/busybox.tar.gz

Проверить, что новые версии зарегистрированы:

sudo docker images | grep datahub

3. Синхронизация конфигов

Сравнить новые шаблоны с действующими .env. Для каждого блока:

diff /etc/datahub/<block>/.env.template ~/datahub-full-v<NEW_VERSION>/deployment/<block>/.env.template

Если в новом шаблоне появились переменные, которых нет в действующем .env — добавить их в .env со значениями по умолчанию или согласованными с описанием в Release Notes.

Аналогично — для docker-compose.yml:

diff /etc/datahub/<block>/docker-compose.yml ~/datahub-full-v<NEW_VERSION>/deployment/<block>/docker-compose.yml

Если изменились теги образов, добавились volumes, environment или ports — перенести в действующий docker-compose.yml. Имена контейнеров (container_name) и сервисы в dh_network менять не нужно.

Слияние, а не замена

Действующие .env и docker-compose.yml содержат реальные значения и подстройки под стенд — не копируйте новые шаблоны поверх. Применяйте именно дельту между шаблонами.

4. Применение миграций

Остановить backend — он не должен работать в момент миграции схемы:

cd /etc/datahub/backend
sudo docker compose down

Запустить flyway — он применит миграции и завершится:

cd /etc/datahub/flyway
sudo docker compose up

(Без -d, чтобы видеть лог в реальном времени.) Дождаться сообщения Successfully applied N migration(s). Если миграции упали — не запускайте новый backend, откатывайтесь по плану.

После успешного применения убрать контейнер flyway:

sudo docker compose down

5. Перезапуск компонентов

Запустить блоки в правильном порядке (вспомогательные блоки — devops-core, postgres, rabbitmq, pg-agmin — уже работают и в перезапуске не нуждаются, если их образы не менялись):

cd /etc/datahub/backend
sudo docker compose up -d --force-recreate

cd /etc/datahub/frontend
sudo docker compose up -d --force-recreate

cd /etc/datahub/nginx
sudo docker compose up -d --force-recreate

--force-recreate гарантирует пересоздание контейнера с новым образом, даже если image: в docker-compose.yml остался тем же тегом (для дев-стендов с фиксированными тегами вроде :dev).

6. Проверка

Проверить healthcheck-эндпоинты:

curl -fsS https://lk.<your-domain>/healthz

curl -fsS https://lk.<your-domain>/api/actuator/health

Статус контейнеров:

sudo docker ps --format "table {{.Names}}\t{{.Status}}"

Все основные сервисы — Up <время> (healthy). Логи на отсутствие фатальных ошибок:

sudo docker logs --tail 200 backend
sudo docker logs --tail 100 frontend
sudo docker logs --tail 50 nginx

Прогнать основные сценарии: вход в личный кабинет, отправка тестового сообщения через exchange API, просмотр очередей в RabbitMQ Management.

Если обновился постгрес major version

При смене major-версии PostgreSQL (например, 17 → 18) каталог PGDATA несовместим — нужен pg_upgrade или выгрузка/загрузка через pg_dumpall. Стандартный сценарий обновления это не покрывает — такие переходы выполняются отдельной процедурой по согласованию с вендором.

В рамках обновлений в пределах одной major-версии (17.6 → 17.7 и т.п.) обновление образа postgres — обычная замена тега в docker-compose.yml с пересозданием контейнера. Данные в ./data/ сохраняются.

Если обновился RabbitMQ major version

Аналогично: переход с RabbitMQ 3.x на 4.x требует отдельной процедуры. В пределах ветки 3.x — обычная замена образа.

Откат

Если обновление пошло не по плану и хочется вернуться на предыдущую версию:

  1. Остановить все блоки:
cd /etc/datahub/nginx && sudo docker compose down
cd /etc/datahub/frontend && sudo docker compose down
cd /etc/datahub/backend && sudo docker compose down
  1. Восстановить /etc/datahub/ из архива (если правили конфиги):
sudo rm -rf /etc/datahub.broken && sudo mv /etc/datahub /etc/datahub.broken
sudo tar -xzf /var/backups/datahub/etc-datahub-pre-upgrade-<DATE>.tar.gz -C /etc
  1. Восстановить БД из дампа:
sudo docker exec -i postgres pg_restore -U "$POSTGRES_USER" -d DataHUB --clean --if-exists < /var/backups/datahub/datahub-pre-upgrade-<DATE>.dump
  1. Поднять старые контейнеры (image: теги в docker-compose.yml уже указывают на предыдущие версии после восстановления):
cd /etc/datahub/backend && sudo docker compose up -d
cd /etc/datahub/frontend && sudo docker compose up -d
cd /etc/datahub/nginx && sudo docker compose up -d
  1. Проверить healthcheck'и и провести smoke-test.

Обновление подсистемы 1С

Подсистема 1С обновляется отдельно от серверной части — на каждой 1С-базе её устанавливает 1С-администратор клиентской системы. Совместимость подсистемы и серверной части документируется в Релизы / Изменения модулей интеграции.

Порядок: сначала серверная часть → затем подсистема 1С (если в релизе помечена как обязательная). Для патч-релизов обычно подсистема 1С не меняется.

Что дальше