Масштабируем автоматизацию тестирования с помощью Kubernetes

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

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

Перед рассказом о нашем опыте использования Kubernetes хотел бы сказать пару слов о себе. Меня зовут Хурсевич Алексей, я занимаюсь автоматизацией и развертыванием инфраструктуры под эти цели уже около 8 лет. Данная статья будет полезна DevOps инженерам и автоматизаторам, перед которыми стоит задача создания масштабируемой и стабильной инфраструктуры для запуска автотестов.

Что уже есть на рынке по автоматизации тестирования

Существует множество популярных платных решений вроде BrowserStack, Sauce Labs и LambdaTest. Подобные кластеры браузеров и мобильных устройств для мануального и автоматизированного тестирования — хороший вариант для малого бизнеса, который не в состоянии инвестировать крупные суммы в покупку новых устройств. Благодаря этим сервисам вы получаете удаленный доступ к любому устройству за 150$. Однако для крупных предприятий, которые ежедневно проводят тысячи тестов, эти решения могут оказаться довольно дорогими. Не подойдут они и высокотехнологичным компаниям, которые используют для тестирования свои виртуальные сети (VPC).

На рынке также присутствует достаточно много open-source решений. Например, известный многим Selenium Grid или более новые решения, базирующиеся на технологии Docker — Selenoid или Zalenium. Так или иначе, все они предполагают покупку или аренду серверного оборудования и постоянную поддержку со стороны DevOps инженеров. Такие инвестиции оправданы в случае действительно больших объемов ежедневных запусков автоматизации.

Эффективное решение для нашей команды

Наша инфраструктура для автоматизации состоит из следующих компонентов:

• Selenium Grid;
• Jenkins;
• Zebrunner (собственный репортинг-инструмент);
• Sonar (для статического анализа кода);
• OpenSTF (для удаленного управления мобильной фермой).

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

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

Кластерная топология Kubernetes

В топологии Kubernetes кластера выделяют 2 основных элемента: master и worker node. Для обеспечения отказоусточивости рекомендуется располагать мастера в различных регионах. По факту контейнеры ваших приложений разворачиваются на worker node, а мастера в свою очередь контролируют статус кластера, отвечают за ролаут новых версий и масштабирование с помощью kubelet сервиса.

В дополнение к фишкам master и worker node отмечу, что Kubernetes может быть развернут на различных инфраструктурах. Таким образом, кластеры можно легко разместить на личном оборудовании или у любого публичного облачного провайдера, например, Google, Amazon или Microsoft. Kubernetes предоставляет простое решение для создания кластерной сети, которая поддерживает связь с микросервисами через уровень абстракции услуг. При развертывании Kubernetes работает с такими объектами как Pods (аналог Docker-контейнера), Deployments, ReplicaSets и StatefulSets.

Основной челлендж

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

Сформулируем три критически важных вопроса:

• Как сделать тестирование изолированным и стабильным?
• Как все быстро настроить?
• Как получить необходимую инфраструктуру по разумной цене?

Изоляция и стабильность

Сперва поговорим о качественной автоматизации для CI. Для нашего CI-пайплайна мы выбрали Jenkins по следующим причинам: это open-source, для него есть большое количество плагинов, беспрецедентная надежность при работе с различными пайплайнами для разработки и тестирования. Одним из ключевых нюансов при установке Jenkins является корректная подготовка новых worker образов.

Поэтому я настоятельно рекомендую использовать плагин Jenkins Kubernetes. Основная суть заключается в том, что он выполняет каждую новую задачу Jenkins в контексте нового Kubernetes pod и удаляет данный ресурс сразу по завершении задачи.

С помощью Jenkins Kubernetes плагина можно передавать разные докер-образы под разные типы Jenkins задач, например, образы окружений Android SDK или NodeJS. Более того, вы можете легко управлять ресурсами для различных задач, выделяя для них необходимое количество процессоров и мегабайт оперативной памяти. Подробные инструкции по настройке плагина доступны по этой ссылке.

Перейдем к кластеру Selenium в контексте Kubernetes. Если вы работали с обычной Selenium Grid под большой нагрузкой, возможно, вы замечали его периодическую нестабильность; скорее всего, вам приходилось регулярно его перезапускать. Новые тесты могут зависать из-за утечек памяти, что несомненно может стать болью для автоматизации. Команде Aerokube удалось выпустить гораздо более стабильную версию Selenium Grid под названием Selenoid. Основная идея в том, что каждый тест выполняется в отдельном Docker контейнере, а после завершения теста контейнеры удаляются.

В Aerokube Selenoid вы можете наблюдать за тестовой сессией через VNC — это весьма удобно при отладке автоматических тестов.

Aerokube предлагает платное решение Moon — это коммерческая имплементация Selenium. Moon использует Kubernetes для запуска браузеров. Идея практически такая же, как я описывал выше, но вместо Docker-контейнеров Moon работает с Kubernetes pods.

Важно отметить, что Kubernetes имеет набор официальных плагинов, которые помогают решать различные задачи. Среди них можно найти полезный Kubernetes Autoscaler, который позволяет горизонтально масштабировать ваш кластер при возрастании нагрузки. Для управления нагрузками плагин контролирует использование ресурсов инфраструктуры, автоматически увеличивая или уменьшая auto scaling группы.

Быстрое распределение

Предположим, что на начальном этапе у нас есть кластер из одного master и трех worker nodes. Там размещены Jenkins мастер и две реплики Moon.

Как только мы начинаем запускать автоматизацию, Jenkins пытается аллоцировать woker pods, а Moon в свою очередь запускает браузерные контейнеры. В какой-то момент Kubernetes Autoscaler получает сигнал о необходимости добавить в кластер дополнительные сервера для деплоймента всех новых pods. По итогу мы получаем горизонтальное масштабирование кластера и автоматическую аллокацию новых задач по серверам.

Рекомендации в документации Kubernetes делают упор на важность контролироля явного выделения ресурсов для pods. Вы просто задаете request / limits параметры для лимитирования CPU и Memory ресурсов. На рисунке ниже показан пример распределения ресурсов для Jenkins worker, браузера Moon и эмулятора Moon Android.

Еще одна интересная фича Kubernetes — это node селекторы. Проектные задачи могут требовать различные типы инстансов из AWS. Например, для запуска Android эмуляторов нам требуются bare-metal сервера с поддержкой технологии KVM, в то время как браузерные сессии мы можем запускать на обычных виртуальных машинах. Такое распределение достигается за счет простой инструкции nodeSelector, которая позволяет поместить очередной pod на необходимый тип сервера.

Экономия бюджета

Так что же с бюджетом? Наша компания смогла значительно сэкономить, используя автоматическое масштабирование Kubernetes и Amazon Spot Instances. Обычно автоматизация тестирования использует инфраструктуру не равномерно. Например, можно выполнять регрессионные тесты в течение нескольких часов ночью или уже прогонять полную регрессию в конце спринта. В противном случае загрузка инфраструктуры потребует 10-20% от полной мощности. С помощью этих инструментов можно повышать масштаб кластера только тогда, когда это необходимо, и не платить за неиспользуемые мощности. Благодаря Amazon Spot Instances, мы сэкономили практически 80% от цены за сервера. На диаграмме ниже показана реальная история экономии бюджета для одного из клиентов компании:

Итоги

Мы уже почти 2 года используем Kubernetes для менеджмента инфраструктуры для автоматизации. Мы ощутили значительное облегчение в поддержке кластера и увеличение показателей стабильности системы. Операционные затраты стали значительно ниже за счет разумного масштабирования и использования Amazon Spot instances. Технология Kubernetes становится мировым стандартом для оркестрации сложных мультимодульных приложений в контексте облачных провайдеров. Как вы видите из нашего примера — это вполне подходящее решение и для построения автоматизации.