Синий / Зеленый развертывания с CloudFront

Я ищу способ сделать Blue / Green развертывания с CloudFront .

У кого-нибудь есть хорошее решение для перехода с одного дистрибутива CloudFront на другой, или все действительно просто создают свой дистрибутив и никогда больше его не трогают?

Мое распределение CloudFront состоит из одного S3 происхождения для статического контента (JavaScript, и т.д.) и пользовательского происхождения указывает на AWS УДР.

Нет изменений в CloudFront

В обычных условиях мы не вносим никаких изменений в наш дистрибутив CloudFront. Мы создаем версии нашего статического содержимого в источнике S3, изменяя имя файлов статического содержимого в S3 и проводим развертывание в экземплярах EC2 в Elastic Load Balancer (ELB). Однако бывают случаи, когда нам нужно тестировать и вносить изменения в сам дистрибутив CloudFront или вносить достаточно существенные изменения в нашу среду, чтобы указывать на новый ELB в новой среде.

Два дистрибутива CloudFront

Первый вариант, который я попытался, состоял в том, чтобы иметь два отдельных веб-дистрибутива CloudFront , один для моей текущей среды или среды A, а другой для новой или среды B. Я попытался использовать политику взвешенной маршрутизации Route53, в которой я добавил две записи для моей записи Route53 на сайте www.domain.com, одну из которых указывает на CloudFront Distribution A с весом 1, а другую - на CloudFront Distribution B с весом 0. План состоит в том, чтобы изменить вес, когда я хочу перейти с дистрибутива A на дистрибутив B. Однако, только один дистрибутив CloudFront одновременно может зарегистрировать альтернативные доменные имена (CNAMEs) www.domain.com, или вы получите следующую ошибку:

com.amazonaws.services.cloudfront.model.CNAMEAlreadyExistsException: One or more of the CNAMEs you provided are already associated with a different resource. (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: ef84a5f0-44e7-11e5-9315-0ba167bb108a)

Один дистрибутив CloudFront

Второй вариант - сохранить один дистрибутив CloudFront. У меня есть S3 и пользовательские источники, указывающие на обе среды A и B, и затем я обновляю поведение CloudFront Cache, чтобы указывать на другое начало, когда я хочу перейти из одной среды в другую. Это очень грязно, потому что эти обновления занимают 15-60 минут, ход обновления не виден, и в зависимости от характера ваших изменений вам может потребоваться последующая проверка CloudFront Invalidation, чтобы вы не обслуживали кэшированный контент. из старой среды вместе с новым контентом.

Спасибо за ваш совет!

Два дистрибутива Cloudfront

Поскольку AWS позволяет перекрывать альтернативные имена CNAME в одной и той же учетной записи AWS, вы можете переключаться между двумя распределениями облачного фронта следующим образом:

• Используйте www.domain.com в качестве альтернативного CNAME для распространения Prod 1
• Используйте * .domain.com в качестве альтернативного CNAME для распространения Prod 2
• Укажите свой CNAME DNS www.domain.com на дистрибутив 1 или дистрибутив 2. (* .cloudfront.net).
• Удалите альтернативный CNAME из дистрибутива, из которого вы больше не хотите показывать контент.

Однако два разных DNS-дистрибутива (* .cloudfront.net) могут указывать на одни и те же пограничные узлы, что означает, что ваш контент обслуживается путем сопоставления CNAME cloudfront.net с пограничными узлами, которые его обслуживают, а затем с Имя хоста. В этом случае, если оба ваших дистрибутива используют одни и те же краевые узлы (это можно проверить, например, с помощью dig), разрез не будет чистым.

Например, если оба дистрибутива используют один или несколько пограничных узлов, распределение 1 с Alt CNAME www.domain.com будет иметь приоритет над распределением 2 с более общим * .domain.com, пока CNAME не будет удален из конфигурации распределения 1 во всех пограничных узлах. , Таким образом, версия, полученная из одного запроса, может отличаться от другой в течение переходного периода.

Немного поздно в игре здесь, но для всех, кто ищет это. Я считаю, что это можно сделать с помощью lambda @ edge. Аналогично тестам A / B. https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html . Вы можете реализовать лямбда-функцию, запускаемую, когда пользователь запрашивает URL. Выберите подачу сине-зеленого контента из разных источников или префикса URL. Значение cookie будет определять, какое развертывание будет обслуживаться. Когда приходит первый запрос (без cookie), установите cookie случайным образом, скажем, 95% синий, 5% зеленый.

Съемка с бедра, сколько времени потребуется, чтобы переключить источник в распределении фронта облака? 1) разверните новый код за ELB, разогрейте его 2) добавьте этот ELB в качестве нового источника в ваш дистрибутив фронта облака, удалив старый источник 3) после того, как вы перевернете старый код за старым ELB.

Чтобы избежать задержек, связанных с обновлениями CloudFront или DNS, вы можете поменять группу автомасштабирования за ELB. 1) разверните новый код в новой ASG, разогрейте его 2) зарегистрируйте существующий ELB с помощью этой новой ASG 3) отмените регистрацию старого ASG в вашем ELB 4) один раз переверните старый ASG.

Я также занимался исследованием этой темы и нашел способ ее обойти (см. Ниже).

Фон:

CloudFront требует, чтобы CNAME в конфигурации распространения был уникальным для всей вашей учетной записи. Поэтому управление синим / зеленым через DNS для разных дистрибутивов не будет работать Ходит хакерская игра, в которой используются подстановочные знаки, но это не гарантирует, что будут предоставлены правильные файлы. Управление синим / зеленым через DNS и CloudFront неосуществимо.

Кроме того, изменение любой конфигурации в CloudFront (включая CNAME) приводит к 15-60 минутному ожиданию, пока изменения распространяются на пограничные серверы. Кроме того, не идеальная настройка.

Работа вокруг:

Для одностраничного приложения эта конфигурация может помочь:

• URL приложения: app.mydomain.com/app
• S3 Структура:
  • приложение / (ваш живой сайт)
  • app2 / (ваш не очень живой сайт)

Теперь настройте CloudFront, чтобы использовать ваше ведро для обслуживания файлов. На данный момент все сводится к настройкам кеша. Поскольку CloudFront работает вечно, установите заголовок CacheControl на наших объектах S3. Для index.html мы используем 5 минут, все остальное 1 день. Когда придет время переключаться, поменяйте местами имена каталогов S3. В течение 5 минут приложение будет доступно для любых целей и задач.

Для приложений, которые уже запущены, у нас есть встроенная в код версия сборки и файл json конфигурации сборки в корне приложения. Затем приложение время от времени запрашивает файл json, проверяет версию, если она устарела, запрашивает обновление.

Ограничения

Вы не можете выполнять тесты выдержки очень хорошо. Я полагаю, что можно увеличить TTL index.html до нескольких часов или дней (в зависимости от ваших потребностей), что поможет гарантировать, что клиенты получат новые версии по истечении срока действия локального кэша.

В этом сообщении в блоге автор реализует ab-тестирование через Lambda @ Edge, отработав код из документации AWS (их примеры можно посмотреть здесь: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda- examples.html ).

По сути, вы создаете один дистрибутив Cloudfront, указывающий на два разных источника. Затем вы можете использовать Lambda @ Edge, чтобы направлять трафик к любому источнику (через Cookies), и, конечно, вы можете реализовывать другие вещи с помощью Lambda, такие как взвешивание трафика или его отражение и т. Д. Также легко добавить дополнительные источники и логику ,