Обновление AFIGate¶

Обновление AFIGate выполняется офлайн: новый дистрибутив предоставляет поставщик, после чего jmsctl.sh upgrade разворачивает его поверх текущей установки и применяет миграции БД.

1. Перед обновлением¶

прочитайте примечания к устанавливаемому выпуску AFIGate;
используйте дистрибутив той же или более новой версии — переход на более старую версию не поддерживается без предварительного согласования;
выберите время для обновления: во время upgrade сервисы недоступны;
завершите или предупредите пользователей об активных SSH/RDP/DB-сессиях — подключения будут прерваны при обновлении;
не обновляйте отдельные контейнерные образы вручную в обход jmsctl.sh upgrade — это может нарушить совместимость компонентов.

2. Что сохранить перед обновлением¶

Данные AFIGate состоят из базы данных и каталога VOLUME_DIR (по умолчанию /opt/afigate). Перед обновлением сохраните оба.

Резервная копия базы данных¶

cd /opt/afigate-installer
sudo ./jmsctl.sh backup_db

Проверьте, что команда завершилась без ошибок и созданный SQL-файл имеет ненулевой размер (по умолчанию сохраняется в VOLUME_DIR/db_backup/). Скопируйте файл на отдельный сервер или в защищенное хранилище.

Резервная копия файлов и конфигурации¶

sudo tar -czf /opt/afigate-backup-$(date +%F).tar.gz -C /opt afigate

В VOLUME_DIR входят как минимум:

config/config.txt — конфигурация, включая SECRET_KEY и BOOTSTRAP_TOKEN; без исходного SECRET_KEY сохраненные секреты расшифровать невозможно;
core/data/media — записи сессий (если не вынесены во внешнее хранилище);
core/data/logs, koko/data/logs, nginx/data/logs — журналы;
koko/data/keys — ключи регистрации компонента koko;
postgresql/data, redis/data — данные встроенных БД (если используются вместо внешних PostgreSQL/Redis).

Полную структуру каталога и правила восстановления см. в «Резервное копирование и восстановление».

Опасно

Отдельно сохраните значения SECRET_KEY и BOOTSTRAP_TOKEN из config.txt — они не восстанавливаются автоматически и требуются при аварийном восстановлении на новом сервере.

В кластерной установке резервную копию БД и config.txt достаточно снять с одного узла, но копию общего хранилища записей (NFS/S3/MinIO/Ceph) проверяйте отдельно от узлов AFIGate.

3. Порядок обновления¶

Получите архив новой версии AFIGate у поставщика и перенесите его на сервер, например в /opt:

afigate-installer-v4.11.0-afi.1-x86_64.tar.gz

Распакуйте архив рядом с текущей установкой и запустите обновление:

cd /opt
tar -xf afigate-installer-v4.11.0-afi.1-x86_64.tar.gz
cd afigate-installer-v4.11.0-afi.1-x86_64
sudo ./jmsctl.sh upgrade

upgrade загружает новые образы, применяет миграции БД и обновляет конфигурацию текущей установки (/opt/afigate/config/config.txt сохраняется). В процессе мастер может задать уточняющие вопросы — отвечайте на них, ориентируясь на текущие параметры установки.

После завершения запустите сервисы и проверьте состояние:

sudo ./jmsctl.sh start
sudo ./jmsctl.sh status

В кластерной установке обновляйте узлы по одному: выведите узел из балансировщика, выполните upgrade и start, дождитесь готовности сервисов и только после этого переходите к следующему узлу. Поочередное обновление без простоя допустимо только если соседние версии узлов совместимы — сверьтесь с примечаниями к выпуску.

4. Проверка после обновления¶

sudo ./jmsctl.sh status — все сервисы запущены;
sudo ./jmsctl.sh tail core — нет повторяющихся ошибок в журнале;
вход в веб-интерфейс, брендинг и версия в разделе О системе;
состояние компонентов: Core, Koko, Lion, Chen, afigate_db, afigate_rdp, afigate_panda, afigate_reporting;
тестовые подключения: веб-терминал, нативный SSH, нативный RDP через afigate_rdp, подключение к БД через afigate_db, при необходимости — Git через KoKo (git ls-remote / git clone на порт 2222);
воспроизведение ранее записанной сессии;
лицензия — актуальный лимит и срок действия в Настройки системы → Лицензия.

5. Откат¶

Если после обновления обнаружены критичные проблемы:

Остановите сервисы: sudo ./jmsctl.sh stop.
Восстановите сохраненный VOLUME_DIR (в том числе config.txt) из резервной копии, снятой перед обновлением.
Восстановите БД из резервной копии: sudo ./jmsctl.sh restore_db /path/to/backup.sql.
Запустите прежнюю версию дистрибутива (jmsctl.sh start) и проверьте работоспособность.

Откат на более старую версию поддерживается только через восстановление из резервной копии, снятой до обновления — понижение версии «на месте» командой jmsctl.sh не предусмотрено.