1. Обзор
В этом руководстве мы опишем шесть наиболее распространенных стратегий развертывания.
2. Стратегии развертывания
Всякий раз, когда мы развертываем приложение, мы должны тщательно планировать процесс. Нам нужно учитывать различные аспекты и то, как это влияет на пользовательский опыт. Развертывание направлено на установку или обновление приложения без простоев и без нарушения работы пользователя.
Стратегия развертывания описывает процесс выполнения этих обновлений.
3. Воссоздайте стратегию развертывания
Самая основная стратегия, которую мы обсуждаем, называется стратегией развертывания «Восстановить». Как следует из названия, мы останавливаемся, а затем заново создаем приложение. Вновь созданное развертывание запускает обновленную версию приложения.
Пользователи будут испытывать некоторое время простоя, потому что нам нужно остановить приложение перед запуском новой версии. Приложение будет недоступно, пока исходная версия закрывается, а новая запускается.
С другой стороны, эту стратегию легко настроить. Нам не нужно одновременно управлять двумя разными версиями приложения. Если мы выберем этот подход, обновленное приложение сразу же будет доступно для всех пользователей. Однако у этого есть недостаток, потому что новая версия может внести ошибки в приложение, и пользователи также увидят их.
Возможно, нам даже потребуется полностью вернуться к предыдущей рабочей версии. К сожалению, откат также приводит к простоям. Чтобы отменить развертывание, нам нужно остановить обновленное приложение и воссоздать исходное.
В заключение отметим, что эта стратегия развертывания довольно проста в настройке и управлении, но мы должны учитывать ее недостатки, прежде чем использовать ее.
4. Сине-зеленое развертывание
Следующая стратегия развертывания, которую мы обсуждаем, называется развертыванием «сине-зеленый». В этом случае мы назначаем разные цвета разным версиям приложения. Отсюда и название. Исходная старая версия называется синей средой, а новая обновленная версия называется зеленой средой.
Давайте посмотрим, как работает эта стратегия. Во-первых, у нас есть синяя среда. Это существующее приложение, которое обрабатывает весь пользовательский трафик. Мы хотели бы обновить приложение без простоев. Для этого мы создаем почти идентичную среду. Однако есть разница. Новая среда будет содержать обновленную версию приложения. Теперь в обеих средах запущено наше приложение, но пользователи по-прежнему используют старую версию:
На изображении выше показано состояние, когда мы уже запустили новую версию, но пользователи все еще используют синюю среду. Следующий шаг — перейти на зеленую среду, переведя в нее весь пользовательский трафик. Это переключение может произойти очень быстро, поэтому у пользователей не будет простоев. Кроме того, они могут использовать приложение так же, как и раньше, и они не знают, что их запросы обслуживаются обновленным приложением:
Если нам нужно откатить изменения, это можно сделать немедленно, перенаправив трафик в исходную синюю среду. Когда развертывание завершено и мы не хотим откатывать назад, мы можем удалить старую синюю среду. Затем мы переименовываем обновленную версию с зеленого на синий. Следующий выпуск может следовать той же процедуре.
Мы видим, что этот процесс предпочтительнее с точки зрения времени безотказной работы и возможности отката. Однако у него есть и недостатки. У него более высокие потребности в ресурсах, потому что мы создаем две почти идентичные среды. Это может быть дорогостоящим и трудоемким для настройки. Во-вторых, у нас могут возникнуть проблемы с откатом, если в новую версию будут внесены несовместимые с предыдущими изменениями изменения. Например, изменения в базе данных.
5. Последовательное обновление
Следующая стратегия называется «Последовательное обновление». Это применимо только в том случае, если у нас есть несколько экземпляров приложения.
Изначально на всех инстансах работает старая версия, и все они могут обрабатывать запросы пользователей. Это важно здесь, потому что процесс будет удалять экземпляры, а оставшиеся должны быть в состоянии обслуживать пользователей, чтобы предотвратить простои.
Во-первых, мы создаем новый экземпляр, который запускает обновленную версию. Когда этот новый экземпляр запускается, мы считаем его частью приложения, поэтому пользовательские запросы могут быть уже обработаны им:
После этого мы удаляем один из экземпляров, на которых работает старая версия. Таким образом, у нас есть два экземпляра со старой версией и один экземпляр с обновленной версией. Это указывает на то, что мы должны иметь возможность поддерживать разные версии одновременно, если мы хотим использовать эту стратегию развертывания. В противном случае старые или новые экземпляры могут работать не так, как ожидалось.
Процесс продолжает добавлять экземпляры с новой версией и удалять их пары:
Развертывание завершается, когда последний экземпляр заменяется обновленным, и мы убедились, что приложение работает должным образом. Конечно, мы можем протестировать и во время обновления. Если мы обнаружим какие-либо проблемы, мы можем отменить все изменения.
Эта стратегия развертывания может быть параметризована в соответствии с нашими потребностями. Обычно мы можем установить, сколько экземпляров мы хотим обновлять за раз. Их может быть больше одного. Мы использовали это значение в нашем примере для простоты.
6. Канарское развертывание
Следующий метод развертывания, который мы исследуем, называется «канареечное развертывание». Основная идея заключается в том, что мы развертываем обновление для все большего числа пользователей итерациями.
Первоначально обновление получает только небольшая часть пользователей. После этого шага мы тестируем систему, чтобы убедиться, что приложение работает правильно после изменений. Таким образом, мы можем снизить риски, и даже если мы внесем в систему ошибки, их увидит только часть пользователей.
Когда мы уверены, что обновление выполнено успешно, мы можем продолжить развертывание для всех пользователей. Это также может происходить постепенно, а это означает, что обновление постепенно достигает все большего числа пользователей. Например, 25%, 50%, 75%, а затем 100%. Мы даже можем повторно протестировать систему между каждым инкрементом:
Во время тестирования мы могли заметить, что приложение работает некорректно. В этом случае нам нужно откатить изменения аналогично предыдущим примерам.
Канарские развертывания обеспечивают высокий уровень контроля, но это может быть сложно реализовать. Нам нужно убедиться, что только ограниченное количество пользователей получит обновление. По сравнению с сине-зелеными развертываниями, когда нам просто нужно было переключать трафик из одной среды в другую, это более сложная задача. С другой стороны, это дает нам больше гибкости и снижает риск.
Этот процесс не требует столько ресурсов, сколько сине-зеленое развертывание, потому что мы не дублируем среды. Однако мы сталкиваемся с той же проблемой, если новая версия приложения вносит критические изменения в базу данных.
Стратегия канареечного развертывания включает в себя еще один интересный аспект. Нам нужно выбрать целевую аудиторию, которая получает обновления в первую очередь. В идеале это целевая группа, которая будет сообщать, если обнаружит какие-либо проблемы с обновлениями. Однако мы можем выбирать пользователей на основе демографических данных, физического местоположения, типа устройства и т. д.
7. A/B-тестирование
A/B-тестирование очень похоже на канареечное развертывание. Его можно рассматривать как вариант. Этот процесс развертывает обновление для подмножества пользователей, как и канареечное развертывание. Однако A/B-тестирование в основном связано с получением отзывов пользователей о наших изменениях. Одна часть пользователей продолжает использовать «версию А» приложения, а другая часть — «версию Б»:
Наша цель — решить, хотим ли мы развернуть обновление для всех пользователей. Это может быть сложным процессом. Мы должны учитывать технические аспекты, такие как производительность приложения, но мы также можем захотеть получить отзывы от пользователей, нравятся им изменения или нет. Например, с помощью A/B-тестирования мы можем определить, будут ли пользователи чаще нажимать на кнопку, если мы заменим на ней текст.
8. Теневое развертывание
Теневое развертывание похоже на сине-зеленое развертывание в том смысле, что оно использует две идентичные среды. Одним из них является исходная производственная среда. Другой - тень.
Однако он отличается от предыдущих стратегий развертывания. Во всех предыдущих подходах запросы пользователей обслуживались обновленной средой. Когда мы используем теневое развертывание, обе среды получают запросы, но ответы исходят от исходной версии приложения:
Таким образом, у нас нет риска внесения ошибок в систему, в то время как мы можем отслеживать и тестировать новую версию под нагрузкой.
С другой стороны, наличие двух развертываний может быть дорогим и сложным в управлении. Кроме того, нам нужно убедиться, что новая версия не имеет побочных эффектов. Например, если мы обрабатываем платежи, нам нужно имитировать платежный сервис в новой среде, чтобы избежать двойного взимания платы с пользователей.
Когда мы уверены, что обновленная версия стабильна, она может заменить старую, и мы можем перенаправить на нее пользовательский трафик.
9. Заключение
В этой статье мы описали стратегии развертывания и сравнили шесть различных стратегий.
Мы должны рассмотреть множество аспектов и сравнить возможные стратегии развертывания, прежде чем выбирать, что использовать в нашей системе.