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

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

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

• 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 с ограниченным набором плюсов и минусов. Проблема отсутствия готовых специалистов делает подобную систему малопривлекательной по сравнению с контейнерами.

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

Плюсы:

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

Минусы:

• Нет внешних специалистов, требуется онбординг.

• Поддержка трудозатратна.

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

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

Плюсы:

• Позволяет полностью описать и задокументировать процедуру деплоя в единой форме.

• Доставка самописного и стороннего ПО отработана и унифицирована.

• Система относительно нетребовательна к специалистам и инфраструктуре.

• Наличие промышленных средств управления жизненным циклом ПО.

Минусы:

• Привязка к дистрибутиву.

• Единообразно развернуть версию ПО у разработчика и в продуктовой среде нельзя, а значит возникает необходимость в дополнительном тестировании.

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

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

Выбор HOSTKEY

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

• В хостинговой компании изначально приходилось делать деплой ОС для клиентов. Через пакетную базу дистрибутива мы собираем LiveCD. Сам деплой в плане поддержки оборудования также удобно расширять через пакеты.

• В HOSTKEY имелась развитая платформа виртуализации и мониторинга, а также была проведена унификация по инфраструктурному дистрибутиву.

• Ранее мы внедрили Foreman — промышленную систему управления жизненным циклом ПО через пакеты.

• У нас не было развитых систем управления конфигурациями, системы оркестрации контейнеров, системы обнаружения сервисов и централизованного логирования.

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

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

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

Выводы

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

Готовность к изменениям и адекватная оценка задачи — залог построения качественной, хорошо документированной и долговечной инфраструктуры. В следующей статье мы опишем некоторые полезные лайфхаки для построения системы RPM-deploy.

Кстати, в HOSTKEY можно пользоваться всеми возможностями технологичного API для быстрого заказа и управления серверами. Выберите сетевые настройки, операционную систему и получите любой сервер в течение 15 минут. Вы также можете собрать сервер индивидуальной конфигурации, в том числе с профессиональными GPU-картами.

Еще у нас можно добавить NVIDIA А5500, а специальный промокод для наших читателей «Я С ХАБРА» дает дополнительную скидку на любую покупку. При размещении заказа назовите промокод консультанту — и скидка ваша.