Привет, Хабр! На связи Денис Мурунов, руководитель практики базовых инфраструктурных сервисов К2Тех. Дано: крупной организации нужно заменить Microsoft SCCM на тысячах рабочих мест. На столе — два российских решения: Зодиак АйТиЭм, с которым мы познакомились пару лет назад (читайте наш обзор), и Колибри-АРМ — относительно новый продукт с амбициями. Заказчик к выбору подошел основательно: сначала провёл самостоятельное пилотирование и тестирование решений. Затем мы подготовили подробное сравнение по требованиям ТЗ от заказчика, провели демонстрации. Полученные нами результаты говорили в пользу Зодиака, однако с учетом всех факторов выбрал пал на Колибри. Почему?

Читайте в статье, что стало решающим аргументом при выборе, почему даже еще развивающийся продукт может оказаться стратегически верным решением и чему учит непростое внедрение.

Поле боя — импортозамещение SCCM

Для понимания масштаба кейса, обозначим положение дел на рынке. В 2022-2023 российский энтерпрайз пережил тектонические сдвиги. Уход западных вендоров заставил целые индустрии в авральном режиме искать замену системам, которые были основой корпоративной инфраструктуры.

Microsoft System Center Configuration Manager — отличный пример такого решения. Для тех, кто работал с парком из сотен и тысяч Windows-машин, SCCM стал привычным инструментом управления жизненным циклом рабочих станций. Нишевое решение только для Windows оказалось очень доступным для организаций, выбравших экосистему Microsoft — продавалось в рамках подписки вместе с другими инфраструктурными продуктами, что и обеспечило ему популярность.

Чтобы заменить этот продукт для отечественных ОС на базе Linux, нужна была система, способная закрыть как минимум четыре критических направления:

Конечно, на место SCCM претендовали немало отечественных решений. Мы провели предварительный анализ рынка и выделили двух финалистов.

Зодиак vs Колибри: на кого поставил заказчик

Зодиак АйТиЭм — один из фаворитов рынка и основной конкурент Колибри. Мы начали с ним знакомиться на несколько месяцев раньше, протестировали возможности и наладили коммуникацию с вендором. Колибри-АРМ — продукт молодой и перспективный, но пока без устоявшейся репутации. Как и положено добросовестным инженерам, мы провели детальное сравнение двух систем. 

Прежде чем перейти к подробностям, предупрежу, что вся описанная ниже информация о решении была актуальна на ноябрь-декабрь 2024 года. С тех пор разработчики с обеих сторон привнесли крупные изменения в функциональные возможности продуктов, однако в статье мы приводим именно те характеристики Зодиака и Колибри-АРМ, на которые опиралась и наша команда, и заказчик на самом старте проекта. 

Зодиак отличался прозрачной архитектурой, полной поддержкой высокой доступности (Active-Active), проработанными функциями в части ИБ, гибкими сценариями кастомизации инвентаризации через скрипты и тем, что основные компоненты разработаны вендором самостоятельно, без использования опенсорсного ПО. Плюс, у этой системы уже была подтвержденная эксплуатация на крупных инфраструктурах.

С Колибри-АРМ ситуация иная. Решение сравнительно молодое, часть важных функций вроде высокой доступности еще в доработке, а некоторых функций, которые обычно запрашивают безопасники, не хватало. Основа — SaltStack и другие опенсорсные компоненты, из-за чего архитектура решения выглядела сложновато.

Инвентаризация в Колибри мощная, но с ограничениями. Система отлично собирает большой объем информации с устройств, а также позволяет её импортировать из внешних источников, однако научить её собирать что-то новое нельзя.

Все это мы упаковали в сравнительную таблицу* и представили заказчику, подсветили риски и дали рекомендацию. Тот внимательно выслушал, задал вопросы и ушел думать. 

*Актуальность таблицы - декабрь 2024 года, на момент публикации статьи данные изменились. Регулярно обновляемое сравнение систем управления конфигурациями доступно здесь.

Вернулся с решением — берем Колибри, и вот почему: 

• Готовая миграция. В разгар проектов импортозамещения с массовым переводом пользователей с Windows на Linux в релизе у Колибри был работающий шаблон миграции. У Зодиака же эта функциональность была в бета-версии, хотя они были готовы предоставить официальную гарантию доделать ее к нужной дате. Но для заказчика готовый продукт (пусть и несовершенный) перевесил обещания.

• Субъективное предпочтение интерфейса. На первый взгляд звучит как выбор автомобиля по цвету. Но если копнуть глубже, то за «интерфейсом» иногда кроется общее впечатление от UX, а это — скорость обучения персонала, прозрачность эксплуатации и количество ошибок. И в управлении инфраструктурой, где часто работают администраторы с разным опытом, этот фактор может быть решающим при близких технических характеристиках продуктов.

Решение принято и нам, как интегратору, предстояло применить на практике наши знания.

Первый раунд — установка системы 

Архитектура Колибри включает три основных блока: корневой сервер, точки распространения и база данных.

• Корневой сервер отвечает за логику системы: фронтенд, бэкенд, авторизацию, хранилище секретов. Он работает, как главная точка распространения — отсюда пакеты расходятся по остальным узлам. 

• Точка распространения — гибрид прокси и файлового хранилища. Она забирает пакеты с корневого сервера и раздает локальным машинам. Несколько точек распространения значительно снижают нагрузку на сеть между удаленными площадками. Но это не полноценный прокси. Агенты по-прежнему получают задания напрямую с корневого сервера и туда же отправляют данные инвентаризации, минуя точки распространения.

• База данных PostgreSQL хранит все необходимое: данные инвентаризации Колибри, секреты Conjur, отчёты Apache Superset, пользователей Keycloak и сессии MeshCentral.

Программное решение Колибри построено на микросервисах, где каждый компонент (сервис инвентаризации, импорта, веб-интерфейс и т.д.) упакован в свой Docker-контейнер.

Во время установки Колибри последовательно запускаются bash-скрипты, которые поочередно поднимают контейнеры со всеми этими сервисами. Эта процедура обычно работает отлично, но не в этот раз, так как в инфраструктуре заказчика было принято использовать нестандартный порт для PostgreSQL (например, 5550 вместо 5432). Казалось бы, тривиальная задача, которая решается одной строкой в конфигурационном файле или передачей параметра --db-port=5550 при установке. 

Однако мы обнаружили, что значение порта 5432 было намертво «приварено» — захардкожено — в десятках скриптов установки, разбросанных по разным подсистемам. Вооружившись grep и sed, пошли по этим скриптам. Пришлось вскрывать каждый, искать строки подключения к СУБД и вручную менять порт. Где-то он был указан явно, где-то использовался по умолчанию и нужно было дописывать его в строку подключения. На этот квест ушла уйма времени, посвященного поиску и замене пары цифр. 

Усилия не пропали даром — мы пробросили порты, а вендор прислушался к нашим просьбам. Теперь он планирует добавить в мастер установки возможность изменения портов. Но главное — мы глубоко изучили архитектуру Колибри-АРМ и составили детальную схему взаимодействия компонентов. Раньше такой схемы у нас не было, и когда что-то ломалось, мы не понимали, где искать проблему. У вендора есть похожая схема в документации, но она менее подробная.

Наша схема показывает, например, что сервис SignalR критически важен — через него агенты общаются с сервером. Если SignalR недоступен, основные функции Колибри-АРМ не работают. Поэтому при настройке мониторинга мы назначаем ему высокий уровень критичности, в отличие от того же tftpd.

Этапы настройки

После установки начались будни, когда новые шаги в настройке системы выявляли мелкие нюансы, требующие изобретательности.

Доставка файлов на АРМ. 

Банальный сценарий: нужно закинуть на рабочие станции какой-нибудь файл, скажем, обои с корпоративным логотипом. Обычно это делается парой кликов через веб-консоль. 

В Колибри сложнее — нужно вручную через SSH подключиться к серверу и загрузить файл в локальный репозиторий пакетов. Далее нужно написать скрипт для скачивания этого файла из репозитория и создать в Колибри задачу на его запуск на всех машинах.

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

Импорт списка компьютеров из службы каталогов с MAC-адресами. 

Для PXE-развертывания ОС система должна знать две вещи о компьютерах, на которые требуется накатить ОС: MAC-адрес сетевой карты и тип соединения — обязательно «Ethernet».

Список компьютеров у нас уже был заведен в службу каталогов ALD Pro, а в Колибри как раз есть такая функция — импортировать этот список из каталога! Первая проблема вылезла сразу: атрибут в ALD Pro назывался macAddress, а система ожидала увидеть в нем атрибут с именем MAC. Из-за этого несоответствия импорт не выполнялся.

Пришлось идти в обход. Настроили задание на импорт как есть, а потом нашли это задание в базе данных Колибри и руками переименовали название атрибута на macAddress. 

После этого импорт списка компьютеров был выполнен успешно. В текущей версии Колибри-АРМ изменять название ключевых атрибутов стало возможным непосредственно из интерфейса портала администрирования.

Но и это было ещё не все. Столкнулись с другой загвоздкой: чтобы заполнить поле «Тип подключения», нужно было импортировать это значение вместе с MAC-адресом. В схеме LDAP у заказчика хранились MAC-адреса, а вот поле «Тип подключения» там отсутствовало.

Специалисты техподдержки вендора оперативно отреагировали на эту проблему — помогли с обходным решением и включили исправление в свежий релиз. В итоге, мы поступили так: взяли неиспользуемый в ALD Pro атрибут «улица» (street) и скриптом забили в него строку Ethernet. Настроили маппинг этого поля на «Тип соединения» в Колибри.

Дальше предстояла работа с корпоративными сертификатами для защищенного подключения к ALD Pro по LDAPS. Здесь нас ждали еще две однотипные сложности в разных подсистемах. Дело в том, что в Колибри подключение к LDAP-каталогу настраивается в двух местах: 

1. В сервисе Keycloak —  для доменной аутентификации пользователей.

2. В модуле импорта —  для подключения к каталогу и импорта из него списка компьютеров.

Чтобы соединение с контроллером домена было безопасным, необходимо использовать протокол LDAPS, для которого необходимо использование сертификатов. На стороне ALD Pro использовался собственный корневой сертификат, который нужно было добавить в Колибри рядом с обычным корпоративным для защищенного подключения к службе каталогов. Колибри наотрез отказывался принимать его через штатные средства администрирования: один корневой сертификат импортировать можно, но импортировать второй без замены первого не получалось, а нам необходимо было использовать как корневой сертификат организации, так и сертификат ALD Pro. Эту проблему мы решили двумя разными способами:

Решение для Keycloak. Пришлось снова лезть «под капот» (к счастью, вендор дал нам готовую инструкцию, как это сделать). Мы подключались к работающему контейнеру с Keycloak через docker exec -it keycloak-keycloak-1 bash, получали внутри него командную строку и вручную, командами keytool, импортировали наш сертификат в хранилище keystore. 

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

Решение для модуля импорта

Вендор предложил решение: использовать переменную окружения LDAPTLS_REQCERT=never и поместить корневой сертификат ALD Pro в директорию с корпоративными сертификатами. В дополнение к этому, в интерфейсе Колибри мы указали правильную комбинацию параметров подключения к ALD Pro, как показано на скриншоте, и все заработало! Нужно было обязательно выбрать Режим «LDAPS» (не «StartTLS»), и поставить галочку «Проверка сертификата». 

Последний маленький сюрприз

Еще нам встретился забавный баг при той самой миграции с Windows на Linux, ради которой заказчик и выбрал продукт. По задумке перед началом миграции у пользователя на экране появляется красивое GUI-окно с таймером обратного отсчета, текстом предупреждения и кнопкой «Продолжить».

Но иногда по непонятной причине вместо этого окна система запускала... пустой «Блокнот». Просто белое окно без текста и кнопок. Пользователь недоумевает — что происходит? А за этим безобидным окошком уже идет процесс миграции.

И вот во время наших предварительных тестов все работало как надо, а на приемочных испытаниях нас ждал такой сюрприз!

Представьте картину: мы перед комиссией заказчика запускаем демонстрацию миграции на тестовом АРМ, и на экране торжественно появляется он — пустой, белый и пушистый. В комнате повисает пауза, и только мы, инженеры, знаем, что за этим невинным белым экраном тикает таймер до начала переустановки системы. К счастью, после ручной перезагрузки АРМ баг исчез, и миграция прошла штатно.

Мы подсветили проблему вендору, но оказалось, что у нее нет никакой воспроизводимости! 

На одном и том же АРМ баг может появиться спустя пять или двадцать пять перезагрузок или не возникнуть вовсе. Причем проявляется проблема только у конкретного заказчика. Вероятно, баг связан со спецификой настроек политик или другой особенностью инфраструктуры заказчика.

Переключаем оптику — видим логичный подход разработчиков

Разговор с архитекторами Колибри вскрыл интересную картину: странности и «костыли», с которыми мы столкнулись, оказались следствием того, что разработчики сосредоточены на основных функциональных возможностях решения. Причем нацеленных не на сиюминутное удобство, а на долгосрочную жизнеспособность продукта. Так что это — осознанные компромиссы и побочные эффекты такого подхода.

В текущих версиях Колибри-АРМ для доставки команд и конфигураций на управляемые компьютеры используется транспорт собственной разработки, но первые версии продукта использовали для этого SaltStack. Это было быстрое и логичное решение для начала: взять готовый, мощный open-source инструмент и построить на нем свою логику. Но когда продукт пошел в пилоты на тысячи машин, архитекторы уперлись в фундаментальные ограничения Salt.

Проблема не в том, что Salt плохо подходит для АРМ, наоборот, его pull-модель как раз хороша и для серверов, и для рабочих станций. Беда в другом: каждый агент при каждом запросе должен авторизоваться. На это требуются ресурсы, а периодичность запросов очень высокая. В результате может возникнуть ситуация, когда мастер-сервер не успевает обработать каждый запрос. 

По словам разработчиков, один Salt-master начинал задыхаться уже после 2000-3000 подключенных АРМ, требуя для дальнейшего роста очень серьезных вычислительных ресурсов.

Попытка масштабироваться по лучшим практикам Salt (выделить «мастера мастеров» и развернуть подчиненных ему «синдиков») привела к еще большим проблемам. Конструкция получилась нестабильной: постоянно отваливались GPG-ключи аутентификации, которые приходилось хранить на общем NFS-хранилище, агенты теряли доверие к своим мастерам. Количество управляемых устройств в консоли могло непредсказуемо скакать в течение дня, и поддержка этой инфраструктуры превращалась в отдельную трудоемкую задачу.

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

Почему все в Docker-контейнерах

Здесь снова проявился стратегический подход, решавший фундаментальные задачи российского рынка:

Совместимость с множеством отечественных ОС. В России нет единого стандарта для корпоративного Linux: используют Astra Linux, РЕД ОС, Альт, РОСА и другие. Поддерживать нативные пакеты (.deb, .rpm) и решать проблемы с зависимостями для каждой системы — прямой путь в производственный ад. Контейнеризация стала элегантным решением и создала слой абстракции: продукту не важно, какая ОС установлена на хосте, главное, чтобы поддерживала Docker Engine. Это позволило вендору не распылять ресурсы, а сосредоточиться на развитии функционала.

Фундамент для высокой доступности. Отсутствие полноценной High Availability было одной из наших претензий к продукту. Разработчики за 2024 год выполнили переход на контейнеры и заложили архитектуру, готовую к работе в кластере. 

Один из самых ценных инсайтов для технического специалиста — принцип разумной достаточности и понимание конечного пользователя при выборе Docker Swarm, а не индустриального стандарта Kubernetes (K8s) для управления контейнерами. 

Kubernetes — невероятно мощный и настолько же сложный инструмент. Он избыточен для развертывания одного-единственного инстанса Колибри в инфраструктуре заказчика. Его внедрение и поддержка требуют отдельной команды специалистов с высокой квалификацией, которых у среднего заказчика может и не быть. 

На этом фоне Swarm выглядит гораздо проще. Он встроен в Docker Engine и активируется одной командой. Его возможностей с лихвой хватает для обеспечения высокой доступности Колибри: репликация сервисов, базовый service discovery и rolling updates. 

Разработчики прагматично выбрали не хайповый, а подходящий инструмент, который не создаст заказчику дополнительной головной боли при эксплуатации.

Особенности управления обновлениями Windows

Даже такую утилитарную вещь, как управление обновлениями Windows, которой нет у аналогов, в Колибри реализовали с прицелом на стратегические риски — выбрали офлайн-механизм вместо прямой интеграции с WSUS, обеспечив независимость продукта от доступности онлайн-сервисов Microsoft. 

Работает это так: система скачивает с сайта Microsoft официальный офлайн-каталог обновлений — XML-файл wsusscn2.cab, содержащий метаданные обо всех актуальных обновлениях, и распространяет на клиентские машины. Агент на клиенте локально сканирует систему на предмет применимости обновлений из этого каталога и отправляет на сервер только результат — список недостающих компонентов. Администратор видит агрегированный отчет, скачивает нужные MSU/EXE файлы патчей, создает из них пакет и разворачивает на целевые машины.

Такой подход обеспечивает устойчивость к санкционным рискам: даже если публичные эндпоинты Windows Update будут заблокированы, механизм продолжит работать. Плюс позволяет эффективно патчить машины в полностью изолированных контурах, где доступ в интернет закрыт по определению.

Важные выводы по итогам проекта

Пройдя все круги установки и отладки, в итоге понимаешь, что оценивать Колибри-АРМ по шкале хорошо/плохо было бы в корне неверно. Продукт оказался сложным, с двойным, а то и тройным дном. Поэтому наш вывод состоит из четырех частей: 

1. Продукт — активное развитие, высокий потенциал и пространство для полировки некоторых деталей. На момент нашего внедрения Колибри представлял собой парадокс. На уровне опыта администрирования продукт был сыроват: захардкоженные значения, многошаговые процессы для решения некоторых простых задач. Процесс установки и первоначальной настройки Колибри требовал от инженера не просто следования инструкции, а понимания того, как система устроена «под капотом». 

В то же время мы увидели на удивление прочный и продуманный наперед архитектурный фундамент. Отказ от Salt в пользу собственного транспорта, полная контейнеризация для кросс-платформенной совместимости с отечественными ОС, прагматичный выбор Docker Swarm вместо избыточного Kubernetes и продуманная офлайн-модель патчинга выглядят верными решениями. Разработчики не стали поддерживать красивый фасад на гнилых сваях, а начали с закладки капитального фундамента. 

2. Вендор — живая команда и четкий вектор. Это один из ключевых плюсов, который перевешивает многие технические недостатки. Взаимодействие с командой Колибри отличалось от общения с безликой техподдержкой типичного энерпрайз-гиганта. У нас был прямой чат с инженерами и архитекторами, где нас реально слышали. Пример с выносом порта БД из хардкода в переменную в последующих релизах — лучшее тому подтверждение. Ребята вникли в нашу боль и, что самое важное, учли в своем бэклоге. Наличие публичной и внятной дорожной карты давало понимание, куда движется продукт, и позволяло соотнести наши ожидания с планами вендора.

3. Внедрение — R&D, а не инсталляция. С точки зрения управления проектом, внедрение Колибри в масштабной и сложной инфраструктуре заказчика нельзя рассматривать как стандартную инсталляцию коробочного ПО. По сути это был R&D-проект с приличными трудозатратами на исследования, отладку и поиск обходных путей. Закладывать время на такой проект нужно с существенным запасом на непредвиденные инженерные ситуации. Это не тот случай, когда можно просто передать задачу младшему администратору и действовать по инструкции. Здесь требуется глубокая вовлеченность высококвалифицированных специалистов. Зато теперь, когда мы обкатали этот процесс на практике, у нас есть понимание всех подводных камней и готовность тиражировать решение на многих заказчиков.

4. Дальше — проще. Несмотря на некоторые сложности, проект был успешно завершен и заказчик получил работающую систему, которая управляет АРМ в гео-распределенной инфраструктуре и смог выполнить миграцию АРМ с Windows на Linux. После внедрения Колибри успешно выполняет свои задачи и уже не требует вмешательства на низком уровне.

Мы продолжаем следить за развитием решения: разработчики набрали неплохие темпы – сейчас выходит по 3 крупных обновления в год. У нас в работе несколько проектов по внедрению новых версий продукта для новых заказчиках — обязательно поделюсь итогами. 

Кстати, потенциальных заказчиков Колибри-АРМ, исходя из нашего опыта, условно можно разделить на два профиля: 

Технологические лидеры. Крупные компании с сильной внутренней ИT-экспертизой (опытные Linux-администраторы, DevOps-инженеры, скриптовики). Они видят в Колибри не просто инструмент, а возможность получить конкурентное преимущество за счет передовых решений. Готовы к плотной работе с командой разработки, рассматривают процесс внедрения как совместную работу по созданию оптимального решения под свои задачи. Для них участие в развитии продукта — это инвестиция в долгосрочное технологическое превосходство и партнерство с инновационной командой.

Консервативные прагматики. Компании, которым критически важна предсказуемость и стабильность всех ИT-процессов. Приоритет — минимизация рисков и трудозатрат на поддержку. У них жесткие требования к SLA, ограниченные ресурсы на техническую поддержку, и каждое изменение в инфраструктуре проходит длительные процедуры согласования. Таким организациям стоит воспользоваться опытом выполняемых в настоящее время масштабных внедрений Колибри и внедрять версии продукта, в которых разработчики Колибри отполируют пользовательский опыт и продемонстрируют его возможности к масштабированию.

Практические рекомендации 

Если вы относите себя к первопроходцам и решились на пилотный проект, вот наш чек-лист, составленный на основе набитых шишек:

1. Проведите глубокий аудит инфраструктуры. Не ограничивайтесь стандартными вопросами. Узнайте про все нестандартные порты, самоподписанные и корпоративные сертификаты, особые требования ИБ к сетевым взаимодействиям, кастомные атрибуты в AD/LDAP, которые используются в ваших процессах. Каждый из этих пунктов может привести к затруднениям в процессе внедрения.

2. Оцените реальные компетенции команды. Вам понадобится не просто администратор, а специалист, который свободно владеет командной строкой Linux, умеет читать и править bash-скрипты, понимает, что такое docker exec и docker logs, и не боится залезть с psql в базу данных, чтобы посмотреть, что происходит или выполнить исправления по указанию техподдержки вендора.

3. Добейтесь прямого контакта с опытной инженерной командой. Вам нужен прямой доступ к людям, которые владеют продуктом. Настаивайте на создании выделенного чата или регулярных технических синках. Этот канал коммуникации — ваш самый ценный ресурс в проекте.

4. Закладывайте буферное время на R&D. Смело умножайте первоначальные оценки трудозатрат на 1,5. Эти дополнительные 50% уйдут на то, что мы называем «незапланированные исследовательские задачи» — поиск причин странного поведения системы и изобретение «обходных путей».

5. Начинайте пилот с самого сложного и нетривиального кейса. Не тратьте время на проверку простой доставки ПО. Сразу беритесь за ваш самый заковыристый бизнес-процесс. Если вы сможете решить его вместе с вендором, все остальное покажется легкой прогулкой.

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

Проект показал, что универсального ответа нет. Это выбор между предсказуемым настоящим и более рискованным, но потенциально более выгодным будущим. И Зодиак, и Колибри — решения со своими особенностями, нюансами и ограничениями. Познакомившись с ними на практике, мы готовы делиться опытом. 

Знание всех подводных камней — тот актив, который мы предлагаем вместе с техническим решением. Поэтому для наших заказчиков вопрос не в том, как безболезненно заменить SCCM, а в том, как использовать выбранную систему по-максимуму.