Обновление

Asmy рассчитан на автоматическое обновление самой панели. Ваши приложения не обновляются вслед за Asmy: их образы и развёртывание вы управляете отдельно.

Ночное обновление

В production-режиме Asmy проверяет обновления раз в час. Запрос версии выполняется, когда время внутри процесса попадает в час с 03:00 до 03:59. Это не запуск строго в 03:00 и не обязательно ваш местный часовой пояс.

Если на asmy.pro назначена более новая версия, запускается установщик. Новейший Git-тег и версия, назначенная для автоматического распространения, могут различаться: сначала релиз проверяется, затем становится общедоступным.

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

При запуске и в этой же ночной проверке панель отправляет на сайт идентификатор установки, свою текущую версию и домен. Отчёт выполняется и без новой версии: он помогает владельцу Asmy видеть распространение релизов. Если сайт временно недоступен, проверка обновления всё равно выполняется, а следующая попытка отчёта будет следующей ночью или при перезапуске. Отдельного частого опроса нет; время последнего отчёта не означает, что сервер доступен прямо сейчас.

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

Панель запускает через Docker отдельный установщик выбранного релиза. Он получает текущие параметры, скачивает нужные образы и применяет Compose- или Swarm-конфигурацию. Остановка панели не останавливает контейнер установщика. При старте новой версии выполняются миграции БД и запуск Caddy.

На хосте не создаётся установочная директория. Вспомогательные файлы находятся в контейнере установщика; рабочая БД, резервные копии и сертификаты — в volumes. Переход со старых версий ещё может использовать raw.asmy.pro/setup.sh; новый updater больше не скачивает и не исполняет этот скрипт.

Ошибка обязательного этапа останавливает установщик. До остановки панели он скачивает образ приложения и проверяет конфигурацию. Успешное завершение установщика означает проверку нужного образа и готовности SQLite/HTTP новой панели. Это не гарантирует доступность каждого пользовательского домена и не является автоматическим откатом. Принятие команды на обновление ещё не означает завершения установщика.

Одновременно работает только один штатный установщик. Контейнер последней операции admire-server-manager-installer сохраняется вместе с ограниченным журналом, даже если новая панель успешно запустилась. Следующее обновление заменяет завершённый контейнер после загрузки нового образа. При ошибке pull предыдущая диагностика сохраняется.

Во время обновления панель может быть недоступна, а применение Caddy может прервать соединения с сайтами. Утверждать, что все приложения всегда продолжат работу без перерыва, нельзя. Планируйте обновления с учётом этого ограничения и резервного копирования.

Проверка версии

Администратор может посмотреть текущую версию в меню пользователя → «Настройки». После обновления перезагрузите вкладку и проверьте номер, доступность панели и сайтов.

После перехода на серверные сессии в версии 3.6 нужно войти заново. Аккаунты и пароли при этом сохраняются.

Ручной запуск для администратора

В интерфейсе нет отдельного полноценного мастера обновления. Для контролируемой проверки доступен метод в консоли браузера на открытой авторизованной панели:

window.updateApplication()

Он запрашивает версию, назначенную для массового обновления. Для проверки конкретного опубликованного релиза, ещё не назначенного всем, администратор может явно передать его версию:

window.updateApplication('4.1.0')

Номер приведён как пример, а не команда установить его вместо более новой версии. Сначала убедитесь, что нужный образ опубликован и переход подходит вашей установке. Не запускайте произвольный старый релиз: миграции БД могут не допускать откат заменой одного образа.

Окно об успешном запросе появляется после фиксированного ожидания; это не результат проверки готовности. Смотрите фактическую версию и Docker-логи.

Если версия не изменилась

Посмотрите результат и журнал последнего установщика:

docker inspect --format '{{.State.Status}} / exit={{.State.ExitCode}}' admire-server-manager-installer
docker logs --tail 200 admire-server-manager-installer

После устранения причины повторите ту же операцию:

docker start -ai admire-server-manager-installer

Контейнер сохраняет свой образ и параметры; повтор не выбирает произвольно другой релиз. Не удаляйте его до сохранения нужной диагностики. После перезагрузки сервера прерванный установщик также может потребовать такого повторного запуска. Автоматическое продолжение всех стадий после аварии питания не гарантируется.

1. Проверьте логи панели и установщика.
2. Убедитесь, что сервер видит asmy.pro и реестры образов; при переходе со старого updater нужен также raw.asmy.pro.
3. Проверьте свободное место и состояние Docker.
4. Сохраните сообщение ошибки, текущую и целевую версии.

Не удаляйте БД, volumes или сеть server для повторного обновления. Готовой кнопки отката нет; возврат после несовместимых миграций требует согласованного восстановления данных, а не только смены Docker-тега.

Очистка остатков прежней PostgreSQL

Актуальная Asmy использует SQLite. После завершения перехода известных установок новый установщик больше не переносит данные из PostgreSQL. Для установки 3.x, которая долго не обновлялась, сначала нужен отдельно согласованный переход; не запускайте над ней новую установку с пустой БД.

Выпуск 4.1.0 завершил переход: перед заменой панели он проверял SQLite, сохранял отдельную копию в admire-server-manager_backups, каталог before-postgres-cleanup-*, и удалял прежние PostgreSQL/backuper-контейнеры, services и два старых volume:

• admire-server-manager_postgres-data;
• admire-server-manager_postgres-backups.

После доставки 4.1.0 всем известным работающим установкам временная очистка удалена из установщика. Для перехода с 4.0.x сначала нужен 4.1.0; не перепрыгивайте этот этап, если старые ресурсы ещё остались. Рабочие SQLite volumes и данные приложений не удаляются. Созданные копии before-postgres-cleanup-* сохраняются и после удаления переходного кода.