Вашему бизнесу необходимо развертывание Canary?

Достаточно ли непрерывной интеграции для тестирования?

Благодаря непрерывной интеграции каждый код с рабочих станций разработчиков включается в общий репозиторий или центральный репозиторий, после чего с помощью автоматизированной сборки и тестов эти коды проверяются и объединяются. Здесь мы замечаем, что это синтетические тесты, проще говоря, скрипты, на основе которых эти тесты происходят, лишь эмулируют пользовательский опыт. Они не могут помочь ИТ-команде понять фактическое взаимодействие с конечным пользователем. Это также не дает информации о ресурсах устройства и состоянии его работоспособности, что также может повлиять на производительность приложения.

Понимание «Canary» развертывания Canary

Прежде чем углубиться в то, как Canary Deployment помогает нам понять фактическое взаимодействие с конечным пользователем, давайте начнем обсуждение со значения его названия. Что ж, если где-то ваш разум сравнивает его с «Канарейками», значит, вы на верном пути!

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

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

Давайте определим Canary Deployment!

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

Шаги, включенные в канареечную стратегию развертывания

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

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

Начните с понимания базовой структуры канареечной стратегии развертывания. Мы можем разъяснить это под следующими заголовками:

• Творчество

• Анализ

• Развертывание/откат

Творчество

Для начала нам нужно создать канареечную инфраструктуру, в которой будет развернуто наше новейшее обновление. Теперь нам нужно направить небольшой объем трафика на этот только что созданный экземпляр canary. Что ж, остальные продолжат работу со старой версией нашей модели программного обеспечения.

Анализ

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

Развертывание/откат

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

Ну, тогда какая нам выгода?

Отсутствие простоя производства

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

Экономичность — дружественность к небольшой инфраструктуре

Цель анализа Canary Release Deployment — направить небольшое количество ваших клиентов на только что созданный экземпляр canary, где развернуто новое обновление. Это означает, что вы используете немного больше своей инфраструктуры для облегчения всего процесса. В дополнение к этому, если мы сравним ее со стратегией развертывания сине-зеленой, для развертывания нового приложения требуется вся среда размещения приложений. По сравнению с сине-зеленым развертыванием нам не нужно прилагать усилий для эксплуатации и обслуживания среды, при канареечном развертывании проще включать и/или отключать любую конкретную функцию на основе любых критериев.

Место для постоянных инноваций

Гибкость тестирования новых функций с небольшим подмножеством пользователей и возможность немедленно получить опыт конечного пользователя — вот что мотивирует команду разработчиков постоянно вносить улучшения/обновления. Мы можем увеличить нагрузку на экземпляр canary до 100 % и отслеживать стабильность работы зарегистрированных функций.

Есть ли у нас какие-либо ограничения?

Ну у всего есть ограничения. Для нас важно понять, как им противодействовать.

Отнимает много времени и подвержен ошибкам

Предприятия, использующие канареечную стратегию развертывания, выполняют развертывание разрозненным образом. Затем назначается инженер DevOps для сбора данных и их анализа вручную. Это занимает довольно много времени, поскольку не масштабируется и препятствует быстрому развертыванию в процессах CI/CD. В некоторых случаях анализ может пойти не так, и мы можем откатить хорошее обновление или откатить неверное.

Локальные приложения сложно обновлять

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

Реализации могут потребовать некоторых навыков!

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

Подведение итогов

Суть «канарейки в угольной шахте» так хорошо отражена в стратегии современной стратегии развертывания — Canary Deployment Strategy. В прежние времена главной заботой было - "==спасите человеческие жизни==" к современной концепции, говорящей - "==спасите человеческие интересы==", наша жизнь сильно эволюционировал. Технология является причиной этого изменения. То, что началось с упрощения нашей жизни, теперь направлено на то, чтобы дать нам персонализированный опыт.

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

Также опубликовано здесь