Речь пойдёт про VDI-портал: систему, которая клонирует виртуалки из шаблона, выдаёт их пользователям и гасит простаивающие. Но статья не о нём как о продукте, а об одном вопросе, который на входе выглядит тривиальным: этой машиной ещё пользуются? Ссылка на код будет в конце, одна.

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

Первое решение было очевидным — скрипт по таймауту. Никто не подключён N минут — машина гасится. Понадобилась — поднимается.

Скрипт я написал за вечер, и он даже работал, но по итогу я изобрёл VDI. Только не так, что посмотрел готовые решения и они меня не устроили, — я вообще не формулировал свою задачу как «нужен VDI» и потому не искал. Я решал «пусть виртуалки сами гасятся», а всё остальное наросло само, вопрос за вопросом. Когда стало очевидно, во что это превратилось, переезжать на готовое было уже и поздно, и незачем.

Дальше разбираю вопросы, которые нарастали.

Изначально это был монолитный портал на Laravel 8, где user фронт и admin фронт лежали рядом с беком в одной папке. 

Проект ставился каждому клиенту на его собственный хостинг, и единого портала «для всех» не существовало, между клиентами отличался и бек, и фронт. 

Кому‑то требовался функционал онлайн‑тестирования, кому‑то доработанный модуль оценивания. В итоге получался хаос из разных версий, у одного улучшили обработку заявок, у другого систему оценок, у третьего есть онлайн‑тестирование, но с отсталым модерированием.

Хуже всего это вылезало в поддержке. Приходит баг, лезешь в код и понимаешь, у другого клиента это давно починено, просто фикс так и не доехал до этой копии. Каждая правка жила в своей репе.

Поэтому, когда появилось время, я занялся этим проектом. Сразу поставил рамку, фреймворк не меняю, остаёмся на Laravel 8. Хотелось не переходить на другой язык, не заниматься переписыванием всего огромного бека, отделить всё в модули и переписывать уже поэтапно отдельные куски.