Canary Release и сине-зеленое развертывание на AWS

В настоящее время я внедряю Canary Release и Blue Green Deployment на моем статическом веб-сайте на AWS S3. По сути, я создал два ведра S3 (v1 и v2) и 2 облачных фронта (я не добавил CNAME). Затем я создаю 2 записи псевдонима A в Route 53 с 50% каждой политики маршрутизации веса. Однако меня перенаправляли на v1 только с помощью ноутбука и мобильного телефона для доступа к моему домену. Я даже прошу своего коллегу открыть мой домен, и они тоже перенаправляются на v1.

Меня действительно озадачило, почему ни одного пользователя не перенаправляют на v2?

Статический Интернет AWS в S3

введите описание изображения здесь


person LDC    schedule 20.12.2018    source источник


Ответы (2)


Назначенные имена хостов dyyyexample.cloudfront.net и dzzzexample.cloudfront.net, которые направляют трафик в ваши дистрибутивы CloudFront, идут в одно и то же место. CloudFront не может видеть записи вашего псевдонима DNS, поэтому он не знает, за каким псевдонимом следовал.

Вместо этого он смотрит на SNI TLS и заголовок HTTP Host, который отправляет браузер. Он использует эту информацию для сопоставления с альтернативным доменным именем для вашего распределения - без изменения DNS.

Имя хоста вашего сайта, example.com, настроено как альтернативное доменное имя только в одном из ваших дистрибутивов, потому что CloudFront не позволяет вам предоставлять одно и то же значение более чем в одном дистрибутиве.

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

Короче говоря, CloudFront напрямую и изначально не поддерживает Blue / Green или Canary.

Обходной путь - использовать триггер Lambda @ Edge и файл cookie для привязки каждого средства просмотра к тому или иному источнику. Триггер запроса источника Lambda @ Edge позволяет изменять источник во время выполнения запроса.

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

person Michael - sqlbot    schedule 20.12.2018

То, что вы объясняете, должно работать, если вы используете перекрывающиеся псевдонимы в Cloudfront. Вы настраиваете один дистрибутив на прослушивание app.example.com, а другой - на * .example.com и используете взвешенную маршрутизацию Route53 для app.example.com.

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

Как и предлагает Майкл, вы можете захотеть иметь 1 облачный фронт и маршрутизацию в сегмент A / B с помощью функций Lambda @ Edge или Cloudfront. Вот пример.

person dennis    schedule 19.06.2021