Помощь
Документация
Вход 
Популярные инструменты
Если вам нужно решить задачи доставки, обновления и отката приложений, стоит обратить внимание на следующие варианты:
- 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 — промышленную систему управления жизненным циклом ПО через пакеты.
- У нас не было развитых систем управления конфигурациями, системы оркестрации контейнеров, системы обнаружения сервисов и централизованного логирования.
- Разработчики не были готовы активно применять контейнеризацию. Нам пришлось бы сразу документировать и автоматизировать разработку, тестирование и деплой, а расширять инфраструктуру и компетенции уже в процессе.
Этот выбор позволил нам задокументировать ПО, разобраться с поддержкой оборудования и получить время на развитие инфраструктуры.
Выводы
В этой статье мы хотели показать читателям логику принятия решения. Важным является адекватная оценка возможностей компании, специфики ее работы и планов развития. Внедрение модного инструмента без экономического и технического обоснования станет очень дорогой ошибкой, но не менее ошибочным является закрытие от инноваций и экстенсивное развитие.