Деплой - особенности и виды , сравнение достоинства и недостатки

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

деплой — процесс выкладки новой версии сайта на сервер (или сервера). Этот процесс может быть довольно сложным и сильно зависит от используемых технологий. Во время деплоя выполняются следующие задачи (ниже всего лишь один из возможных вариантов, причем довольно примитивный):

1. Код проекта скачивается на сервер (обычно через клонирование Git)
2. Ставятся все необходимые зависимости
3. Выполняется процесс сборки, например собирается фронтенд-часть
4. Выполняются миграции. Миграции — SQL-скрипты, которые изменяют структуру базы данных
5. Запускается новая версия кода

Как это ни странно, но во многих компаниях прямо сейчас весь этот процесс выполняется руками. Программист заходит на сервер, запускает git pull и далее проходится по списку выше. Это худший способ деплоить.

Деплой (deploy) -- задача развертывания приложения на новой машине/или на той же самой, но новой его версии.

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

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

Как хорошо и как плохо делать деплой

Сегодня деплой принятно производить максимально автоматизированным способом -- т.е. писать скрипты (или использовать готовые инструменты), которые автоматизируют:

• перенос кода проекта,
• его адоптацию (скажем, разворот данных бд)
• и запуск на новой машине.

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

Кроме того, деплои можно классифицировать по способу обновления и отката:

• Последовательное обновление — сервера обновляются по очереди
• Сине-Зеленый деплой — полное дублирование инфраструктуры с подменой
• При канареечный релиз (canary release) подходе переключение на использование новой версии происходит постепенно, сначала для небольшого процента пользователей, а затем и для всех.
• Recreate(Стратегия воссоздания ) : версия A прекращает работу, затем развертывается версия B.
• Ramped (также известный как скользящее обновление или инкрементное): версия B медленно развертывается и заменяет версию A.
• Синий / зеленый : версия B выпускается вместе с версией A, затем трафик переключается на версию B.
• Canary : версия B выпускается для подгруппы пользователей, после чего выполняется полное развертывание.
• A / B-тестирование : версия B выпускается для подмножества пользователей при определенных условиях.
• Теневой: версия B получает реальный трафик вместе с версией A и не влияет на ответ.

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

Более короткие и частые развертывания имеют следующие преимущества:

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

Но с увеличением частоты релизов также повышаются шансы негативно повлиять на надежность приложения или пользовательский опыт. Именно поэтому командам эксплуатации и DevOps важно строить процессы и управлять стратегиями развертывания таким образом, чтобы минимизировать риск для продукта и пользователей. (Узнать больше об автоматизации CI/CD-пайплайна можно здесь.)

В этой публикации мы обсудим различные стратегии деплоя и ихразновидности.

Стратегии деплоя

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

Rolling (постепенный, «накатываемый» деплой)

Это стандартная стратегия развертывания. Она постепенно, один за другим, заменяет pod'ы со старой версией приложения на pod'ы с новой версией — без простоя кластера.



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

Стратегия воссоздания Recreate (повторное создание)

В этом простейшем типе развертывания старые ноды убиваются все разом и заменяются новыми:

Стратегия воссоздания - это фиктивное развертывание, которое состоит из выключения версии A и развертывания версии B после выключения версии A. Об этом говорит сайт https://intellect.icu . Этот метод подразумевает простои службы, которые зависят как от завершения работы, так и от продолжительности загрузки приложения.

Плюсы:

• Легко настраивается.
• Состояние приложения полностью обновлено.

Минусы:

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

Ramped (скользящее обновление или инкрементное)

Стратегия постепенного развертывания заключается в медленном развертывании версии приложения путем замены экземпляров один за другим, пока не будут развернуты все экземпляры. Обычно это следует следующему процессу: с пулом версии A за балансировщиком нагрузки развертывается один экземпляр версии B. Когда служба готова принимать трафик, экземпляр добавляется в пул. Затем один экземпляр версии A удаляется из пула и отключается.

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

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

Плюсы:

• Легко настроить.
• Версия медленно выпускается в разных экземплярах.
• Удобно для приложений с отслеживанием состояния, которые могут выполнять перебалансировку данных.

Минусы:

• Откат / откат может занять время.
• Поддерживать несколько API сложно.
• Нет контроля над трафиком.

Синезеленый деплой Blue/Green (сине-зеленые развертывания)

Стратегия сине-зеленого развертывания отличается от поэтапного развертывания, версия B (зеленый) развертывается вместе с версией A (синий) с точно таким же количеством экземпляров. После проверки соответствия новой версии всем требованиям трафик переключается с версии A на версию B на уровне балансировщика нагрузки.

Плюсы:

• Мгновенный откат / откат.
• Избегайте проблем с версией, все состояние приложения изменяется за один раз.

Минусы:

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

Стратегия сине-зеленого развертывания (иногда ее еще называют red/black, т.е. красно-черной) предусматривает одновременное развертывание старой (зеленой) и новой (синей) версий приложения. После размещения обеих версий обычные пользователи получают доступ к зеленой, в то время как синяя доступна для QA-команды для автоматизации тестов через отдельный сервис или прямой проброс портов:

Канареечный деплой

Канареечное развертывание состоит из постепенного переноса производственного трафика с версии A на версию B. Обычно трафик разделяется по весу. Например, 90 процентов запросов относятся к версии A, 10 процентов - к версии B.

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

Канареечные выкаты похожи на сине-зеленые, но лучше управляются и используют прогрессивный поэтапный подход. К этому типу относятся несколько различных стратегий, включая «скрытые» запуски и А/В-тестирование.

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

Плюсы:

• Версия выпущена для группы пользователей.
• Удобно для мониторинга количества ошибок и производительности.
• Быстрый откат.

Против:

• Медленное развертывание.

Например, у вас может быть два различных манифеста в Git: обычный с тегом 0.1.0 и «канареечный» с тегом 0.2.0. Изменяя веса в манифесте виртуального шлюза Istio, можно управлять распределением трафика между этими двумя deployment'ами:

Канареечные развертывания с Weaveworks Flagger

Weaveworks Flagger позволяет легко и эффективно управлять канареечными выкатами.

Flagger автоматизирует работу с ними. Он использует Istio или AWS App Mesh для маршрутизации и переключения трафика, а также метрики Prometheus для анализа результатов. Кроме того, анализ канареечных развертываний можно дополнить вебхуками для проведения приемочных (acceptance) тестов, нагрузочных и любых других типов проверок.

На основе deployment'а Kubernetes и, при необходимости, горизонтального масштабирования pod'ов (HPA), Flagger создает наборы из объектов (deployment'ы Kubernetes, сервисы ClusterIP и виртуальные сервисы Istio или App Mesh) для проведения анализа и реализации канареечных развертываний:



Реализуя контур управления (control loop), Flagger постепенно переключает трафик на канареечный сервер, параллельно измеряя ключевые показатели производительности, такие как доля успешных HTTP-запросов, средняя продолжительность запроса и здоровье pod'ов. Основываясь на анализе KPI (ключевых показателей эффективности), канареечная часть либо растет, либо сворачивается, и результаты анализа публикуются в Slack. Описание и демонстрацию этого процесса можно найти в материале Progressive Delivery for App Mesh.

A / B тестирование

Развертывание A / B-тестирования состоит из маршрутизации подмножества пользователей к новой функциональности при определенных условиях. Обычно это метод принятия бизнес-решений, основанный на статистике, а не на стратегии развертывания. Однако это связано и может быть реализовано путем добавления дополнительных функций к канареечному развертыванию, поэтому мы кратко обсудим это здесь.

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

Вот список условий, которые можно использовать для распределения трафика между версиями:

• С помощью cookie браузера
• Параметры запроса
• Геолокализация
• Поддержка технологий: версия браузера, размер экрана, операционная система и т. Д.
• Язык

Плюсы:

• Несколько версий работают параллельно.
• Полный контроль над распределением трафика.

Минусы:

• Требуется интеллектуальный балансировщик нагрузки.
• Распределенная трассировка становится обязательной для трудностей с устранением ошибок для данного сеанса.

Теневой деплой

Теневое развертывание состоит из выпуска версии B вместе с версией A, входящих запросов версии A, и отправки их в версию B, не влияя на производственный трафик. Это особенно полезно для тестирования производственной нагрузки новой функции. Развертывание приложения запускается, когда стабильность и производительность соответствуют требованиям.

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

Плюсы:

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

Минусы:

• Дорого, так как требует вдвое больше ресурсов.
• Не настоящий пользовательский тест и может ввести в заблуждение.
• Сложен в настройке.
• В некоторых случаях требуется сервис mocking.

Dark (скрытые) или А/В-развертывания

Скрытое развертывание — еще одна вариация канареечной стратегии (с ней, кстати, Flagger тоже может работать). Разница между скрытым и канареечным развертыванием состоит в том, что скрытые развертывания имеют дело с фронтендом, а не с бэкендом, как канареечные.

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

С помощью переключателей функциональности (feature toggles) и других инструментов можно следить за тем, как пользователи взаимодействуют с новой функцией, увлекает ли она их или они считают новый пользовательский интерфейс запутанным, и другими типами метрик.

Flagger и A/B-развертывания

Помимо маршрутизации с учетом весов, Flagger также может направлять на канареечный сервер трафик в зависимости от параметров HTTP. При А/В-тестировании можно использовать заголовки HTTP или файлы cookie для перенаправления определенного сегмента пользователей. Это особенно эффективно в случае frontend-приложений, требующих привязки сессии к серверу (session affinity). Дополнительную информацию можно найти в документации Flagger.

Выводы

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

Стратегии «синих / зеленых» и «теневых» имеют большее влияние на бюджет, так как требуют двойного ресурсного потенциала. Если в приложении отсутствуют тесты или нет уверенности в эффективности / стабильности программного обеспечения, можно использовать канарейку, тестирование a / b или теневой выпуск. Если вашему бизнесу требуется тестирование новой функции среди определенного пула пользователей, которое можно фильтровать в зависимости от некоторых параметров, таких как геолокация, язык, операционная система или функции браузера, вы можете использовать технику тестирования a / b.

И последнее, но не менее важное: теневой выпуск сложен и требует дополнительной работы для имитации исходящего трафика, что является обязательным при вызове внешних зависимостей с изменяемыми действиями (электронная почта, банк и т. Д.). Однако этот метод может быть полезен при переходе на новую технологию баз данных и использовании теневого трафика для мониторинга производительности системы под нагрузкой.

Ниже представлена ​​диаграмма, которая поможет вам выбрать правильную стратегию:

Вау!! 😲 Ты еще не читал? Это зря!

• инфраструктура сайта
• сайт , веб-сервер ,
• CI непрерывная интеграция , непрерывная поставка ,
• CD непрерывная интеграция , непрерывная поставка ,
• Непрерывная интеграция непрерывная интеграция , непрерывная поставка ,
• непрерывная поставка непрерывная интеграция , непрерывная поставка ,
• непрерывное развертывание непрерывная интеграция , непрерывная поставка ,

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