Обновление и откат

Обновление заменяет бинарный файл, но не переводит вас на другой продукт. Каталог данных, ключ подписи аудита и материалы TLS остаются на месте, а движок сам применяет новые миграции схемы при запуске. Эта страница проводит оператора от вопроса «стоит ли устанавливать этот релиз?» до «мне нужно вернуть предыдущий».

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

Перед каждым обновлением создавайте DR-копию командой dr backup установленного релиза. Экран Backups (/backups) и Резервное копирование и восстановление описывают процедуру. После повышения версии схемы для возврата к предыдущему релизу нужны копия, сделанная до обновления, и её секретная парольная фраза или KEK. olivares upgrade сохраняет исполняемый файл, но не создаёт резервную копию базы данных.

Какой путь обновления подходит вам

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

Установка	Путь
Пакет deb, rpm, apk или AUR	Менеджер пакетов. Установка из пакета
Бинарный файл на хосте, systemd (не из пакета)	olivares upgrade — эта страница
Контейнер Docker или Podman	docker compose exec olivares olivares upgrade, затем пересоздайте контейнер. Образ изменить нельзя, поэтому релиз сохраняется в томе данных (ota/ в каталоге данных), и каждый запуск бинарного файла образа запускает его, пока он новее образа или той же версии, собранной иначе. Если удалить ota/, контейнер вернётся к бинарному файлу своего образа. Команды приведены в разделе Docker и Compose.
Kubernetes / Helm	Задайте образ и позвольте оператору выполнить поэтапное обновление. Не запускайте olivares upgrade внутри pod: развёртывание декларативно, и следующая сверка отменит эту замену.

Прежде всего: прочитайте план

--check загружает и проверяет манифест канала, сравнивает его с установленной версией и показывает, что произойдёт. Ничего не заменяется.

olivares upgrade --check

Команда сообщает установленную и доступную версии и строку состояния: up to date, upgrade available, DOWNGRADE (blocked unless --force-rollback) или UNKNOWN. Читайте строку состояния, а не сравнивайте два номера версии самостоятельно.

UNKNOWN не означает «скорее всего, всё в порядке». Это означает, что установленную версию измерить не удалось: например, из-за staging-каталога другой архитектуры, монтирования noexec или сборки из исходников. Защита от отката и ограничение минимальной версии формулируют утверждения именно об установленной версии, поэтому проверить их нельзя. Команда отказывается угадывать. Объявите версию, которая, как вам известно, установлена, и обе защиты останутся включёнными:

olivares upgrade --check --current-version 0.4

Каналы релизов

olivares upgrade следует каналу релизов. Их 3, и они объявлены в core/release/manifest.go в порядке возрастания стабильности:

Значение --channel	Объявлено как
stable	release.ChannelStable
security	release.ChannelSecurity
lts	release.ChannelLTS

Значение вне этой таблицы отклоняется до загрузки каких-либо данных (release.ValidChannel).

stable — общедоступная линия и значение по умолчанию. security содержит только внеочередные исправления: развёртывание на этом канале получает релизы безопасности, не принимая функциональные релизы.

lts проходит проверку, но его никто не публикует

Таблица выше сгенерирована из объявленных в коде констант каналов, поэтому включает каждое значение, принимаемое --channel, в том числе lts. Манифест lts не создаётся и не публикуется, поэтому развёртывание на этом канале запрашивает у хоста обновлений несуществующий объект. Поддержка безопасности действует только в течение оплаченного срока, без общих переносов исправлений; замороженной линии, заслуженного запасного права или бессрочного права нет. Выберите stable или security.

Выберите подходящий вашему процессу канал и придерживайтесь его:

olivares upgrade --channel security

Релиз безопасности помечается в манифесте, а --check показывает исправляемые рекомендации по безопасности. На канале security вы получаете их вне очереди общедоступной линии.

Выполнение обновления

olivares upgrade

При установке из пакета (deb, rpm, apk, AUR) команда отклоняется с кодом выхода 2 до какой-либо загрузки: используйте менеджер пакетов, как указано в таблице выше. --check по-прежнему показывает план.

Команда выполняет следующие действия по порядку:

1. Загружает манифест канала и проверяет его подпись автономно по встроенному в сборку релизному ключу Ed25519. Якорь доверия — подпись, а не транспорт. Для сборки без встроенного ключа его нужно передать через --pubkey; непроверяемого пути нет.
2. Отказывается идти назад. Установка версии старше работающей блокируется, если не передан --force-rollback; это действие записывается в журнал аудита.
3. Связывает артефакт с подписанным SHA-256 из манифеста, прежде чем байты будут исполнены.
4. Проверяет кандидата, затем выполняет атомарную замену и сохраняет заменённый бинарный файл как резервную копию с временной меткой. Если новый файл не запускается, команда сама возвращает эту копию.
5. Не затрагивает работающий процесс. Заменяется файл на диске. Новый код вступит в силу после перезапуска службы.

Добавьте --yes, если командой управляет скрипт и отвечать на запрос подтверждения некому.

Автоматический откат на шаге 4 проверяет version, а не запуск службы или совместимость базы данных. Он не восстанавливает хранилище, мигрированное при следующем запуске.

Горячих исправлений нет

Бинарный файл Go не исправляется на месте. «Нулевой простой» здесь означает корректное завершение и передачу работы либо поэтапный перезапуск, но никогда не исправление внутри процесса. Без перезапуска применяются данные и конфигурация: источники, коннекторы, секреты, политика и лицензия.

Установки в изолированной среде

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

Для установки без сети требуется Enterprise. Community проверяет комплект с --bundle --check, не читая лицензию и не устанавливая его.

olivares upgrade --bundle ./olivares-release.tar.gz --check

Поэтапное развёртывание и автоматические проверки

Манифест может назвать когорту поэтапного развёртывания, чтобы релиз сначала получил лишь процент инфраструктуры. С --if-eligible узел действует только тогда, когда входит в эту когорту, иначе не делает ничего:

olivares upgrade --if-eligible --yes

Именно эту форму запускает встроенный таймер. Чтобы вывести таймер и службу systemd, которые вызывают её в окно обслуживания:

olivares upgrade --install-timer --timer-schedule 'Sun *-*-* 03:00:00'

По умолчанию команда печатает unit-файлы; --timer-dir записывает их в указанный каталог. Это явно включаемая функция: ничего не планирует себя само.

При установке из пакета команда отказывает: /usr/bin/olivares принадлежит менеджеру пакетов, поэтому она завершается с кодом 2, не записывает unit и называет путь обновления: менеджер пакетов хоста, а на appliance Olivares — systemctl start olivares-appliance-update.service. С --enterprise --connect она называет также olivares license connect refresh. Проверка идёт по пути, поэтому бинарный файл, который install.sh --bindir /usr/bin положил туда, тоже отклоняется.

Консоль предоставляет доступ только для чтения к той же информации: Settings → update status вызывает POST /v1/console/update-check, который по запросу проверяет настроенный канал. Изолированное развёртывание или развёртывание без настроенного канала отвечает 501 и прямо сообщает причину, а не утверждает, что обновлений нет.

Проверка обновления

olivares version
olivares upgrade --check

Теперь --check должен сообщить up to date. Затем проверьте здоровье службы на экране консоли Health (/health) или через endpoint готовности движка по руководству Мониторинг с Prometheus.

Откат

Предыдущий исполняемый файл сохраняется рядом с новым; команда печатает его путь. Эта копия не является точкой восстановления данных.

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

1. Остановите все движки, использующие хранилище. Сохраните обновлённые данные, конфигурацию службы, материалы TLS и внешние ключи запечатывания.
2. Бинарным файлом предыдущего релиза восстановите DR-комплект, созданный до обновления: Резервное копирование и восстановление. SQLite: новый каталог данных либо dr restore --in-place с --operator и --reason; храните сохранённые файлы до подтверждения восстановления. PostgreSQL: пустая цель через olivares db init, её --dsn, --owner-dsn, --admin-dsn и новый каталог для восстановленного ключа подписи.
3. Требуйте успешной проверки реестра и ключа аудита. Направьте каталог данных, тома и DSN PostgreSQL службы на восстановленное хранилище и соответствующие ключи подписи, прежде чем запускать предыдущий релиз.
4. Войдите и проверьте восстановленные данные и состояние службы.

Восстановление возвращает сохранённое состояние. Последующие записи в восстановленном хранилище отсутствуют; сохраните обновлённое хранилище для сверки. Без комплекта и его парольной фразы или KEK замена исполняемого файла не обеспечивает такое восстановление.

--force-rollback разрешает установить старый исполняемый файл и записывает переопределение в журнал аудита. Он не обходит проверку core-схемы или минимальной версии и не восстанавливает данные. Если установленная версия ниже порога, используйте промежуточный релиз.

Проверка восстановления перед обновлением рабочей среды

Запустите проверенный предыдущий релиз с временным каталогом SQLite, завершите настройку, войдите и остановите его. Создайте и проверьте комплект его командами dr backup и dr verify. Запустите кандидат на том же хранилище, войдите и остановите его. Если схема превысила предел предыдущего релиза, тот должен завершиться с core schema version newer than this binary supports. Восстановите комплект в новый каталог прежней командой dr restore. Требуйте код выхода ноль и успешную проверку реестра; запустите там прежний релиз и проверьте вход, исходный публичный ключ аудита и сохранённые данные. Ошибка восстановления или входа означает провал проверки.

Измеренная проверка SQLite (2026-10-08): официальный релиз 26.10.1 создал core-схему 18, новый кандидат повысил её до 27. Старый файл отказал с кодом 1 (database=27 binary=18). Его dr backup, dr verify и dr restore завершились с кодом 0. После восстановления комплекта до обновления в новый каталог удалось войти исходной учётной записью и подтвердить исходный публичный ключ аудита.

Если что-то пошло не так

Симптом	Что он означает	Что делать
--check печатает UNKNOWN	Установленную версию измерить не удалось, поэтому сравнить порядок невозможно	Передайте --current-version с заведомо установленной версией
min_ver сообщает, что версия слишком старая	Релиз отказывается устанавливаться непосредственно поверх неё	Сначала обновитесь до указанного промежуточного релиза
Установленный файл не проходит проверку version после замены	Проверка исполняемого файла не прошла	Команда возвращает сохранённый файл; проверьте журналы
Служба не запускается после перезапуска или старый файл сообщает о более новой core-схеме	Это вне проверки исполняемого файла	Остановите службу и восстановите DR-комплект до обновления по разделу Откат
--install-timer срабатывает, но ничего не происходит	Узел не входит в когорту поэтапного развёртывания	Это ожидаемо при --if-eligible; когорта расширяется по мере развёртывания
«another olivares upgrade is already installing», код выхода 5	Одновременно допускается одно обновление бинарного файла. Блокировка удерживается на протяжении загрузки и замены	Дождитесь работающего процесса и повторите команду. Если ничего не запущено, ядро уже освободило блокировку, поэтому повторите сейчас
«it CHANGED while this upgrade was downloading»	После составления плана бинарный файл заменил другой механизм: менеджер пакетов, развёртывание образа или система управления конфигурацией	Запустите заново: защиты повторно оцениваются относительно фактически установленного файла. Если это повторяется, одним бинарным файлом управляют два механизма

Один агент обновления на бинарный файл. olivares upgrade устанавливает эксклюзивную блокировку цели на всю последовательность подготовки, загрузки и замены, поэтому второй запуск завершается с кодом 5. Установите один таймер и меняйте в нём --channel, а не запускайте таймер на каждый канал: раньше две установки, завершившиеся в одну секунду, перезаписывали резервные копии друг друга, и автоматический откат проигравшей установки восстанавливал другой бинарный файл и сообщал об успехе. Непосредственно перед заменой команда заново читает байты цели и отказывается продолжать, если это не тот файл, для которого составлялся план: выводы защиты от отката и минимальной версии относятся к конкретному установленному файлу.

Для остальных случаев используйте общее руководство Устранение неполадок; экран консоли Logs (/logs) транслирует собственный журнал движка.