Обновление версий

GetOLT обновляется одной командой. Миграции схемы БД идут автоматически при старте — никаких flyway, liquibase, ручных SQL.

Узнать что вышла новая версия

Раз в сутки приложение делает phone-home к серверу лицензий и проверяет последний опубликованный релиз. Если он новее установленного — в шапке слева от плашки лицензии появляется teal-плашка с номером версии и стрелкой ↑. Клик ведёт на страницу /update, где видно:

• какая версия сейчас установлена;
• какая доступна и когда выпущена;
• ссылка на release notes (если есть);
• инструкция-команда, специфичная для канала установки (Docker compose или bare-metal).

Если плашки нет — вы на актуальной версии. Сама проверка ничего не блокирует и работает на любом тарифе. Кнопка «Обновить сейчас» на странице /update пока неактивна — авто-обновление через UI появится отдельным релизом; сейчас обновление запускается командой ниже.

Стандартное обновление (рекомендуется)

curl -A "getolt-installer/1.0" -fsSL https://get.getolt.online/update.sh | sudo bash

Скрипт делает то же, что и ручные команды ниже, плюс:

• автоматический online-бэкап БД в /opt/getolt/backups/getolt-YYYY-MM-DD-HHMM.sql.gz (mysqldump --single-transaction, без даунтайма);
• тегирование текущего образа как :rollback-prev — откат одной командой;
• health-check https://127.0.0.1/login после рестарта (до 3 минут);
• автоматический rollback на :rollback-prev если новая версия не отвечает 200;
• ротация бэкапов (последние 7, KEEP_BACKUPS=N для override).

Если digest не изменился — скрипт молча выходит, recreate’а не делает.

Ручное обновление

cd /opt/getolt
docker compose pull
docker compose up -d

Что происходит:

1. docker compose pull тянет свежий образ registry.getolt.online/getolt/getolt-grade:latest.
2. docker compose up -d пересоздаёт контейнер приложения, MySQL остаётся как есть (если его тэг не менялся).
3. На старте Spring Boot прогоняет идемпотентные DDL: создаёт недостающие таблицы, добавляет новые колонки, не трогает данные. Если миграция упадёт — приложение не стартует и пишет понятную ошибку в docker compose logs app.

Типичное время простоя — 30–60 секунд (рестарт + warmup).

Если в новой версии появились новые переменные .env

update.sh и ручное docker compose pull обновляют только Docker-образ приложения — сам файл /opt/getolt/docker-compose.yml остаётся прежним. Если в новой версии добавились новые переменные окружения (например, расширили блок LDAP в app.environment:), их не будет в вашем compose-файле, и приложение возьмёт дефолты вместо значений из .env.

Признак: вы прописали переменную в .env, но docker compose exec app env | grep <ИМЯ> её не показывает.

Лечение:

cd /opt/getolt
sudo curl -fsSL -A "getolt-installer/1.0" \
  https://get.getolt.online/docker-compose.client.yml -o docker-compose.yml
sudo docker compose up -d --force-recreate app

Данные MySQL и лицензия на volumes — не затрагиваются.

Перед обновлением

• Если используете update.sh — бэкап БД делается автоматически (в /opt/getolt/backups/, ротация 7 снимков). Дополнительный снимок нужен только если хотите внешнюю копию: docker compose exec mysql mysqldump --single-transaction -uroot -p"$MYSQL_ROOT_PASSWORD" getolt_db > /backup/getolt-$(date +%F).sql. Подробнее — Резервное копирование.
• Сохранить копию /opt/getolt/.env вместе с дампом БД. Пароли и SSH-ключи доступа к вашим OLT хранятся в базе в зашифрованном виде, а ключ шифрования GETOLT_SECRET_KEY лежит только в .env. Дамп БД без этого файла восстановить невозможно: расшифровать учётные данные будет нечем, и приложение не запустится.
• Прочитать /changelog — там по версиям отмечены breaking changes (если есть).

Если вы обновляетесь с версии, где GETOLT_SECRET_KEY ещё не было

update.sh и upgrade.sh создают ключ автоматически и дописывают его в .env, если его там нет. При первом запуске новой версии учётные данные OLT в базе будут зашифрованы этим ключом.

С этого момента .env становится таким же критичным, как сам дамп БД — включите его в регламент резервного копирования. Ключ не хранится больше нигде и не подлежит восстановлению.

Откат на предыдущую версию

Если обновление делалось через update.sh, прошлый образ всегда помечен тегом :rollback-prev локально на машине — откат одной командой:

cd /opt/getolt
GETOLT_IMAGE=registry.getolt.online/getolt/getolt-grade:rollback-prev docker compose up -d app

Откат на произвольную версию из реестра — по короткому SHA коммита:

# узнать текущий запущенный digest
docker compose images app
# в /opt/getolt/docker-compose.yml поменять
#   image: registry.getolt.online/getolt/getolt-grade:latest
# на
#   image: registry.getolt.online/getolt/getolt-grade:<нужный-короткий-sha>
docker compose up -d

Если откатываемая версия делала изменения схемы БД, которые несовместимы с прежней — потребуется восстановить БД из снапшота:

gunzip -c /opt/getolt/backups/getolt-YYYY-MM-DD-HHMM.sql.gz \
  | docker compose exec -T mysql mysql -uroot -p"$MYSQL_ROOT_PASSWORD" getolt_db

Поэтому снимок перед обновлением — это не паранойя, а часть процедуры (скрипт update.sh делает его автоматически).

Что дальше

• Резервное копирование — снапшот и восстановление.
• Production-deploy — заодно описание /opt/getolt/.
• По вопросам обновления — support@getolt.online или в Telegram @getolt_pub.