Методологию DevOps часто отождествляют с контейнерами. Многие компании и вовсе игнорируют её потенциал, полагаясь лишь на них. Ведущий инженер компании Perrone Robotics Эрик Бруно поделился с изданием InformationWeek опытом использования DevOps-практик, которые исключают использование контейнеров.

Под термином DevOps обычно подразумевают методологию разработки ПО, сфокусированную на предельно активном взаимодействии и интеграции «в одной упряжке» программистов, тестировщиков и администраторов, синхронизированно обслуживающих общий для них сервис/продукт/ПО. Совместная работа группы специалистов устремлена на устранение узких мест при разворачивании приложения.

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

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

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

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

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

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

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

По словам Бруно, контейнеры — это не панацея, помимо них успешный проект DevOps может ориентироваться на следующие технологии:

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

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

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

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

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

Соблюдая эти условия, вы будет уверены, что софт создается не в изолированной среде. У вас будет ясное представление о готовности его компонентов (кода, интерфейсов) не только на момент окончания разработки, но и на её протяжении. Полной информацией также будут обладать участники проекта, при этом хорошо осознавая, какие компоненты софта им следует улучшить или что изменить. Таким образом, методология DevOps выходит за рамки рутинного написания кода, формируя образ готового продукта еще до его создания.

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

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

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