Хаос-инженерия с помощью CI/CD-конвейеров Harness


Левый сдвиг хаос-инженерии

Появление облачно-нативной парадигмы и все более широкое внедрение Kubernetes привело к возникновению проблем, связанных с перестройкой архитектуры приложений: они должны быть распределенными, слабосвязанными и контейнерными (читай: микросервисами). Это также привело к появлению новых способов решения «операционных» аспектов, таких как развертывание и обновление, обеспечение хранения (в случае компонентов с состоянием), поддержание высокой доступности, масштабирование, восстановление и т. д. Kubernetes, как всеобъемлющая система оркестровки, предоставляет множество вариантов и подходов для их реализации. Однако это вносит значительную сложность.

Организации, переходящие на Kubernetes, обычно сталкиваются с необходимостью тестирования различных сценариев сбоев и глубокого изучения своих систем и процессов путем многократных экспериментов — для укрепления уверенности перед запуском в производство. Это способствовало «сдвигу влево» в хаос-инженерии, с более широким использованием хаоса в конвейерах CI/CD.

LitmusChaos улучшает поддержку CI/CD

Сообщество litmus отмечает значительный рост использования экспериментов с хаосом в конвейерах, в некоторых случаях еще до того, как артефакты сборки/развертывания сливаются в основной источник истины (выполняются на переходных PR-окружениях), а в большинстве случаев — как часть процесса непрерывного развертывания, когда артефакты сборки перемещаются в среду постановки, где они подвергаются «хаосу здравомыслия».

Хотя проект предоставил некоторую начальную (ограниченную) поддержку и представил примеры использования в этой области в рамках релизов 1.x: шаблоны Gitlab и действия хаоса Github, все еще оставалась необходимость в поддержке полнофункциональных сценариев хаоса, позволяющих настраивать все параметры эксперимента, а также проверять гипотезы с помощью зондов Litmus в конвейерах CI/CD. Другими словами, поддержка выполнения рабочих процессов, которыми можно управлять и просматривать из Chaos-Center.

Последние версии Litmus (v2.8.0+) предоставляют набор рефакторинговых/стандартизированных API для запуска рабочих процессов из конвейера, а также позволяют визуализировать и управлять хаос-рабочими процессами, запущенными с определенными метаданными (cluster_id & controller-instanceid labels) в Chaos-Center.

В этой заметке мы рассмотрим пример выполнения хаоса из конвейера Harness CI/CD.

Harness CI/CD

Платформа Harness Continuous Delivery as a Service предоставляет простой и безопасный способ для инженерных и DevOps команд выпускать приложения быстрее, безопаснее и надежнее. Harness автоматизирует весь процесс CI/CD, что помогает быстрее создавать, тестировать и развертывать улучшенные функции. Он использует машинное обучение для определения качества развертывания и автоматического отката неудачных развертываний, что экономит время, сокращает количество сценариев и ручной контроль. Она обеспечивает безопасность корпоративного уровня на каждом этапе конвейера CI/CD.

Вот краткое описание того, как можно настроить конвейер сборки и развертывания с помощью Harness.

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

Эксперименты с хаосом в трубопроводах Harness

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

или как этап внутри самой стадии развертывания, с возможностью отката развертывания в случае, если хаос-эксперимент не принес желаемых результатов.

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

Такой шаблон рабочего процесса хаоса можно либо создать вручную и использовать в качестве полезной нагрузки в вызове API, либо, что еще проще, предварительно сконструировать на Хаос-центре, чтобы его можно было повторно запустить из конвейера, используя ссылку workflow_id.
Альтернативным механизмом является выполнение операции kubectl apply манифеста рабочего процесса, загруженного после его создания из Chaos-центра (эта модель предназначена для поддержки тех пользователей, которые предпочитают иметь золотую копию определения сценария хаоса наряду с артефактами развертывания). Статус и успех выполнения таких рабочих процессов можно отслеживать с помощью команд kubectl или через litmus API.

Заключение

Хотя эксперименты с хаосом как часть игровых дней под руководством SRE будут существовать и дальше, поскольку практика хаос-инжиниринга продолжает внедряться во все большем количестве организаций, ее потребление в сообществе разработчиков возрастет в разы благодаря ее включению в конвейеры CI/CD, что связано с культурой разработчиков, использующих build-to-deploy для своих изменений кода.

В этом посте мы показали пример того, как популярные CI/CD платформы, такие как Harness, принимают концепцию хаоса экспериментов и вводят ее в сферу конвейеров. Вы можете увидеть объяснение в действии в этой демонстрации Ниланджана, представленной во время встречи Cloud Native Scale.

Оцените статью
Procodings.ru
Добавить комментарий