Я хочу выполнить развертывание синих зеленых на лазурном от стадии до производства.
Наше веб-приложение поддерживает длительное соединение EventSource / SSE с нашим внутренним сервером. Во время перехода от стадии подготовки к производству эти длительные соединения не должны прерываться.
Другими словами, если производственный сервер изначально является синим сервером, любые подключения к синему серверу должны продолжаться на синем сервере во время и после перевода зеленого сервера в рабочий. Новые подключения будут направлены на зеленый сервер.
Мое собственное тестирование показало, что обмен виртуального IP-адреса облачных служб Azure (классический) не работает, по крайней мере, с подключениями https. Во время обмена существующие соединения разрываются. При дальнейшем чтении Как управлять облачными сервисами, похоже, нет никакой гарантии, что существующие соединения будут поддерживаться.
Как описано в последнем разделе, замена развертывания обычно выполняется очень быстро, поскольку это всего лишь изменение конфигурации в подсистеме балансировки нагрузки Azure. Однако в некоторых случаях это может занять десять или более секунд и привести к временным сбоям подключения. Чтобы ограничить влияние на ваших клиентов, рассмотрите возможность реализации логики повторных попыток клиента.
Первая часть моего вопроса заключается в том, является ли то, что я описал выше, ожидаемым поведением свопа VIP, или он должен поддерживать существующие соединения.
Вторая часть вопроса - каков рекомендуемый способ достижения моей цели в Azure. Мне не удалось найти официальную документацию от Azure, в которой подробно описывается этот сценарий с подробностями о существующих подключениях.
Обратите внимание, я хочу избегать решений на основе DNS. Я ищу что-то дальше по сетевому стеку. Что-то похожее на использование Elastic Load Balancer на AWS для сине-зеленого развертывания, как подробно описано Вот
Кажется, что остановка слива не поддерживается в балансировщике нагрузки Azure.
В другой метод использование настраиваемой проверки работоспособности может работать, но немного беспорядочно
Фактически, метод проверки работоспособности довольно непрактичен для одновременного удаления всего кластера серверов, поэтому я придумал обходной путь.
Я попытался настроить перенаправитель https, который можно было бы легко переключать между синим и зеленым с помощью переменной среды, но это привело к тому, что для Origin для cors было установлено значение null и разрешать нулевое происхождение не рекомендуется.
В конце концов, решение, которое я выбираю, - это служба конфигурации, которая будет запрашиваться для последней конечной точки. В моей ситуации это сработает, но я вижу, что это может быть проблемой для многих реализаций.