Как управлять программным обеспечением в корпоративной ИТ-инфраструктуре?

Популярные инструменты

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

• Docker;
• универсальную пакетную систему (Snap, Flatpack, Appimage);
• доставку через систему управления конфигурациями или иную систему, связанную с CVS/CI (например: Git\Jenkins);
• пакетную систему дистрибутива Linux (RPM, Deb и т.д.).

Изучим достоинства и недостатки каждого из них.

Docker

Плюсы:

• Docker — индустриальный стандарт, а значит найти специалистов для поддержки и развития системы будет несложно.
• Ощутимым плюсом Docker является возможность развертывания приложений независимо от среды исполнения: контейнер запускается и в продуктовом Kubernetes и на отдельной машине разработчика. Здесь есть свои нюансы, но в целом ситуация такова.

Минусы:

• Docker требователен к качеству инфраструктуры. Если вам нужны настоящие контейнеры с оркестрацией, понадобятся работающие и настроенные сервисы: система оркестрации, система мониторинга и алертинга, централизованное логирование, система обнаружения сервисов и система управления конфигурациями. Необходимо также умение выстраивать процессы CI/CD и готовность разработчиков к управлению всей системой.
• Обилие на рынке кандидатов со словом Docker или Kubernetes в резюме ничего не говорит об их компетенциях, а профессиональная команда обойдется недешево. Эти расходы не всегда оправданы и нужно учитывать стоимость решения, а также готовность компании оплачивать его разработку, внедрение и поддержку. Соскочить не получится, это добавит изрядный плюс в OPEX.

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

Универсальная пакетная система

Плюсы:

• Она проще Docker и не привязана к инфраструктуре. Получается не зависящее от дистрибутива решение, хорошо интегрированное с современными системами безопасности.
• Пакеты автономны как и контейнеры Docker. Есть возможность запуска нескольких приложений на одном хосте, обновление и откат происходят транзакционно и несут в себе все необходимое для запуска.

Минусы:

• Готовых специалистов по работе с любым из подобных решений мало, а их качественная интеграция с системами безопасности сложна.
• Требования к разработке остаются высокими, как и в случае с использованием Docker. Если пакеты собираются по принципу: набросать в кучу все зависимости с машины разработчика, завернуть и отправить на прод, результат будет соответствующим.
• Нет гибкости Docker: пакет — это не контейнер, он запустится почти на любом Linux, но и только. Запустить его как контейнер на MacOS или Windows не выйдет.

В итоге вы получите облегченный Docker с ограниченным набором плюсов и минусов. Проблема отсутствия готовых специалистов делает подобную систему малопривлекательной по сравнению с контейнерами.

Самописная система

Плюсы:

• Возможно, она уже у вас есть и работает.

Минусы:

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

Пакетная система дистрибутива

Плюсы:

• Позволяет полностью описать и задокументировать процедуру деплоя в единой форме.
• Доставка самописного и стороннего ПО отработана и унифицирована.
• Система относительно нетребовательна к специалистам и инфраструктуре.
• Наличие промышленных средств управления жизненным циклом ПО.

Минусы:

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

Выбор HOSTKEY

По ряду причин для доставки приложений мы используем пакетную систему дистрибутива:

• В хостинговой компании изначально приходилось делать деплой ОС для клиентов. Через пакетную базу дистрибутива мы собираем LiveCD. Сам деплой в плане поддержки оборудования также удобно расширять через пакеты.
• В HOSTKEY имелась развитая платформа виртуализации и мониторинга, а также была проведена унификация по инфраструктурному дистрибутиву.
• Ранее мы внедрили Foreman — промышленную систему управления жизненным циклом ПО через пакеты.
• У нас не было развитых систем управления конфигурациями, системы оркестрации контейнеров, системы обнаружения сервисов и централизованного логирования.
• Разработчики не были готовы активно применять контейнеризацию. Нам пришлось бы сразу документировать и автоматизировать разработку, тестирование и деплой, а расширять инфраструктуру и компетенции уже в процессе.

Этот выбор позволил нам задокументировать ПО, разобраться с поддержкой оборудования и получить время на развитие инфраструктуры.

Выводы

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