Ставить отдельный плагин под каждую задачу кажется очевидным решением в GLPI - до дня обновления, когда половина из них не поднимается. За годы сопровождения сред GLPI клиентов мы поняли: узкое место редко бывает в одном плохом плагине - проблема в сумме дюжины разрозненных плагинов, у каждого из которых свой цикл релизов, свои зависимости и свой мейнтейнер. Это руководство показывает, как выбирать и сочетать расширения, не попадая в «plugin sprawl», где уместен модульный подход NexTool - и, честно, где он не нужен.
Проблема: «plugin sprawl»
Каждый плагин экосистемы GLPI - это отдельный проект: свой мейнтейнер, свой репозиторий, свой ритм релизов. Это сила open source-сообщества, но она превращается в обузу, когда в одной среде накапливается дюжина таких плагинов. Симптомы, которые мы видим чаще всего:
- Рассинхронизация совместимости с ядром - GLPI выпускает мажорную версию, и каждому плагину нужно собственное обновление, чтобы не отстать. Достаточно одного непортированного плагина, чтобы вся среда застряла на обновлении.
- Конфликты между плагинами - два плагина переопределяют один и тот же hook, внедряют конкурирующий CSS или регистрируют один и тот же маршрут. Симптом обычно проявляется далеко от причины.
- Неявные зависимости - плагин, который работает только при установленном другом, и это нигде не задокументировано. Отключите не тот - и ляжет функция, которую с ним никто не связывал.
- Многократно выросшая поверхность сопровождения - каждый плагин означает changelog, за которым нужно следить, CVE, которые нужно отслеживать, и вопрос «а поднимется ли он в следующий раз?» в каждое окно обслуживания.
Прежде всего: проведите инвентаризацию того, что уже есть
Перед любым обновлением - и перед установкой очередного плагина - первым делом мы выясняем, что установлено и в каком состоянии. Запрос, который мы выполняем прямо в базе:
-- Inventario dos plugins instalados no GLPI e o estado de cada um.
-- state = 1 significa ativado; os demais estados merecem atencao antes do upgrade.
SELECT directory AS plugin,
name,
version,
state
FROM glpi_plugins
ORDER BY state, directory;Для каждой строки результата - три вопроса: кто его поддерживает, с каким ритмом релизов и что сломается, если он не поднимется при следующем обновлении. Плагин, о котором никто не может ответить, - кандидат на удаление до окна обслуживания, а не во время него.
Три подхода бок о бок
Не каждая потребность требует одного и того же ответа. Таблица сводит компромисс между тем, чтобы закрыть пробел отдельным плагином сообщества, модулем NexTool или уже встроенной функцией GLPI 11:
| Критерий | Отдельный плагин сообщества | Модуль NexTool | Встроенная функция GLPI 11 |
|---|---|---|---|
| Зависимости | По одной на плагин, часто неявные | Один базовый плагин; модули тестируются вместе | Нет - часть ядра |
| Обновление / апгрейд | Каждый плагин в своём ритме; один отстающий блокирует обновление | Один пакет для обновления, совместимость тестирует поставщик | Обновляется вместе с GLPI |
| Конфликты | Реальный риск между плагинами разных мейнтейнеров | Ниже: модули тестируются вместе. Это не устраняет баги - но сосредотачивает ответственность в одном месте | Ноль - это само ядро |
| Покрытие версий | Зависит от плагина; для вашей версии может не существовать | База работает в GLPI 10 и 11; каждый модуль заявляет, в каких версиях работает (многие только для 11) | Следует за установленной версией |
| Поддержка | Сообщество / волонтёры, без SLA | Единый поставщик с каналом поддержки | Официальный roadmap проекта GLPI |
| Зависимость от поставщика | Низкая - открытый код, можно сделать форк и поддерживать самим | Высокая - roadmap, цена и непрерывность зависят от одной компании | От самого проекта GLPI |
| Нагрузка на сопровождение | Растёт с числом плагинов | Ровная - одна точка для отслеживания | Минимальная, но ограничена тем, что покрывает ядро |
Как работает модульный подход
Альтернатива - не отказ от функций, а сокращение числа независимых компонентов, которыми нужно управлять. NexTool переворачивает логику: вместо N плагинов - один базовый плагин (бесплатный), в котором размещаются модули, включаемые по необходимости.
- Единая точка установки - вы устанавливаете и обновляете базовый плагин; модули живут внутри него, и ни один из них не является отдельным пакетом в маркетплейсе.
- Включайте только то, чем пользуетесь - в каталоге есть ИИ, коммуникации, документы, безопасность, автоматизация и многое другое; вы включаете модуль за модулем по мере необходимости, не таская за собой ненужное.
- Без управления зависимостями между модулями - совместимость между ними - ответственность одного поставщика, она тестируется вместе в каждом релизе.
- Растущий каталог - новые модули появляются без новой установки плагина; они видны на экране модулей уже установленного плагина.
- Бесплатная база - базовый плагин и значительная часть модулей - FREE; лицензируемые модули соседствуют с ними в том же месте, и вы платите только за то, что включаете.
Чему нас научило сопровождение
У клиента с более чем 15 отдельными плагинами минорное обновление GLPI уронило половину из них: среда поднималась, но четыре плагина оставались в состоянии «требует обновления» и исчезали из меню. Чего никто не ожидал, так это того, что плагин отчётов зависел от таблицы, которую создавал другой плагин, - отключение второго молча выводило из строя первый. Целое окно обслуживания ушло только на то, чтобы выяснить, какой плагин блокирует какой. С тех пор мы решили считать каждый новый плагин долгом по сопровождению, а не бесплатной функцией. Типичная ошибка - которую совершали и мы - установить плагин ради одного-единственного отчёта и забыть его на два года, пока он не станет причиной, по которой обновление не удаётся завершить.
Кому подходит (и когда НЕ использовать)
Модульный подход раскрывается, когда вам нужно несколько согласованных функций - ИИ в заявке, уведомления в WhatsApp, наряд-заказ в PDF, процесс согласования - и вы хотите, чтобы за совместимость и поддержку отвечал один поставщик. Если ваша работа живёт в жёстких окнах обслуживания и не может позволить себе обновление, заблокированное брошенным плагином, централизация окупается.
Но будьте честны и в обратном: если один плагин сообщества уже хорошо закрывает вашу единственную потребность, установите его и двигайтесь дальше - нет смысла тянуть базовый плагин ради одного модуля. И главное - сначала посмотрите, что GLPI уже умеет из коробки. Встроенная инвентаризация (GLPI Inventory, начиная с GLPI 10) в большинстве случаев заменяет старый FusionInventory; формы и пользовательские объекты, для которых раньше требовались FormCreator и GenericObject, вошли в ядро в GLPI 11. Не всё требует плагина, и уж тем более NexTool: лучший плагин - обычно тот, который вам не нужно устанавливать.
Есть и компромисс, который централизация не решает, а лишь переносит: сосредоточив функции у одного поставщика, вы сосредотачиваете и риск. С отдельными open source-плагинами, если мейнтейнер забрасывает проект, можно сделать форк и продолжить. С проприетарным хабом roadmap, цена и непрерывность начинают зависеть от одной компании. Это не повод отвергать подход - это повод оценивать поставщика так же, как любого другого: история релизов, канал поддержки и что будет с вашими данными, если вы решите уйти.
Как включить модуль
- Установите базовый плагин NexTool как любой плагин GLPI: распакуйте в
plugins/, затем установите и активируйте в Настройки > Плагины. - В меню перейдите в Настройки > NexTool > Модули.
- Найдите нужный модуль в каталоге, проверьте поддерживаемые им версии GLPI и нажмите включить.
- Откройте экран настройки модуля и задайте параметры (API-ключи, каналы, профили - что потребуется).
- Повторите для каждого модуля. Ни один шаг не требует переустанавливать базовый плагин или вручную разрешать зависимости.
Совместимость
Базовый плагин NexTool бесплатен и работает как в GLPI 10, так и в GLPI 11. Совместимость модулей, однако, заявляется для каждого модуля отдельно: часть каталога кроссверсионная и работает в обеих версиях, тогда как значительная часть новых модулей доступна только для GLPI 11, поскольку опирается на возможности, существующие только там. Каталог показывает поддерживаемые версии каждого модуля, а включение блокируется с явным сообщением, если среда несовместима, - вы узнаёте об этом до установки, а не посреди обновления.
На практике тем, кто переходит с 10 на 11: проверьте в каталоге, какие из используемых вами модулей кроссверсионные. Это та же инвентаризация, которую этот пост рекомендует для любого плагина, - с той разницей, что здесь информация собрана в одном месте, а не разбросана по десятку репозиториев.
Если в вашей работе управление плагинами стало отдельной задачей, стоит познакомиться с NexTool как модульным хабом - или свяжитесь с командой, чтобы оценить, нужна ли в вашем случае централизация или ядро уже справляется.
Проверено командой NexTool Solutions.
