Сине-зеленое развертывание( blue/green deployment ) - существует две параллельные инфраструктуры (в которых находятся и базы данных и кластеры сервисов, и вообще все тоже самое), когда происходит развертывание новой версии продукта, то это делается на не подключенной инфраструктуре, проводятся тесты и потом просто переключается уравновешиватель нагрузки. Если что пойдет не так, уравновешиватель просто переключает продукт на старую инфраструктуру, то есть предыдущую версию. Перед заливкой на продакшин, отключенная инфраструктура превращается в стейджинг среду и там происходит вся магия.
Проблемы такого подхода:
- синхронизация баз данных/сервисов в которых сохраняется состояние;
- вырастает в два раза цена инфраструктуры прода - ее нужно продублировать.
Выкатывающиеся развертывание( rolling deployment ) - в этом случае у продакшина одна инфраструктура, выкатывание происходит на минимальное количество учасников кластеров (продукт состоит из нескольких/многих сервисов, каждый из которых для отказоустойчивости - это кластер контейнеров/серверов(обычно 3)). Постепенное выкатывание обеспечивает отсутсвие даунтайма, тестирование происходит на обновленных нодах, при этом можно тестировать и живыми пользователями. Когда что-то идет не так, то обновленные ноды просто ложат, и инфраструктура работает на старых версиях сервисов.
Проблемы такого подхода:
- нужно обеспечить, чтобы обновленные схемы баз данных были подходящими и для старых и для новых версий сервисов - такое развертывание нужно сначала тестировать на стейджинге;
- сессии у сервисов с состояниями будут разрываться при переброске балансером между новой и старой версией, или их данные будут различаться, и даже у сервисов без состояний поведение будет "странненьким" -- это в случае, если мы развертываем приложение без отключения обновленных контейнеров от внешнего мира, если же отключаем и только наши тестировщики их пользуют, то есть риски влиять через базы на работу других сервисов со старой версией.
Проблемы такого подхода:
- синхронизация баз данных/сервисов в которых сохраняется состояние;
- вырастает в два раза цена инфраструктуры прода - ее нужно продублировать.
Выкатывающиеся развертывание( rolling deployment ) - в этом случае у продакшина одна инфраструктура, выкатывание происходит на минимальное количество учасников кластеров (продукт состоит из нескольких/многих сервисов, каждый из которых для отказоустойчивости - это кластер контейнеров/серверов(обычно 3)). Постепенное выкатывание обеспечивает отсутсвие даунтайма, тестирование происходит на обновленных нодах, при этом можно тестировать и живыми пользователями. Когда что-то идет не так, то обновленные ноды просто ложат, и инфраструктура работает на старых версиях сервисов.
Проблемы такого подхода:
- нужно обеспечить, чтобы обновленные схемы баз данных были подходящими и для старых и для новых версий сервисов - такое развертывание нужно сначала тестировать на стейджинге;
- сессии у сервисов с состояниями будут разрываться при переброске балансером между новой и старой версией, или их данные будут различаться, и даже у сервисов без состояний поведение будет "странненьким" -- это в случае, если мы развертываем приложение без отключения обновленных контейнеров от внешнего мира, если же отключаем и только наши тестировщики их пользуют, то есть риски влиять через базы на работу других сервисов со старой версией.
Комментариев нет:
Отправить комментарий