mirror of
https://github.com/Vateron-Media/XC_VM.git
synced 2026-10-04 12:02:33 +02:00
198 lines
11 KiB
Markdown
198 lines
11 KiB
Markdown
# Механизм обновления в XC_VM
|
||
|
||
Система обновления XC_VM реализована как многоуровневый процесс, от веб-интерфейса до сценариев системного уровня. Такой подход обеспечивает надежность, автоматизацию и целостность данных при обновлении панели.
|
||
|
||
> 📋 Пошаговое руководство со скриншотами см. в разделе [Обновление сервера](../administration/server-update.md).
|
||
|
||
---
|
||
|
||
## 1. Инициирование обновления
|
||
|
||
Процесс начинается, когда администратор нажимает кнопку **"Обновить"** в веб-интерфейсе.
|
||
|
||
- Сигнал с именем `update` вставляется в таблицу `signals` в базе данных.
|
||
- Этот сигнал действует как **спусковой крючок** для всей процедуры обновления.
|
||
|
||
---
|
||
|
||
## 2. Триггер CRON
|
||
|
||
Каждые **минута** выполняется следующее задание CRON:
|
||
|
||
```bash
|
||
/home/xc_vm/console.php cron:root_signals
|
||
```
|
||
|
||
Задание cron `root_signals` проверяет наличие новых сигналов.
|
||
Когда он обнаруживает сигнал `update`, он запускает:
|
||
|
||
```bash
|
||
/home/xc_vm/console.php update update
|
||
```
|
||
|
||
---
|
||
|
||
## 3. Управление обновлениями (уровеньPHP)
|
||
|
||
Основная логика находится в классе `UpdateCommand`:
|
||
|
||
```text
|
||
src/Cli/Commands/UpdateCommand.php
|
||
```
|
||
|
||
На этом этапе выполняются следующие действия:
|
||
|
||
1. Определите значение **текущий тип панели** (`MAIN` или `LB`).
|
||
2. Извлекать обновленные метаданные из **ГитХаб**:
|
||
- Прямая ссылка на архив обновлений.
|
||
- Контрольная сумма SHA для проверки целостности.
|
||
3. Загрузите архив во временный каталог.
|
||
4. Убедитесь, что загруженный файл соответствует ожидаемому хэшу.
|
||
5. Передайте управление программе обновления системного уровня (Python):
|
||
|
||
```bash
|
||
sudo /usr/bin/python3 /home/xc_vm/update "/home/xc_vm/tmp/.update.tar.gz" "HASH" > /dev/null 2>&1 &
|
||
```
|
||
|
||
> 💡 После завершения обновления Python программа вызывает `console.php update post-update`, что запускает [миграцию базы данных](../guides/database-migrations.md) и очистку после обновления.
|
||
|
||
---
|
||
|
||
## 4. Обновление на системном уровне (уровень Python)
|
||
|
||
Управление передается скрипту на Python:
|
||
|
||
```text
|
||
/home/xc_vm/update
|
||
```
|
||
|
||
Он выполняет привилегированные системные операции:
|
||
|
||
1. **Повторная проверка** контрольная сумма архива.
|
||
2. **Остановите панель** для предотвращения конфликтов во время обновления.
|
||
3. **Извлекать** архив во временный каталог:
|
||
|
||
```bash
|
||
/tmp/xc_vm_update_*/
|
||
```
|
||
|
||
4. **Удаление исключенных каталогов** из временной копии — двоичные файлы, конфигурации и пользовательские данные, которые нельзя перезаписывать:
|
||
|
||
`bin/ffmpeg_bin`, `bin/nginx`, `bin/nginx_rtmp`, `bin/php`, `bin/redis`, `bin/install`, `bin/maxmind`, `bin/certbot`, `content`, `backups`, `tmp`, `config`, `signals`
|
||
|
||
5. **Скопируйте оставшиеся файлы** поверх текущей установки:
|
||
|
||
```bash
|
||
cp -a /tmp/xc_vm_update_*/. /home/xc_vm/
|
||
```
|
||
|
||
6. **Закрепить право собственности**:
|
||
|
||
```bash
|
||
chown -R xc_vm:xc_vm /home/xc_vm/
|
||
```
|
||
|
||
7. Выполнение задач после обновления:
|
||
|
||
```bash
|
||
/home/xc_vm/console.php update post-update
|
||
```
|
||
|
||
8. **Перезапуск** панель находится в нормальном рабочем режиме.
|
||
9. **Уборка** откройте временный каталог и удалите архив.
|
||
|
||
> ℹ️ Один и тот же архив используется как для установки, так и для обновления. Фильтрация выполняется на сервере во время обновления — список исключений определяется непосредственно в `src/update`.
|
||
|
||
---
|
||
|
||
## 5. Завершение обновления
|
||
|
||
Заключительные шаги выполняются на этапе `post-update` из `UpdateCommand`:
|
||
|
||
1. Если включено значение **Автоматическое обновление LB** и был обновлен главный узел (`MAIN`), → создайте сигналы `update` для всех подсистем балансировки нагрузки.
|
||
2. Обновите значение **панельная версия** в базе данных.
|
||
3. Удалите устаревшие файлы.
|
||
4. Повторно примените правильные разрешения:
|
||
|
||
```bash
|
||
chown -R xc_vm:xc_vm /home/xc_vm/
|
||
```
|
||
|
||
5. Перезагрузить systemd демонов:
|
||
|
||
```bash
|
||
sudo systemctl daemon-reload
|
||
```
|
||
|
||
6. Проверка состояния панели:
|
||
|
||
```bash
|
||
sudo /home/xc_vm/console.php status
|
||
```
|
||
|
||
7. Отметьте процесс обновления как завершенный.
|
||
|
||
---
|
||
|
||
## 6. Полная схема рабочего процесса
|
||
|
||
```text
|
||
[ Web Interface ]
|
||
│
|
||
▼
|
||
[ DB: "update" signal ]
|
||
│
|
||
▼
|
||
[ CRON → console.php cron:root_signals ]
|
||
│
|
||
▼
|
||
[ UpdateCommand (PHP): download + verify hash ]
|
||
│
|
||
▼
|
||
[ update (Python): extract to /tmp → remove excluded → copy over ]
|
||
│
|
||
▼
|
||
[ post-update → UpdateCommand ]
|
||
│
|
||
▼
|
||
[ Finalize, restart daemons, update version in DB ]
|
||
```
|
||
|
||
---
|
||
|
||
## Откат (понижение рейтинга)
|
||
|
||
Сервер также можно откатить до версии **ранее**. Это повторяет описанный выше процесс обновления, но нацелен на выбранную версию, а не на последнюю — повторно используется тот же конвейер signal → CRON → PHP → Python и тот же инструмент `src/update` applier'а. Откат выполняется для каждого сервера, поэтому `MAIN` и каждый `LB` могут быть понижены независимо друг от друга.
|
||
|
||
1. **Инициация.** В **Серверы → Управление серверами** меню "Действия для каждого сервера" содержит пункт **Версия для отката**. Открывается диалоговое окно со списком более ранних версий (предварительные версии помечены как `(beta)`), выбранных с помощью действия `rollback_versions` API (`GitHubReleases::getPreviousVersions()`). При выборе версии вводится сигнал — `{"action":"rollback","version":"X.Y.Z"}` - для этого сервера.
|
||
|
||
2. **Триггер CRON.** `cron:root_signals` обрабатывает сигнал `rollback`, запуская:
|
||
|
||
```bash
|
||
/home/xc_vm/console.php update rollback X.Y.Z
|
||
```
|
||
|
||
3. **PHP layer (`UpdateCommand`, `rollback` case).**
|
||
- Проверьте целевую версию (`X.Y.Z`, строго более старую, чем текущая версия).
|
||
- Только для **главный**: выполните автоматическое резервное копирование базы данных в `backups/pre_rollback_<from>_to_<to>_<timestamp>.sql`, прервав его в случае сбоя. Узлы LB не имеют базы данных и пропустите это.
|
||
- Откройте архив версии **точный** с помощью `GitHubReleases::getVersionFile()` (MAIN → `xc_vm.tar.gz`, LB → `loadbalancer.tar.gz`), загрузите его и проверьте MD5.
|
||
- Передайте в тот же Python updater (`src/update`).
|
||
|
||
4. **Система + завершение.** Аналогично обновлению: скрипт на Python останавливает панель, заменяет дерево (сохраняя двоичные файлы/конфигурацию/данные) и `post-update` устанавливает версию в базе данных на откатную версию и перезапускает панель.
|
||
|
||
The version list is channel-aware: the `stable` channel offers only stable releases, `beta` also offers `(beta)` pre-releases.
|
||
|
||
> ⚠️ Понижение версии **не отменяет перенос базы данных** (они доступны только в прямом режиме). Схема поддерживается с обратной совместимостью, а автоматическое ОСНОВНОЕ резервное копирование является способом восстановления. Программа Python выполняет копирование по дереву (`cp -a`) без удаления файлов, поэтому файлы, добавленные в более новой версии, сохраняются до следующего обновления.
|
||
|
||
---
|
||
|
||
## ключевые функции
|
||
|
||
- **Двойная проверка целостности** (оба уровня - PHP и Python - проверяют хэш).
|
||
- **Автоматическое распространение** обновлений от ОСНОВНОГО до всех подсистем балансировки нагрузки.
|
||
- **Уборка** для удаления устаревших файлов и нормализации разрешений.
|
||
- **Безопасный перезапуск панели управления** после установки.
|
||
- **Гибкость и автономность** благодаря запуску на основе сигнала CRON +.
|
||
|
||
---
|