Канары время: Канарские Острова, Испания — точное время

Как только canary запускается на одном сервере, несколько пользователей начинают видеть обновления.

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

По мере того, как мы становимся увереннее в Canary, мы продолжаем устанавливать его на остальные машины, пока на них не будет установлена ​​последняя версия.

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

Параллельное развертывание

Стратегия параллельного развертывания имеет много общего с сине-зеленым развертыванием. Вместо поэтапного обновления машин мы создаем полностью новую дублирующую среду и устанавливаем туда канареечную версию.

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

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

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

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

Преимущества канареечного развертывания

Зачем утруждать себя внедрением канареечной стратегии? Преимуществ много:

• A/B-тестирование : мы можем использовать canary для проведения A/B-тестирования. Другими словами, мы представляем пользователям две альтернативы и смотрим, какая из них лучше воспринимается.
• Проверка емкости : невозможно проверить емкость большой производственной среды. В канареечные развертывания встроены тесты емкости. Любые проблемы с производительностью, которые у нас есть в нашей системе, начнут возникать по мере того, как мы будем медленно переводить пользователей на канарейку.
• Обратная связь : мы получаем бесценный вклад от реальных пользователей.
• Холодный пуск запрещен : запуск новых систем может занять некоторое время. Развертывание Canary постепенно набирает обороты, чтобы предотвратить медлительность холодного запуска.
• Без простоев : как и сине-зеленые развертывания, канареечное развертывание не приводит к простоям.
• Легкий откат : если что-то пойдет не так, мы можем легко вернуться к предыдущей версии.

Первые канарейки

Идея использования канарейки в качестве системы раннего предупреждения имеет долгую историю. Задолго до того, как их использовали Google или Netflix, шахтеры брали с собой настоящих канареек, чтобы найти утечки газа. Когда эти маленькие птички, более восприимчивые к непахучим газам, чем люди, выздоровели, пришло время выбираться из шахты.

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

• Канарские выпуски : пока у нас есть способ удаленного обновления программного обеспечения, мы можем выпускать канареечные выпуски. Магазины приложений — отличный тому пример. И Google Play, и Apple App Store поддерживают поэтапное развертывание. Эта функция позволяет нам отправлять обновления волнами для определенного процента пользователей за раз.
• Катящиеся канарейки : у нас есть множество инструментов, таких как AWS CodeDeploy, Chef, Puppet или Docker, которые помогают нам выполнять последовательные обновления.
• Канарейки : облако позволяет нам создавать и демонтировать оборудование и услуги по запросу. У нас есть такие инструменты, как Terraform, Ansible или AWS CloudFormation, для определения инфраструктуры с помощью кода.
• CI/CD : когда мы добавляем непрерывную доставку и развертывание, мы получаем один из самых эффективных шаблонов для доставки кода.

Kubernetes

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

Если вы хотите узнать о Kubernetes и увидеть пошаговое канареечное развертывание в действии, загрузите нашу бесплатную электронную книгу CI/CD с Docker Kubernetes.

Планирование Canary

При планировании развертывания Canary необходимо принять во внимание несколько моментов:

• Этапы : сколько пользователей мы отправляем на Canary сначала и через сколько этапов.
• Продолжительность : как долго мы планируем запускать канарейку? Канарские развертывания обычно выполняются в течение нескольких минут или часов. Релизы Canary отличаются друг от друга, так как мы должны дождаться обновления достаточного количества клиентов, прежде чем мы сможем оценить результаты. Это может произойти в течение нескольких дней или даже недель.
• Метрики : какие метрики мы должны записывать для анализа прогресса, включая производительность приложений и отчеты об ошибках. Хорошо выбранные параметры необходимы для успешного развертывания канареек.
• Оценка : какие критерии мы будем использовать, чтобы определить успех канарейки.

Для начала мы могли бы попробовать логарифмический подход, который использует шаги 1-10-100. То есть начать с отправки 1% пользовательской базы на канарейку, чтобы убедиться в отсутствии серьезных проблем. Затем мы увеличиваем канарейку до 10%, чтобы посмотреть, как она ведет себя под нагрузкой. Наконец, мы переносим 100% пользовательской базы и завершаем процесс.

У нас может быть столько этапов, сколько нам нужно. Может быть, двух шагов 2-100 будет достаточно, а кто-то может предпочесть постепенные шаги 10-20-50-100.

Стратегии миграции пользователей

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

• Случайным образом : мы можем отправить канарейка случайно.
• По регионам : разверните канарейку по одной географической области за раз. Например, мы могли бы выбрать стратегию «следуй за ночью» и выпускать в ночное время каждого региона, когда в сети меньше всего пользователей.
• Программа раннего внедрения : предоставление пользователям возможности подписаться (или отказаться) от участия в канареечной программе может дать наилучшие результаты. Ранние последователи с большей вероятностью предоставят качественную обратную связь.
• Кормление собак : этот термин относится к поговорке «съесть корм для собственных собак» и включает в себя сначала предоставление канарейки внутренним пользователям и сотрудникам.

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

Недостатки Canary Deployment

Ничто не идеально. И канареечное развертывание не является исключением. Давайте посмотрим на обратную сторону канареечного развертывания.

• Разочарование : первая группа, использующая канарейку, обнаружит самые опасные ошибки. Более того, некоторым пользователям может быть неприятно узнать, что их использовали в качестве подопытных кроликов. Если вас это беспокоит, рассмотрите возможность запуска программы подписки (назовите ее как-то вроде «первопроходец» или «программа инсайдеров» для большей крутости).
• Затраты : стоимость параллельного развертывания выше, поскольку нам нужна дополнительная инфраструктура. Используйте облако в своих интересах; создавать и удалять ресурсы по запросу, чтобы снизить затраты.
• Сложность : канареечное развертывание имеет те же сложности, что и сине-зеленое развертывание. Наличие большого количества производственных машин, миграция пользователей и мониторинг новой системы; это сложные задачи. Избегайте любой ценой делать их вручную. Всегда автоматизируйте процесс развертывания с помощью платформы CI/CD, такой как Semaphore.
• Время : настройка работоспособного канареечного конвейера развертывания требует времени и усилий. С положительной стороны, как только мы все сделаем правильно, мы сможем выполнять более частые и безопасные развертывания.
• Базы данных : написаны целые книги о том, как вносить изменения в схему базы данных. Проблема в том, что база данных должна одновременно работать с канареечной и контрольной версиями при развертывании. Итак, если у нас есть критические изменения схемы, у нас проблемы. Нам необходимо поддерживать обратную совместимость при внесении изменений, что добавляет еще один уровень сложности.

Канарейки не для всех

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

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

Canary против Blue-Green

Мы обсуждали преимущества и недостатки сине-зеленых развертываний в предыдущем посте. Теперь, когда мы узнали о канарейках, возникает вопрос на миллион долларов: что лучше?

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

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

Канарейка, вероятно, лучший выбор, когда:

• Мы не уверены на 100% в новой версии, мы думаем, что вероятность отказа у нас от низкой до приличной.
• Нас беспокоят проблемы с производительностью или масштабированием.
• Мы делаем крупное обновление, например, добавляем блестящую новую или экспериментальную функцию.
• У нас все в порядке с медленным развертыванием.
• Наше приложение зависит от устаревшей или сторонней системы, которую мы не можем воспроизвести в тестовой среде. В этом случае тестирование возможно только на действующих производственных системах.

Заключение

Настоящее испытание приходит, когда люди начинают использовать наше программное обеспечение. Развертывание Canary позволяет нам проводить контролируемые испытания с реальными пользователями. Когда мы объединяем эту стратегию с быстрым рабочим процессом CI/CD, мы получаем продуктивный, многофункциональный цикл выпуска.

Просмотрите эти ресурсы, чтобы продолжить изучение развертываний.

• Загрузите нашу бесплатную электронную книгу: CI/CD с Docker и Kubernetes.
• Прочтите о сине-зеленых развертываниях.
• Прочтите пошаговое руководство по непрерывному развертыванию в Kubernetes.

Спасибо за внимание!

Эта статья длинная. Загрузите PDF, чтобы прочитать его позже.

Скачать

Подробное руководство по развертыванию Canary

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

Неважно, какое у вас приложение — можно применить канареечное развертывание, будь то веб-сайт, настольное приложение или мобильное приложение. Они также работают с локальными, облачными или гибридными инфраструктурами. Контейнеры? Вы держите пари. В этом посте я покажу, как выполнять канареечное развертывание с использованием Docker и Kubernetes в качестве практического примера.

Совет. Мгновенно находите ошибки приложений и проблемы с производительностью с помощью Stackify Retrace

Устранение неполадок и оптимизация кода упрощается благодаря встроенным ошибкам, журналам и анализу производительности на уровне кода.

Что такое канареечное развертывание?

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

Как это можно сравнить с разработкой и развертыванием программного обеспечения?

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

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

Как вы выполняете канареечное развертывание?

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

Балансировщики нагрузки

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

(Обратите внимание, что вы можете выполнять канареечное развертывание без балансировщиков нагрузки, но с ними проще, потому что вы можете вывести обновляемый сервер из ротации.)

Когда вы закончите обновление серверов, вы отслеживаете и тестируете какое-то время. Если вам не нравятся результаты в балансировщике нагрузки B, вы можете откатиться и завершить выпуск. Но если новые изменения подходят, вы можете приступить к обновлению серверов, которые находятся за балансировщиком нагрузки A.

Amazon Web Services (AWS)

Если вы хотите выполнить канареечное развертывание с помощью AWS, вы будете использовать их сервис под названием Route 53, который позволяет использовать взвешенные записи для разделения трафика 95/5, как мы делали раньше. Или вы можете использовать группы автоматического масштабирования, если вы не хотите возиться с DNS TTL.

Но если вас не слишком заботит такое строгое разделение, вы можете получить те же результаты, используя группы Auto Scaling (ASG). Магия ASG заключается в том, что даже если у вас более одной ASG, вам нужен только один Elastic Load Balancer (ELB), потому что вы будете подключать все ASG к одному и тому же ELB. Это уравновешивает нагрузку между ASG. Допустим, у одной ASG девять экземпляров (по три на каждую зону доступности). Второй ASG имеет только один экземпляр. Это дает вам в общей сложности десять экземпляров. Затем, если мы используем второй ASG в качестве канарейки, у вас будет 1/10 экземпляров для этой цели.

Для канареечного развертывания с помощью ASG применяется тот же метод, что и с балансировщиками нагрузки, но с небольшими изменениями. Вы обновляете ASG с помощью нового образа машины Amazon (AMI), который содержит новые изменения, и заменяете текущий экземпляр новым. Вам не нужно беспокоиться о простоях, потому что вы можете сначала запустить новый экземпляр. Как только он будет зарегистрирован в балансировщике нагрузки, вы можете сбросить соединения со старым экземпляром и завершить его.

С помощью этого метода откат выполняется так же просто, как обновление ASG с помощью предыдущего AMI и последующая ротация экземпляров. Если вы решите продолжить развертывание как есть, просто выполните ту же процедуру с другим ASG, имеющим девять экземпляров.

Kubernetes

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

У вас есть служба, которая может действовать как балансировщик нагрузки для модулей, которые «зарегистрированы» в службе. У вас также есть «развертывания», которые действуют как ASG. Так что в теории вы применяете одни и те же методы. Но вместо того, чтобы просто объяснять это, как я сделал выше, давайте учиться на практике.

Контейнеры и докеры

Теперь давайте поговорим о том, как выполнить канареечное развертывание с помощью контейнеров и Docker.

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

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

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

Базовая теория Kubernetes

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

Развертывания

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

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

Службы

Службы можно рассматривать как балансировщики нагрузки для модулей. Позвольте мне объяснить: каждый модуль имеет свой собственный IP-адрес, но если модуль создается заново или их несколько, потребителям этих модулей необходимо будет отслеживать эти IP-адреса. Вместо того, чтобы делать это вручную, вы можете использовать сервис. Службы также предоставляют IP-адрес, который могут использовать потребители, но реальная выгода заключается в том, что служба будет балансировать запросы между подами, которые находятся под ней.

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

Ярлыки и селекторы

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

Метки и селекторы — это то, как связано все, что мы только что обсудили. Когда вы определяете модули в развертывании, вы описываете набор меток, которые служба будет использовать для балансировки нагрузки. Вот как поды «регистрируются» в сервисе.

Развертывание Canary шаг за шагом

Достаточно теории; Давайте начнем. Давайте сымитируем, как будет выглядеть повседневная работа разработчика при использовании Docker и Kubernetes.

0. Предварительные условия

Прежде чем мы начнем, на вашем компьютере должно быть установлено следующее:

• Докер Край. Если вы уже установили Docker, вам необходимо удалить его, а затем установить версию Edge. Почему Эдж? Просто потому, что он включает в себя локальную установку Kubernetes, которая сделает вашу жизнь проще. Он поддерживается в Windows и Mac.
• Minikube, если вы используете Linux. Он также поддерживается в Windows, но тогда Docker необходимо установить нестандартным способом.
• kubectl является обязательным, потому что именно так вы взаимодействуете с Kubernetes с помощью командной строки. Он также поддерживается на Windows и Mac.

Если у вас есть Docker, Kubernetes и kubectl в вашей локальной среде, вы готовы приступить к работе.

1. Создайте образ Docker для приложения

Вам нужно приложение для развертывания в Kubernetes. В моем случае я буду использовать шаблон .NET Core API, но вы можете использовать и существующее приложение.

Если вы хотите использовать мой, код находится на GitHub. Вам просто нужно клонировать его в корневую папку репозитория и выполнить несколько команд, чтобы создать начальную версию образа Docker. Замените мое имя пользователя «christianhxc» своим именем пользователя.

Выполните следующую команду, чтобы создать образ Docker версии 1.0:

 docker build -f HelloWorld/Dockerfile -t christianhxc/helloworld:1.0 .
 

Затем выполните следующую команду, чтобы отправить образ Docker версии 1.0 (это необязательно, так как наш случай работает локально):

 docker push christianhxc/helloworld:1. 0
 

Вы увидите, что изображение теперь отображается в Docker Hub:

2. Разверните первую версию в Kubernetes

Теперь, когда у нас есть начальная версия приложения, мы можем развернуть ее в Kubernetes.

Начнем с создания файла определения сервиса k8s-service.yaml. Это должно выглядеть так:

 apiVersion: v1
вид: сервис
метаданные:
  имя: привет мир
спецификация:
  тип: LoadBalancer
  порты:
  - порт: 80
  селектор:
    приложение: привет мир
 

Как видно из строки 8, эта служба будет работать через порт 80. Обратите внимание, как служба будет выбирать модули в строках 9.–10. Он будет использовать метку «приложение: helloworld» в качестве селектора. Модули с этой меткой будут включены в сервис.

Теперь выполните следующую команду, чтобы создать службу. Если служба уже существует, она будет обновлена:

 kubectl apply -f k8s-service.yaml
 

Теперь пришло время создать развертывание. Давайте создадим файл определения развертывания k8s-deployment. yaml, который должен выглядеть так:

 apiVersion: apps/v1beta1.
вид: развертывание
метаданные:
  имя: привет мир
спецификация:
  реплики: 2
  стратегия:
    обновление:
    макс. всплеск: 1
    макс. недоступно: 1
  минреадисекунд: 5
  шаблон:
    метаданные:
      этикетки:
        приложение: привет мир
        трек: стабильный
    спецификация:
      контейнеры:
      - имя: привет мир
        изображение: christianhxc/helloworld:1.0
        порты:
        - контейнерПорт: 80
        Ресурсы:
          Запросы:
            процессор: 50 м
          пределы:
            процессор: 100 м
 

В этом файле определения развертывания вы видите, что в строках 15–16 есть две метки: app и track. Вот где происходит волшебство. Поды в этом развертывании будут иметь метку «app:helloworld», которую ищет служба. Служба сбалансирует нагрузку между двумя модулями (строка 6), созданными этим развертыванием.

Давайте создадим развертывание в Kubernetes, выполнив следующую команду:

 kubectl apply -f k8s-deployment. yaml
 

Вы можете проверить, что модули работают, с помощью следующей команды:

 kubectl получить стручки
 

Запустите эту команду, чтобы получить «ВНЕШНИЙ IP-адрес» службы:

 kubectl get service
 

Здесь вы получите статический IP-адрес, если вы работаете в облаке, но в этом случае мы используем локальный Kubernetes, поэтому «ВНЕШНИЙ IP-адрес» — это локальный хост.

Перейдите по адресу http://localhost/api/values, и вы увидите, что работает API версии 1.0:

3. Создайте образ Docker для второй версии приложения

Если вы решили использовать мое приложение, перейдите в файл HelloWorld/Controllers/ValuesController.cs и измените версию в первом методе, чтобы она выглядела так:

Выполните следующую команду, чтобы создать образ Docker версии 2.0. :

 docker build -f HelloWorld/Dockerfile -t christianhxc/helloworld:2.0 .
 

Затем выполните следующую команду, чтобы отправить образ Docker версии 2. 0 (опять же, это необязательно, так как наш случай работает локально):

 докер push christianhxc/helloworld:2.0
 

4. Разверните вторую версию в Kubernetes с помощью Canary

Версия 2.0 готова, но мы хотим развернуть ее безопасно.

Давайте создадим определение файла развертывания canary k8s-deployment-canary.yaml. Это должно выглядеть так:

 apiVersion: apps/v1beta1
вид: развертывание
метаданные:
  имя: helloworld-канарейка
спецификация:
  реплики: 1
  стратегия:
    обновление:
      макс. всплеск: 1
      макс. недоступно: 1
  минреадисекунд: 5
  шаблон:
    метаданные:
      этикетки:
        приложение: привет мир
        трек: канарейка
    спецификация:
      контейнеры:
      - имя: привет мир
        изображение: christianhxc/helloworld:2.0
        порты:
        - контейнерПорт: 80
        Ресурсы:
          Запросы:
            процессор: 50 м
          пределы:
            процессор: 100 м
 

В строке 6 вы можете видеть, что этот файл развертывания говорит, что он создаст только один модуль. Как мы видели в «стабильном» файле развертывания, теперь у вас есть два запущенных модуля. Это означает, что канареечная версия теперь будет получать 33 процента (1/3) всего трафика. В строке 20 определена новая версия Docker 2.0, поэтому новый модуль будет запускать версию, которую мы только что создали.

5. Некоторое время следить за второй версией

Пришло время некоторое время следить за новой версией. Вы должны иметь некоторое представление о производительности.

Если ошибок нет, вы готовы к развертыванию (см. шаг 6). Но если что-то пойдет не так (закон Мерфи, люди), переходите к шагу 7. Даже если были какие-то ошибки, вам не о чем беспокоиться, потому что только 33 процента пользователей будут затронуты ошибками. (Если вы хотите иметь более низкий процент, вам нужно добавить больше модулей в стабильную версию. Например, если стабильная версия создала девять модулей, а канареечная версия — один, это повлияет только на 10% пользователей.)

6. Разверните вторую версию до стабильной версии

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

Обновим файл k8s-deployment.yaml в строке 20, чтобы использовать образ Docker версии 2.0, который должен выглядеть так:

 ...
изображение: christianhxc/helloworld:2.0
...
 

Чтобы применить обновление, выполните следующую команду:

 kubectl apply -f k8s-deployment.yaml
 

Убедитесь, что все работает нормально. Вы должны увидеть версию 2.0, работающую для всех модулей.

7. Удалить канареечную версию

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

Выполните следующую команду, чтобы удалить канареечное развертывание:

 kubectl delete -f k8s-deployment-canary.yaml
 

8. Вернитесь к шагу 3, чтобы развернуть новую версию

Готово. Каждый раз, когда у вас есть изменение, которое вы хотите развернуть, вам нужно создать новую версию образа Docker.

Вернитесь к шагу 3 и внесите необходимые изменения, а затем выполните развертывание. Шаги 4-7 менять не нужно. Приятно то, что мы запускаем все локально, поэтому вы можете попрактиковаться в развертывании, прежде чем переходить к рабочей среде. Вы можете автоматизировать развертывание версии образа Docker. Или вы можете передать его как параметр, чтобы просто заменить новую версию заполнителем в файле развертывания.

Это не так сложно, как может показаться.

Развертывание Canary может выполняться по-разному на разных платформах. Но мне подход Docker и Kubernetes кажется более родным. И как видите, это не так сложно, как вы думаете. Выполнение этих простых и последовательных шагов поможет сделать ваше развертывание более предсказуемым. Конечно, невозможно предсказать ошибки приложения, но именно поэтому вам также необходимо иметь информацию о том, как работает приложение.

Вы не только ускорите развертывание, автоматизировав эти шаги, но и сделаете развертывание более уверенным. У вас всегда будет возможность протестировать новую версию с небольшой долей пользователей. А если что-то пойдет не так, вы легко сможете откатиться назад. Если ничего не пойдет не так, вы можете приступить к полному развертыванию. Затем вы просто закрываете канареечную версию и повторяете.

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

• Об авторе
• Последние сообщения

О Кристиане Мелендесе

• Начало работы с AWS Elastic Beanstalk .NET Core — 17 января 2020 г.