6 способов деплоя веб-приложений
Деплой — это процесс развертывания веб-приложения или сайта в рабочей среде: на гостевом хостинге или сервере. Разбираемся, какие есть способы деплоя, в чем их преимущества и недостатки, а также какой из них выбрать в разных ситуациях.
Если вы еще не знаете, что такое деплой и как его проводить, сначала прочитайте наш гайд, а потом возвращайтесь к статье.
Повторное создание
Способ, при котором разработчик сначала отключает старую версию приложения (V1 на картинке), а затем развертывает новую версию (V2 на картинке). При этом в работе приложения возникает перерыв, длительность которого зависит от скорости отключения и повторного запуска.
- Простота
- Состояние приложения полностью обновляется.
- Пользователь не может использовать сервис во время простоя, длительность которого зависит от скорости проведения работ.
Последовательное развертывание
Разработчики постепенно заменяют экземпляры текущей версии приложения на экземпляры новой версии. Процедура выглядит следующим образом: балансировщик нагрузки распределяет трафик между серверами в пуле экземпляров версии V1. Потом развертывается один экземпляр версии V2. Когда новый экземпляр готов принимать трафик (пользователей, которые заходят в приложение), его включают в пул. Затем удаляют и отключают один экземпляр версии V1.
Чтобы увеличить время развертывания, можно изменять эти максимальные значения:
- Количество экземпляров, которые развертываются одновременно
- Увеличение количества экземпляров во время деплоя
- Количество экземпляров, недоступных во время последовательного развертывания.
- Простота
- Экземпляры приложения заменяются постепенно
- Удобно перераспределять данные приложений, сохраняющих информацию о запросах.
- Развертывание и откат к предыдущей версии занимают много времени
- Сложно реализовать поддержку нескольких API
- Отсутствует контроль за трафиком.
Освойте DevOps на интенсиве Хекслета Научитесь автоматизировать окружение, деплоить приложения одной кнопкой одновременно на любое количество машин и разворачивать облачный кластер на Digital Ocean или Yandex Cloud.
Сине-зеленый деплой
Сине-зеленый деплой означает, что синяя версия V2 развертывается параллельно зеленой версии V1 с одинаковым количеством экземпляров. Убедившись, что новая версия работает исправно, разработчики перенаправляют трафик от версии V1 к версии V2 с помощью балансировщика нагрузки.
- Моментальное развертывание и откат
- Так как приложение развертывается целиком, не возникают проблемы из-за одновременного использования двух версий.
- Высокая стоимость, так как для такого деплоя требуется вдвое больше ресурсов
- Перед развертыванием нужно тщательно протестировать платформу
- Сложно работать с приложениями, сохраняющими данные о запросах.
Канареечный релиз
Канареечный релиз позволяет постепенно перенаправить трафик от версии V1 к версии V2. Обычно трафик распределяется пропорционально: например, 90% запросов отправляется версии V1, а 10% — версии V2.
Этот метод используется, если тестов не хватает, или они не дают надежные результаты. Еще он подходит, когда разработчики не уверены в стабильности новой версии.
- Версия доступна части пользователей
- Удобно отслеживать коэффициент ошибок и работу новой версии
- Быстрый откат.
- Медленное развертывание.
A/B-тестирование
Пользователи, которые отвечают заранее определенным условиям, получают доступ к новым функциям. Этот метод похож на стратегию канареечного релиза, но отличается целями. A/B-тестирование — это не только стратегия деплоя, но и способ принятия бизнес-решений на основании статистики. Часто этот способ используется, чтобы оценить эффект изменения и определить, какая версия больше нравится пользователям.
Трафик может распределяться на основании следующих условий:
- Настройки файлов cookie
- Параметры запросов
- Геолокация
- Браузер, размер экрана, ОС и другие технические характеристики
- Язык.
- Параллельная работа нескольких версий
- Полный контроль над распределением трафика.
- Требуется умный балансировщик нагрузки
- Сложно устранять проблемы для конкретного сеанса
- Требуется трассировка распределенных систем.
Скрытое развертывание
Версия V2 развертывается параллельно версии V1. Она тоже получает входящие запросы, но не влияет на реальный трафик. Так можно протестировать нагрузку новой функции. Полный переход на новую версию происходит, когда приложение работает стабильно и отвечает требованиям.
Это сложная стратегия с дополнительными требованиями, которая использует исходящий трафик. Иногда из-за этого возникают ошибки: например, если интернет-магазин проводит скрытое тестирование платежного сервиса, клиент может случайно оплатить заказ дважды. Чтобы этого избежать, придется создать сервис, который имитирует ответ поставщика услуг.
- Работа приложения проверяется на основе реального трафика
- Пользователь не теряет доступ к приложению
- Приложение развертывается только тогда, когда оно отвечает всем требованиям заказчика.
- Высокая стоимость, так как требуется вдвое больше ресурсов
- Результаты могут вводить в заблуждение, поскольку полноценный пользовательский тест не проводится
- Сложность организации
- В некоторых случаях требуется сервис для имитации услуг.
Какую из стратегий деплоя использовать
Выбор стратегии деплоя зависит от потребностей и бюджета. Например, для развертывания на этапе разработки или в промежуточной среде подходит повторное создание или последовательный деплой. Для выпуска готовой версии приложения используется последовательное или сине-зеленое развертывание, но только после проведенного тщательного тестирования.
Сине-зеленое развертывание и скрытый деплой стоят дороже, так как требуют вдвое больше ресурсов. Если тестирование не проводится в нужном объеме, или есть сомнения в отношении функционирования и стабильности приложения, подойдет канареечный релиз, A/B-тестирование или скрытое развертывание. Чтобы протестировать новую функцию на группе пользователей, можно применить фильтр, используя такие параметры, как геолокация, язык, ОС или настройки браузера. Для этого применяют A/B-тестирование.
Скрытое развертывание — сложная и трудоемкая стратегия. Если приложение работает с внешними зависимостями и отправляет выходной трафик почтовым сервисам, банкам или другим партнерам, такие действия требуется имитировать. Однако эта стратегия полезна при переходе на новую базу данных и использовании теневого трафика для мониторинга работы под нагрузкой.
Эта статья — адаптированный перевод материала разработчика Этьена Тремеля, опубликованного в блоге The New Stack.
Канареечные релизы – кто использует?
Давно хочу проект, на котором можно будет попробовать организовать канареечные релизы, но масштаб и критичность не те (масштаб маловат, а критичность систем в большинстве случаев великовата для таких экспериментов).
Кто использует – расскажите, как оно, я хоть позавидую.
P.S. Если кто-то не в курсе, то канареечный релиз – это способ безопасного тестирования нового кода в продакшене, а именно – частичный выпуск на небольшое количество пользователей с автоматическим откатом или, наоборот, увеличением количества пользователей по мере понимания, что код работает корректно.
Слово “канареечный” взято не с потолка, раньше шахтеры брали с собой канареек в клетках в угольные шахты для обнаружения повышения концентрации угарного газа. Канарейка, пока все было хорошо, постоянно пела, а при малейшей концентрации угарного газа – тут же умирала. То есть как только канарейка переставала петь – все знали, что самое время эвакуироваться. Птичек, конечно, жалко, но представляю, скольким шахтерам они так жизнь спасли.
В избранное
Информация полезна? Поддержи развитие проекта!
На кофе и новые материалы для читателей блога 🙂
Canary Releases
Метод снижения риска внедрения новой версии программного обеспечения в “производственную среду”. Происходит путем плавного развертывания изменений для небольшой группы пользователей.
Отрывок из блога Мартина Фаулера
Откуда такой термин?
Термин «канареечный релиз» придуман по аналогии с тем, как шахтеры в угольных шахтах брали с собой канареек в клетках, чтобы обнаруживать опасный уровень угарного газа. Если в шахте скапливалось много угарного газа, то он убивал канарейку до того, как становился опасным для шахтеров, и они успевали спастись.
В чем основная суть метода?
Новый функционал или его обновлённая часть публикуется для ограниченной аудитории по мере готовности на продакшен окружение. Перед деплоем достаточно убедиться, что код не содержит синтаксических ошибок. Этот шаг может быть частью ci пайплаина. Первые пользователи, которые увидят изменения, могут быть разработчиками или тестировщиками. После проверки функционала, который уже находится в той среде, где с ним начнут взаимодействовать реальные пользователи, можно открыть доступ настоящим пользователям частично или полностью. В случае нахождения ошибок фичу можно моментально закрыть от пользователей и минимизировать потери (репутационные, финансовые).
Альтернативный способ?
Использовать предпродакшен среду, на которую сначала публикуются изменения, после этапа проверки и тестирования. Изменения попадают в продакшен среду, где еще раз проверяются на ошибки связанные с интеграцией, которые могли возникнуть из за неточности двух окружений.
Какие плюсы у канареечного релиза?
- Отпадает необходимость держать лишние окружения: экономия времени разработчиков на поддержку актуального состояния тестовой среды.
- Снижение финансовых затрат на n-ое количество тестовых окружений.
- Тестирование происходит сразу на продакшен среде — выявляются ошибки интеграции, которые могут не возникать на тестовом окружении.
- Позволяет перейти на Trunk-Based Development(Patterns for Managing Source Code Branches) — подход, когда в системе контроля версий используется одна ветка, в которую сразу попадает весь написанный код. Такой подход избавляет разработчиков от затрат времени на решение больших и сложных конфликтов в коде. А так же исключает ситуацию, когда уже реализованный функционал где-то теряется 🙂
- Бонусом появляется возможность проводить A/B тесты на пользователях и находить лучшее решение, а также быстро проверять гипотезы.
- Возможность демонстрации заказчику будущих изменений сразу на продакшен окружении.
- Ранний доступ для лояльных пользователей и сбор обратной связи позволяют узнать как воспримут будущие изменения реальные пользователи.
- Если есть разные платформы (andord, ios, web) — одновременно для пользователей всех платформ предоставить доступ к новому функционалу — единовременный релиз.
- Культура децентрализованного принятия решений — принимать решения на основе продуктовых или технических метрик. Например, автоматизировать откат новой фичи в случае аномального роста нагрузки после релиза.
Какие накладные расходы для использования канареечных релизов?
- Разработчик должен гарантировать, что его код не содержит синтаксических ошибок и способен запуститься. Решается успешной компиляцией или использованием статического анализатора кода для интерпретируемых языков перед поставкой кода в продакшен среду.
- Использование готового или разработка своего механизма переключения доступа к фичам — Feature Toggles (aka Feature Flags)
Почему стоит использовать канареечные релизы?
Масштабирование, снижение количества ошибок, автоматизация ручной работы. При ускорении time to market и увеличении количества релизов ограничением становятся тестовые окружения, где в один момент времени может быть только одно изменение в тесте.
Фундаментальные проблемы нескольких предпродакшен окружений: при росте инфраструктуры и сложности приложения сложность поддержки тестовых окружений будет расти, увеличивая стоимость поддержки окружения и снижая частоту релизов. Тестовое окружение не может быть идентичным продакшен, а пользовательский трафик не может быть сопоставим.
Полезные материалы:
- Canary release — блог Мартина Фаулера
- Feature Flags, Toggles, Controls — библиотека для фичтоглинга
- Тестируем на проде: Canary Deployment
- The Facebook Mobile Release Process — видео с доклада
- Facebook — Rapid release at massive scale
- Automated Canary Analysis at Netflix with Kayenta
Deployment
При этой стратегии создается полная копия инфраструктуры (Green) для новой версии приложения, а затем постепенно перенаправляется трафик на нее, оставляя предыдущую версию (Blue) работающей параллельно. Это обеспечивает возможность быстрого отката в случае проблем и минимизирует риски простоя системы.
Одна из задач автоматизации деплоя — переход из одного состояния в другое внутри себя же, с переводом софта из финальной стадии тестирования в действующий продакшен. Обычно это нужно сделать быстро, чтобы минимизировать время простоя. При сине-зеленом подходе у вас есть два продакшена, насколько возможно идентичных. В любое время один из них, допустим синий, активен. При подготовке новой версии софта, вы делаете финальное тестирование в зелёном продакшене. Вы убеждаетесь, что программа в этом продакшене работает и настраиваете роутер так, чтобы все входящие запросы шли в зелёную операционную среду — синяя в режиме ожидания.
Сине-зелёный деплой также даёт вам возможность быстро откатиться до старого состояния: если что-то пойдет не так, переключите роутер обратно на синий продакшен. Но вам всё ещё придётся справляться с пропущенными транзакциями, пока зелёный продакшен активен, и, в зависимости от структуры кода, вы сможете направлять транзакции в оба продакшена, чтобы сохранять синий как резервную копию, при активном зелёном. Или можете перевести приложение в read-only режим, перед синхронизацией, запустить его на время в этом режиме, а потом переключить в режим read-write. Этого может оказаться достаточно, чтобы избавиться от многих нерешенных проблем.
Canary Deployment (канареечные релизы)
При этой стратегии новая версия приложения запускается на ограниченной части инфраструктуры или для небольшого числа пользователей, чтобы проверить его работоспособность и сравнить с предыдущей версией. Если новая версия проходит проверку успешно, она постепенно внедряется на остальные серверы или для всех пользователей.
Термин «канареечный релиз» придуман по аналогии с тем, как шахтеры в угольных шахтах брали с собой канареек в клетках, чтобы обнаруживать опасный уровень угарного газа. Если в шахте скапливалось много угарного газа, то он убивал канарейку до того, как становился опасным для шахтеров, и они успевали спастись.
При использовании этого шаблона, когда мы делаем выпуск, то наблюдаем, как программное обеспечение работает в каждой среде. Когда что-то кажется неправильным, мы выполняем откат, в противном случае мы выполняем развертывание в следующей среде.
Blue-Green-Canary Deployment
Это комбинированная стратегия, объединяющая элементы Green-Blue и Canary деплоя. При этом создается новая версия (Blue), которая постепенно внедряется на ограниченный набор серверов или пользователей (Canary). После проверки и удовлетворения результатами, новая версия становится основной (Green), а предыдущая версия сохраняется в качестве резервной.
Shadow Deployment (теневой)
При данной стратегии новая версия приложения запускается параллельно с текущей активной версией, но не обрабатывает реальные запросы пользователей. Вместо этого, она получает копии запросов и используется для сбора данных о производительности и стабильности новой версии без риска негативного влияния на пользователей.
Rolling Deployment (плавный деплоймент)
Эта стратегия предусматривает постепенное обновление приложения или инфраструктуры путем замены старых компонентов новыми на протяжении определенного времени или количества этапов. Это позволяет распределить нагрузку и снизить риски, так как если что-то идет не так, можно быстро вернуться к предыдущей версии.
A/B Testing (A/B тестирование)
Эта стратегия предполагает разделение пользователей на две группы: одна получает новую версию приложения (группа A), а другая продолжает использовать предыдущую версию (группа B). Это позволяет сравнить производительность, стабильность и пользовательский опыт между версиями и принять решение о полном переходе на новую версию.
Feature Toggles (фич-тоглы)
Эта стратегия позволяет включать и отключать определенные функциональные возможности приложения в зависимости от конфигурации. Таким образом, можно поэтапно вводить новые функции или экспериментировать с разными вариантами, не влияя на работу основного приложения.
Traffic Splitting (разделение трафика)
При этой стратегии трафик распределяется между несколькими версиями приложения в определенных пропорциях. Это позволяет постепенно увеличивать нагрузку на новую версию и наблюдать ее работу в реальном времени, а также сравнивать ее с предыдущей версией.
Immutable Infrastructure (неизменяемая инфраструктура)
Эта стратегия предполагает создание инфраструктуры, которая не подвергается изменениям после развертывания. Вместо этого, для обновления приложения создается новая инфраструктура с новой версией приложения, что обеспечивает простоту отката и предотвращает проблемы, связанные с изменениями в рабочей инфраструктуре.
Blue-Green-Red Deployment
Это расширенная версия Blue-Green деплоя, в которой предусмотрено наличие третьей окружения (Red), используемого для разработки и тестирования новых функций. При этом Blue и Green окружения остаются стабильными и готовыми к использованию, а Red используется для экспериментов и разработки.
Список стратегий деплоя
- Green-Blue Deployment
- Canary Deployment
- Rolling Deployment
- A/B Testing
- Blue-Green-Canary Deployment
- Shadow Deployment
- Feature Toggles
- Traffic Splitting
- Immutable Infrastructure
- Blue-Green-Red Deployment
- Rolling Updates
- Recreate Deployment
- Traffic Mirroring
- Dark Launching
- Forking
- Phased Rollout
- Ring Deployment
- Delta Deployment
- Staged Rollout
- Live Migration
- Binary Delta Deployment
- Hybrid Deployment
- Multi-Armed Bandit
- Traffic Shifting
- Zero Downtime Deployment
- Chaos Engineering
- Parallel Deployment
- Incremental Deployment
- Strangler Pattern
- Hot Patching