Миграция с GLPI 10 на GLPI 11 почти никогда не ломается на команде обновления базы - она ломается на том, что происходит до и после неё. Это руководство объединяет план, который мы применяем при сопровождении клиентов: где на самом деле всё ломается, как защитить каждый этап и как откатиться, если что-то пойдёт не так.
Прежде всего: почему миграция требует методичности
Миграция с 10 на 11 необратимо изменяет схему базы и заменяет весь слой представления (теперь на Symfony и Twig). Это не «заменить файлы и запустить». Две вещи, которые чаще всего приводят к незапланированному простою, - несовместимые плагины, активные во время обновления, и версия PHP, установленная на сервере. Относитесь к миграции как к небольшому проекту, с окном и планом отката, а не как к хотфиксу. Запланируйте также предупредить пользователей, что интерфейс 11 визуально отличается от интерфейса 10: значительная часть заявок после миграции - это люди, потерявшиеся в новом макете, а не настоящие баги.
Чек-лист перед миграцией
- Полная резервная копия базы (mysqldump) и каталогов конфигурации и данных.
- Находиться на последней минорной версии GLPI 10 (самой свежей 10.0.x) перед переходом на 11.
- PHP 8.1+ установлен и активен в правильной версии для CLI и FPM.
- Инвентаризация плагинов со статусом совместимости каждого с GLPI 11.
- Тестовая среда с реальной копией базы для репетиции миграции.
Плагины: что меняется в GLPI 11
| Плагин | Статус в GLPI 11 | Действие перед миграцией |
|---|---|---|
| FormCreator | Вошёл в ядро (встроенные формы) | Деактивировать и удалить |
| GenericObject | Вошёл в ядро (пользовательские объекты) | Деактивировать и удалить |
| FusionInventory | Прекращён | Перейти на GLPI Agent |
| Fields, Escalade, DataInjection, PDF, Tag | Есть версия для 11 | Обновить после миграции |
| NexTool | Совместим с 10 и 11 | Обновить до версии для 11 |
| Плагины без обновлений с 2023 года | Вероятна несовместимость | Оценить замену |
1. Полная (и проверенная) резервная копия
Резервная копия, которую вы ни разу не восстанавливали, - это не резервная копия, а надежда. Создайте её и как минимум проверьте размер файла:
# Banco de dados
mysqldump -u root -p --single-transaction glpi > /backup/glpi_pre_migration.sql
# Arquivos (config, dados e plugins)
tar -czf /backup/glpi_files_pre_migration.tar.gz /var/www/glpi /etc/glpi /var/lib/glpi2. Деактивировать несовместимые плагины
В GLPI 10 перейдите в Настройки > Плагины и деактивируйте все, у которых нет версии для 11. Удалите каталоги несовместимых. Этот шаг не опционален: это причина № 1 сбоев команды обновления.
3. Обновить файлы GLPI
cd /tmp
wget https://github.com/glpi-project/glpi/releases/download/11.0.0/glpi-11.0.0.tgz
tar -xzf glpi-11.0.0.tgz
# Substituir arquivos preservando config, dados e plugins
rsync -av --delete /tmp/glpi/ /var/www/glpi/ --exclude plugins/ --exclude marketplace/
chown -R www-data:www-data /var/www/glpiВсегда скачивайте последний стабильный релиз линейки 11.x, не обязательно 11.0.0.
4. Выполнить миграцию базы
php /var/www/glpi/bin/console db:update --no-interactionЭта команда применяет все миграции схемы. Следите за выводом целиком - любую ошибку нужно устранить, прежде чем продолжать, и никогда не игнорировать.
5. Очистить кэш и сессии
php /var/www/glpi/bin/console cache:clear
rm -rf /var/lib/glpi/_sessions/*6. Проверка после миграции
- Вход работает, а версия в Настройки > Общие показывает 11.x.
- Заявки, активы и пользователи на месте, с ожидаемыми итогами.
- Создание новой заявки работает от начала до конца.
- В логах нет повторяющихся ошибок после нескольких минут работы.
- Включайте и обновляйте совместимые плагины по одному, проверяя после каждого.
Чему нас научило сопровождение
На практике миграция редко ломается на самом db:update. Она ломается после: несовместимый плагин, оставшийся активным, роняет интерфейс с ошибкой 500, PHP в FPM указывает на версию, которую GLPI 11 не принимает (в то время как CLI уже на 8.1), или клиент, пропустивший минорную версию 10, подходит к команде обновления со схемой, которая не совпадает. Поэтому наш план всегда сначала обновляет до последней 10.0.x, проверяет и только затем переходит на 11 - и включает плагины по одному, никогда все сразу, потому что, когда что-то ломается, нужно точно знать, какой плагин виноват.
Самая частая ловушка
Классическая ошибка - считать, что формы FormCreator сами перейдут во встроенные формы GLPI 11. Не перейдут: плагин уходит, а созданные им формы нужно вручную пересоздать в новом ядре. Проведите инвентаризацию форм FormCreator до удаления плагина, иначе вы обнаружите потерю в продуктиве, когда пользователь пожалуется, что форма пропала. Вторая по частоте ошибка - запуск db:update с ещё активным несовместимым плагином: консоль пытается загрузить плагин, находит API, которого больше нет, и прерывается посреди миграции.
Откат: когда что-то пошло не так
Поскольку изменение схемы необратимо, откат - это не «отменить», а восстановить предыдущее состояние. Поэтому проверенная резервная копия из этапа 1 не обсуждается:
# Restaurar arquivos
tar -xzf /backup/glpi_files_pre_migration.tar.gz -C /
# Restaurar banco
mysql -u root -p glpi < /backup/glpi_pre_migration.sqlРепетиция такого восстановления в тестовой среде до реального окна - вот что отличает лёгкий испуг от инцидента.
Следующий шаг
После миграции изучите встроенные формы и другие новшества GLPI 11 и верните необходимые плагины. Чтобы расширять ядро, не накапливая плагины, которые ломаются при следующей мажорной версии, NexTool собирает десятки модулей в одном плагине, с версиями для 10 и 11. Нужна поддержка при миграции? Свяжитесь с командой.
Проверено командой NexTool Solutions.
