Канареечный деплой что это
Стратегии деплоя в Kubernetes: rolling, recreate, blue/green, canary, dark (A/B-тестирование)
Прим. перев.: Этот обзорный материал от Weaveworks знакомит с наиболее популярными стратегиями выката приложений и рассказывает о возможности реализации наиболее продвинутых из них с помощью Kubernetes-оператора Flagger. Он написан простым языком и содержит наглядные схемы, позволяющие разобраться в вопросе даже начинающим инженерам.
Схема взята из другого обзора стратегий выката, сделанного в Container Solutions
Одной из самых больших проблем при разработке cloud native-приложений сегодня является ускорение деплоя. При микросервисном подходе разработчики уже работают с полностью модульными приложениями и проектируют их, позволяя различным командам одновременно писать код и вносить изменения в приложение.
Более короткие и частые развертывания имеют следующие преимущества:
В этой публикации мы обсудим различные стратегии деплоя в Kubernetes, в том числе rolling-развертывания и более продвинутые методы, такие как канареечные (canary) выкаты и их разновидности.
Стратегии деплоя
Существует несколько различных типов стратегий развертывания, коими можно воспользоваться в зависимости от цели. Например, вам может потребоваться внести изменения в некое окружение для дальнейшего тестирования, или в подмножество пользователей/клиентов, или возникнет необходимость провести ограниченное тестирование на пользователях, прежде чем сделать некую функцию общедоступной.
Rolling (постепенный, «накатываемый» деплой)
Это стандартная стратегия развертывания в Kubernetes. Она постепенно, один за другим, заменяет pod’ы со старой версией приложения на pod’ы с новой версией — без простоя кластера.
Kubernetes дожидается готовности новых pod’ов к работе (проверяя их с помощью readiness-тестов), прежде чем приступить к сворачиванию старых. Если возникает проблема, подобное накатываемое обновление можно прервать, не останавливая всего кластера. В YAML-файле с описанием типа deployment’а новый образ заменяет собой старый образ:
Параметры накатываемого обновления можно уточнить в файле манифеста:
Recreate (повторное создание)
В этом простейшем типе развертывания старые pod’ы убиваются все разом и заменяются новыми:
Соответствующий манифест выглядит примерно так:
Blue/Green (сине-зеленые развертывания)
Стратегия сине-зеленого развертывания (иногда ее ещё называют red/black, т.е. красно-чёрной) предусматривает одновременное развертывание старой (зеленой) и новой (синей) версий приложения. После размещения обеих версий обычные пользователи получают доступ к зеленой, в то время как синяя доступна для QA-команды для автоматизации тестов через отдельный сервис или прямой проброс портов:
После того, как синяя (новая) версия была протестирована и был одобрен ее релиз, сервис переключается на неё, а зеленая (старая) сворачивается:
Canary (канареечные развертывания)
Канареечные выкаты похожи на сине-зеленые, но лучше управляются и используют прогрессивный поэтапный подход. К этому типу относятся несколько различных стратегий, включая «скрытые» запуски и А/В-тестирование.
Эта стратегия применяется, когда необходимо испытать некую новую функциональность, как правило, в бэкенде приложения. Суть подхода в том, чтобы создать два практически одинаковых сервера: один обслуживает почти всех пользователей, а другой, с новыми функциями, обслуживает лишь небольшую подгруппу пользователей, после чего результаты их работы сравниваются. Если все проходит без ошибок, новая версия постепенно выкатывается на всю инфраструктуру.
Хотя данную стратегию можно реализовать исключительно средствами Kubernetes, заменяя старые pod’ы на новые, гораздо удобнее и проще использовать service mesh вроде Istio.
Например, у вас может быть два различных манифеста в Git: обычный с тегом 0.1.0 и «канареечный» с тегом 0.2.0. Изменяя веса в манифесте виртуального шлюза Istio, можно управлять распределением трафика между этими двумя deployment’ами:
Пошаговое руководство по реализации канареечных развертываний с помощью Istio можно найти в материале GitOps Workflows with Istio. (Прим. перев.: Мы также переводили материал про канареечные выкаты в Istio здесь.)
Канареечные развертывания с Weaveworks Flagger
Weaveworks Flagger позволяет легко и эффективно управлять канареечными выкатами.
Flagger автоматизирует работу с ними. Он использует Istio или AWS App Mesh для маршрутизации и переключения трафика, а также метрики Prometheus для анализа результатов. Кроме того, анализ канареечных развертываний можно дополнить вебхуками для проведения приемочных (acceptance) тестов, нагрузочных и любых других типов проверок.
На основе deployment’а Kubernetes и, при необходимости, горизонтального масштабирования pod’ов (HPA), Flagger создает наборы из объектов (deployment’ы Kubernetes, сервисы ClusterIP и виртуальные сервисы Istio или App Mesh) для проведения анализа и реализации канареечных развертываний:
Реализуя контур управления (control loop), Flagger постепенно переключает трафик на канареечный сервер, параллельно измеряя ключевые показатели производительности, такие как доля успешных HTTP-запросов, средняя продолжительность запроса и здоровье pod’ов. Основываясь на анализе KPI (ключевых показателей эффективности), канареечная часть либо растет, либо сворачивается, и результаты анализа публикуются в Slack. Описание и демонстрацию этого процесса можно найти в материале Progressive Delivery for App Mesh.
Dark (скрытые) или А/В-развертывания
Скрытое развертывание — еще одна вариация канареечной стратегии (с ней, кстати, Flagger тоже может работать). Разница между скрытым и канареечным развертыванием состоит в том, что скрытые развертывания имеют дело с фронтендом, а не с бэкендом, как канареечные.
Другое название этих развертываний — А/В-тестирование. Вместо того, чтобы открыть доступ к новой функции всем пользователям, ее предлагают лишь ограниченной их части. Обычно эти пользователи не знают, что выступают тестерами-первопроходцами (отсюда и термин «скрытое развертывание»).
С помощью переключателей функциональности (feature toggles) и других инструментов можно следить за тем, как пользователи взаимодействуют с новой функцией, увлекает ли она их или они считают новый пользовательский интерфейс запутанным, и другими типами метрик.
Flagger и A/B-развертывания
Помимо маршрутизации с учётом весов, Flagger также может направлять на канареечный сервер трафик в зависимости от параметров HTTP. При А/В-тестировании можно использовать заголовки HTTP или файлы cookie для перенаправления определенного сегмента пользователей. Это особенно эффективно в случае frontend-приложений, требующих привязки сессии к серверу (session affinity). Дополнительную информацию можно найти в документации Flagger.
Автор выражает благодарность Stefan Prodan, инженеру Weaveworks (и создателю Flagger), за все эти потрясающие схемы деплоя.
Простой и безопасный способ автоматизации канареечных деплоев с помощью Helm
Эта заметка посвящена тому, как организовать подобный деплой средствами Kubernetes и автоматизации деплоя. Предполагается, что вы кое-что знаете о Helm и ресурсах Kubernetes.
Простой канареечный деплой в Kubernetes включает в себя два ключевых ресурса: сам сервис и инструмент развертывания. Канареечный деплой работает через одну службу, которая взаимодействует с двумя разными ресурсами, обслуживающими трафик обновления. Один из этих ресурсов будет работать с «канареечной» версией, а второй — со стабильной. В этой ситуации мы можем регулировать количество канареечных версий для того, чтобы снизить объем необходимого к обслуживанию трафика. Если, к примеру, вы предпочитаете использовать Yaml, то выглядеть в Kubernetes это будет следующим образом:
Еще проще представить такой вариант можно на kubectl, а в документации по Kubernetes даже есть полноценный туториал по этому сценарий. Но главный вопрос этого поста заключается в том, как мы собираемся автоматизировать этот процесс, используя Helm.
Автоматизация канареечного деплоя
Прежде всего нам понадобится карта чартов Helm, в которую уже внесены обсуждаемые нами выше ресурсы. Выглядеть она должна быть примерно так:
Основа концепции Helm — управление мультиверсиями релизов. Stable-версия — это наша основная стабильная ветка кода проекта. Но с помощью Helm мы можем развернуть канареечный релиз с нашим экспериментальным кодом. Главное — сохранить обмен трафиком между стабильной версией и канареечным релизом. Управлять всем этим мы будем с помощью специального селектора:
Наши как «канареечные», так и stable-ресурсы деплоя будут указывать эту метку на модулях. Если все настроить правильно, то во время деплоя канареечной версии нашей карты чартов Helm мы увидим, что трафик будет направляться на свежеразвернутые модули. Стабильная версия этой команды будет выглядеть так:
Теперь давайте проверим наш канареечный релиз. Чтобы задеплоить канареечную версию, нам надо помнить о двух вещах. Название релиза должно отличаться, чтобы мы не накатили апдейт на текущую stable-версию. Версия и тег также должны отличаться, чтобы мы могли развернуть другой код и определить различия по меткам ресурсов.
Вот, собственно, и все! Если пингануть службу, то можно увидеть, что канареечное обновление маршрутизирует трафик только часть времени.
Если вы ищите инструменты автоматизации деплоя, которые включают в себя описанную логику, то обратите внимание на Deliverybot и на инструменты автоматизации Helm на GitHub. Чарты Helm, используемые для реализации описанного выше способа лежат на Github, вот тут. Вообще, это был теоретический обзор того, как реализовать автоматизацию деплоя канареечных версий на практике, с конкретными концепциями и примерами.
Простой и безопасный способ автоматизации канареечных деплоев с помощью Helm
Канареечный деплой — это очень эффективный способ тестирования нового кода на каком-то подмножестве пользователей. Он значительно снижает трафик-нагрузку, с которой могут возникнуть проблемы в процессе развертывания, так как происходит только в пределах определенной подгруппы. Эта заметка посвящена тому, как организовать подобный деплой средствами Kubernetes и автоматизации деплоя. Предполагается, что вы кое-что знаете о Helm и ресурсах Kubernetes.
Простой канареечный деплой в Kubernetes включает в себя два ключевых ресурса: сам сервис и инструмент развертывания. Канареечный деплой работает через одну службу, которая взаимодействует с двумя разными ресурсами, обслуживающими трафик обновления. Один из этих ресурсов будет работать с «канареечной» версией, а второй — со стабильной. В этой ситуации мы можем регулировать количество канареечных версий для того, чтобы снизить объем необходимого к обслуживанию трафика. Если, к примеру, вы предпочитаете использовать Yaml, то выглядеть в Kubernetes это будет следующим образом:
Еще проще представить такой вариант можно на kubectl, а в документации по Kubernetes даже есть полноценный туториал по этому сценарий. Но главный вопрос этого поста заключается в том, как мы собираемся автоматизировать этот процесс, используя Helm.
Автоматизация канареечного деплоя
Прежде всего нам понадобится карта чартов Helm, в которую уже внесены обсуждаемые нами выше ресурсы. Выглядеть она должна быть примерно так:
Основа концепции Helm — управление мультиверсиями релизов. Stable-версия — это наша основная стабильная ветка кода проекта. Но с помощью Helm мы можем развернуть канареечный релиз с нашим экспериментальным кодом. Главное — сохранить обмен трафиком между стабильной версией и канареечным релизом. Управлять всем этим мы будем с помощью специального селектора:
Наши как «канареечные», так и stable-ресурсы деплоя будут указывать эту метку на модулях. Если все настроить правильно, то во время деплоя канареечной версии нашей карты чартов Helm мы увидим, что трафик будет направляться на свежеразвернутые модули. Стабильная версия этой команды будет выглядеть так:
Теперь давайте проверим наш канареечный релиз. Чтобы задеплоить канареечную версию, нам надо помнить о двух вещах. Название релиза должно отличаться, чтобы мы не накатили апдейт на текущую stable-версию. Версия и тег также должны отличаться, чтобы мы могли развернуть другой код и определить различия по меткам ресурсов.
Вот, собственно, и все! Если пингануть службу, то можно увидеть, что канареечное обновление маршрутизирует трафик только часть времени.
Если вы ищите инструменты автоматизации деплоя, которые включают в себя описанную логику, то обратите внимание на Deliverybot и на инструменты автоматизации Helm на GitHub. Чарты Helm, используемые для реализации описанного выше способа лежат на Github, вот тут. Вообще, это был теоретический обзор того, как реализовать автоматизацию деплоя канареечных версий на практике, с конкретными концепциями и примерами.
Canary деплой с Jenkins-X, Istio и Flagger
Доброго времени суток, читатель!
Вот мы и подошли к заключительной части цикла статей о Канареечных релизах в Kubernetes и методах их реализации. Желаю приятного чтения и надеюсь, что данный цикл был для вас полезным.
Использование решения Jenkins X для выполнения Canary деплоя в кластере Kubernetes
В этом цикле:
Что мы будем делать здесь?
Мы создадим Jenkins X k8s кластер и тестовое приложение на Python шаг за шагом. Вы можете повторять по примеру, либо просто читать, смотреть иллюстрации и результаты для получения представления о взаимодействии JenkinsX+Flagger+Istio сanary deployment и решить для себя, стоит ли эта связка более глубокого изучения.
Canary Deployment
Надеемся, что вы читали первую часть, где мы кратко объясняли что такое сanary deployment и показывали как его реализовать через стандартные ресурсы Kubernetes.
Jenkins X
И мы предполагаем, что читая эту статью, вы уже имеете представление о том, что такое Jenkins X. Если нет, то вы можете почитать о нем здесь.
Istio
Также, мы надеемся, что вы знаете что такое Istio. Если нет, то вы можете почитать о нем здесь. Вам также стоит прочитать часть 3, где мы осуществляли Canary deployment при помощи Istio, для лучшего понимания.
Flagger
Flagger это оператор Kubernetes, который автоматизирует сanary deployments используя Istio, Linkerd, App Mesh, NGINX, Contour или Gloo routing для управления трафиком и метрики Prometheus для canary-аналитики. Canary-аналитика может быть расширена с помощью веб-хуков для проведения тестов доступа, нагрузочных испытаний или любой другой проверки. (источник)
Создаем тестовую инфраструктуру и приложение
Мы будем использовать инструмент командной строки Jenkins X jx для создания кластера Kubernetes, репозитория Github и пробного приложения, он отлично подходит для создания быстрого примера.
Jenkins X k8s кластер
Первым делом мы создаем Jenkins X кластер, здесь мы используем Gcloud:
Вам нужно выбрать тип “Serverless Jenkins X Pipelines with Tekton” и привязать все к вашему Github аккаунту. Это автоматически создаст два Github репозитория для stage и production окружений.
Далее мы установим некоторые дополнения (addons):
Если вы столкнетесь с проблемами с Istio (у меня отсутствовали метрики istio_requests_total в Prometheus), вы можете установить Istio вручную:
Добавьте label istio-injection: enabled к любому namespace, в поды которого Istio sidecar должен быть внедрен.
Test App / Quickstart
Теперь ждем пока jxing-nginx-ingress-controller в namespace kube-system получит External IP. Затем создаем простое python-приложение:
Jenkins X автоматически создаст Github репозиторий для приложения.
Окружения
Jenkins X создаст три окружения по умолчанию ( jx get env ):
Каждое окружения имеет свой собственный Git-репозиторий, где все сконфигурировано через GitOps. Окружения на самом деле сконфигурированы из Helm Charts и ссылаются на все приложения + версии, установленные в них, через require.yaml.
Начальный Deployment
При создании нового quickstart приложения, или импорта существующего ( jx import ), он будет выпущен как версия 0.0.1 в stage окружении. Так происходит, потому что PROMOTE установлен в Auto для stage окружения. Мы можем видеть их как Pull Request в stage репозитории, который Jenkins X автоматически создает и сливает. Мы можем отслеживать все действия Pipeline через:
После того как pipelines завершатся успешно, мы можем проверить доступность приложений:
У нас должна быть возможность открыть доступ к stage приложению, через предоставленный URL:
Перемещение в production
(Прежде чем переходить в production я внес ещё одно изменение, которое увеличило версию до 0.0.2 )
Перемещение ( promote ) в production по факту означает “деплой”. Через jx get env мы можем увидеть, что production требует ручного деплоя, поэтому мы делаем:
Это автоматически создаст Pull Request в Jenkins X production Github репозиторий. И сейчас jx get applications покажет версию 0.0.2 на stage и так же на production:
Мы можем также переместить приложение в production через изменение requirements.yaml файла вручную в репозитории prod окружения.
Включение Canary для prod окружения
Прямо сейчас деплой в prod или stage производится без использования canary, но через rolling-rollouts Kubernetes.
В нашем репозитории для тестового приложения Python, Jenkins X автоматически создал через хелм-чарт. Если мы откроем файл charts/APP_NAME/values.yaml, то можем увидеть различные варианты Flagger Canary:
С данными настройками успешный canary deployment пройдет примерно за 3 минуты, по 1 минуте на каждый шаг: 20%, 40%, 60%.
Внесение изменений в репозиторий production окружения будет автоматически триггерить сборку в Jenkins X, проверим через:
Ждем пока все activities станут successful. Теперь нам нужно увидеть как автоматически создались Istio VirtualService и Gateway:
Заметим, что в первый раз, когда он был задеплоен, он не выполнит сanary, так как ему нужна предыдущая версия приложения для сравнения, но он заработает после второго деплоя. (источник)
Теперь нам нужна возможность доступа к нашему приложению в production через Istio на определенном хосте:
Откроем Flagger Grafana Dashboard
Flagger установит Grafana в namespace istio-system, следовательно, мы можем выполнить:
В Grafana перейдите в Istio Dashboard и введите:
Primary и canary это названия services. Они созданы автоматически при деплое, когда Canary был включен.
Flagger Canary Workflow и Анализ
В Helm Chart для Python приложений у нас есть множество настроек, которые мы можем изменять (здесь можно почитать описания большинства из них):
Мы должны скорректировать их в зависимости от потребностей нашего приложения. Flagger выполнит автоматический анализ метрик и будет выполнять развертывание только при соблюдении требований.
Чтобы увидеть текущий статус развертывания Canary, проверьте ресурсы Flagger:
Выполнение Canary Deployment
Deploy изменений
Сейчас мы изменили приложение app.py так, чтобы оно возвращало другой текст на GET запрос. Создаем Pull Request в master-репозитории с приложением и делаем его merge. Jenkins X выполнит его автоматический deploy на stage.
Теперь задеплоим его вручную на prod, скопируем новую версию, которая запущена на stage. Сейчас я на 0.0.6 версии, так как я внес некоторые изменения между ними:
И можем посмотреть статус работы Canary:
Запуск Canary с весом 20%
Мы запускаем повторяющийся curl на production Istio endpoint, который выдает результат, что 20% запросов отправлены на новую версию:
Canary терпит неудачу (недостаточно трафика)
Мы должны убедиться, что достаточно трафика достигает endpoint, иначе Canary анализ через Flagger провалится и запустит откат:
Canary также не запустится, если соответственные требования не будут выполнены.
Canary с весом 40%
Если трафика, который успешно достигает приложения достаточно, Flagger увеличит вес до 40%:
Canary с весом 60%
Если будет достаточно трафика, которое смог быть корректно обработан, Flagger увеличит его объем до 60%:
Canary прошел успешно
Теперь все запросы обрабатываются новой версией:
Jenkins X можно относительно легко настроить для работы с Istio и Flagger для Canary Deployments. Однако, у меня были проблемы с установкой Istio через jx create addon istio, и мне пришлось делать это вручную.
Я не игрался с настройками Flagger, но использование настроек просто по умолчанию, как мне кажется, отлично подходит для тестовых исследований. Я думаю, что как только вы познакомитесь с Jenkins X и с предлагаемым им функционалом, то сможете избавиться от множества ручной или повторяющейся работы.
Так же без Jenkins X, я думаю, сама по себе комбинация Flagger и Istio для Canary Deployments весьма мощна, относительно тех, которые я изучал самостоятельно в последнее время.
Ускоряем деплой на продакшен канарейками и самописным мониторингом
Привет, меня зовут Лёша, я работаю в SEMrush в команде SRE, которая занимается обеспечением бесперебойной работы нашего сервиса. Эта история о том, как мы разогнали деплой в 6 раз и сократили затраты на мониторинг в 3 раза. И все это через приручение канареек и самописные инструменты.
Я расскажу, как мы улучшали релизный пайплайн с помощью канареечного деплоя. Так, за пару лет мы прошли путь от «надо бы попробовать» до самописного тулинга.
Надо бы попробовать
До описываемой тут истории наш деплой был устроен вот так:
наш релизный пайплайн до внедрения канареечного деплоя
Есть ветка, в которой ведётся разработка новой фичи. В какой-то момент разработчик решает, что код готов к доставке пользователю. Тогда код заливается на тестовый стенд, прогоняются автоматические тесты, QA и PO делают ревью. Если всё ОК, происходит автоматическая раскатка по продакшн-окружению. Классика.
Вопрос, который мы постоянно задаём себе в команде SRE: «Насколько этот процесс быстрый и надежный?» Также было несколько моментов, которые мы хотели улучшить.
Хотим улучшить: удобство деплоя
В SEMrush тесты пишут команды разработки. В основном тесты нацелены на покрытие фич и бизнес-требований. Тестов много, и уследить за порядком не всегда было просто. Происходили ситуации, когда фича могла быть уже не актуальна, а тесты ещё не удалены.
Были сложности с упавшими тестами. Команд разработки несколько, у каждого теста есть свой владелец. Когда при запуске всего набора тестов что-то падало, приходилось искать владельца теста и выяснять, что могло пойти не так.
Всё это приводило к тому, что решение о мерже и деплое принималось в ручном режиме, а прохождение инкремента по всему релизному пайплайну могло занимать до 60 минут. Мы хотели сделать деплой более удобным для всех.
Хотим улучшить: покрытие тестами
Структурно тестовое окружение такое же, как продакшен, но отличия есть:
Зовём на помощь канарейку
Чтобы побороть эти проблемы, мы решили добавить в пул продакшн-серверов ещё одну ноду. План был такой: будем выкатывать туда бета-сборку с новой фичей и заводить туда часть пользователей, чтобы посмотреть, что всё работает корректно. Так у нас появилась канарейка
концепция канареечного деплоя
Wiki-минутка: на протяжении нескольких веков шахтеры брали с собой под землю канарейку. Птица чувствительна к газам, и если в шахте была утечка, канарейка умирала. Печально, но так шахтёры получали сигнал, что пора эвакуироваться из шахты. Канарейка спасала человеческие жизни.
По задумке канареечный деплой должен был принести с собой важное улучшение: принятие решения о раскатке фичи по продакшену на основе предварительно собранных метрик.
по задумке канареечный пайплайн должен был стать таким
Проводим кастинг на канарейку
Ок, пробуем настроить канареечный деплой. Самый первый вопрос: на ком будем экспериментировать и собирать заветные метрики. Тут навскидку было три варианта.
Первый вариант (решение в лоб) — направить на новую ноду часть реальных пользователей. Не подошло по нескольким причинам. Во-первых, фидбек от пользователей может быть довольно медленным. Нужно будет каждый раз ждать, пока соберётся статистика в достаточном объёме. Во-вторых, у нас в системе есть важные сценарии, которые случаются не так часто. Придётся ждать их появления, чтобы проверить. В-третьих, нам не хотелось портить user experience даже маленькой части пользователей. Отбрасываем вариант.
Второй вариант (отвергнутый) — задействовать наши тесты. Их у нас много. Но тоже не подходит. На продакшн-данных тестировать сложно. К тому же нужно постоянно следить, чтобы в тесты для продакшена не затесались проверки, которые нельзя там запускать. Отбрасываем вариант.
Третий вариант (рабочий) — система мониторинга продакшн-сервисов. Она работает в продакшн-окружении. Всегда актуальна и даёт сигналы, когда что-то сломалось. К ней высокое доверие: дежурные администраторы по сигналу системы мониторинга начинают чинить проблему даже ночью. Берём этот вариант.
Может получиться быстро и надёжно, идём проверять.
Proof of Concept
В качестве системы мониторинга на роль канарейки мы взяли Pingdom, которым тогда пользовались. Сработало! Канареечная концепция реализуется, ничего не ломается. Но вопросы остались.
Канарейка VS тесты VS мониторинг
С приходом канарейки наш деплойный пайплайн стал выглядеть так:
релизный пайплайн после внедрения канареечного деплоя
Для каждого окружения мы имели свой набор инструментов. Каждый нужно поддерживать, при этом все они работают по-разному. Неудобно по нескольким причинам.
Случалась проблема «ненастоящего» браузера. Pingdom использует эмуляции, которые могут отличаться от реального браузера.
Такую картину можно было наблюдать даже для в ситуациях, когда у пользователей все работало исправно.
Ещё была проблема с рассинхроном тестов и мониторинга. В команде SRE мы в первую очередь доверяем мониторингу. Ребята из QA ориентируются на тесты. Получается следующее: соответствующие инструменты в каждом окружении работают по-разному и непонятно, за кем последнее слово.
А ещё было тяжело дебажить упавшие тесты. Pingdom – внешний инструмент. Оттуда можно достать ограниченную информацию об инцидентах. Этого не всегда хватало, чтобы разобраться в проблеме. На запросы разработчиков часто приходилось разводить руками.
Чтобы победить эти проблемы, мы решили сделать свой инструмент.
Introducing SEMrush PURR
Нам нужен реальный браузер, единые сценарии тестов и мониторинга, удобный дебаг. Для интеграции с нашим GitLab CI мы хотели иметь возможность запуска из CLI. И, раз такое дело, заодно и возможность запуска по расписанию. Такими были требования к новому инструменту.
Решение: мы взяли Puppeteer, сделали обвязку из NodeJS, добавили Redis для очередей. Инструмент назвали SEMrush PURR (от Puppeteer Runner).
Puppeteer – инструмент от Google; делает та же команда, что Chrome. Это реализация DevTools Protocol для той консоли Chrome, которой мы пользуемся каждый день. На тот момент поддерживались Chrome, Firefox (beta), Edge (alpha).
Puppeteer помог нам решить проблему «ненастоящего» браузера. Запуск из CLI дал возможность встроить запуск SEMrush PURR в пайплайн GitLab CI.
запуск SEMrush PURR – финальный шаг пайплайна; если PURR падает, выкладки не происходит
Для удобства дебага мы получили возможность делать скриншоты, записывать видео, собирать логи и трейсы. Если проверка упала, можно увидеть картинку прямо в GitLab и посмотреть, что случилось.
дебажим упавшие тесты
Единые сценарии тестов и мониторинга стали описываться в YAML-файле.
YAML-файл со сценариями тестов и мониторинга
Там можно указывать разные параметры (например, домен, который мы тестируем). Тут на скриншоте указано, что работаем с куками и авторизацией.
Для работы по расписанию запускаем наше NodeJS-приложение в Kubernetes. Настраиваем расписание проверки с помощью Redis (библиотека Bull). Результаты проверок отгружаем в Prometheus. Оттуда забираем алерты, если что-то упало.
Варианты запуска по расписанию не ограничиваются только этим стеком. Можно использовать хоть cron, хоть Google Cloud Functions, хоть AWS Lambda. Или захостить у себя на виртуалке.
Унификация пайплайна с SEMrush PURR
В итоге SEMrush PURR дал нам заветное: один и тот же инструмент и сценарии для всех трёх окружений.
релизный пайплайн после внедрения SEMrush PURR
Главный результат внедрения SEMrush PURR – сократилось количество post-deploy инцидентов, когда на продакшене оказался код с ошибками.
С канарейкой, но без ограничений Pingdom, время доставки фичи на продакшен снизилось с 60 до 10 минут. Не нужно ждать, пока освободится тестовый стенд; не нужно ходить в другие команды узнавать, что с их тестами.
Отдельный позитивный момент работы с SEMrush PURR для нас лично то, что конфигурацией проверок занимается наша команда. Так что мы имеем возможность делать частью проверок те вещи, которые важны для продакшн-системы, на наш взгляд.
Дружите с канарейками
Канареечный деплой помог нам улучшить релизный пайплайн. Хочется верить, что со временем эта практика может стать индустриальным стандартом, как когда-то тесты в целом. Хочется, чтобы больше людей и компаний имели доступ к пользе от канарейки.
Если вы уже пользуетесь канареечным деплоем (или вот-вот начнёте), обратите внимание на Puppeteer. Он помог нам получить окружение для мониторинга, близкое к настоящему браузеру пользователя.
Если будете подбирать тулинг, посмотрите на SEMrush PURR. Он доступен на GitHub. Будем рады, если наш инструмент поможет вам сделать канареечный деплой удобнее.