Я ищу способ развертывания синих / зеленых с помощью CloudFront.
Есть ли у кого-нибудь хорошее решение для перехода с одного дистрибутива CloudFront на другой, или все действительно просто создают свой дистрибутив и никогда больше не трогают его?
Дистрибутив My CloudFront состоит из одного S3 происхождение для статического контента (javascript и т. д.) и настраиваемого источника, указывающего на AWS ELB.
В обычных условиях мы вообще не вносим никаких изменений в наш дистрибутив CloudFront. Мы версируем наш статический контент в источнике S3, изменяя имена файлов статического контента в S3, и выполняем скользящие развертывания в экземплярах EC2 с помощью Elastic Load Balancer (ELB). Однако бывают случаи, когда нам нужно протестировать и внести изменения в сам дистрибутив CloudFront или внести достаточно существенные изменения в нашу среду, чтобы указать на новый ELB в новой среде.
Первый вариант, который я попробовал, заключался в том, чтобы иметь два отдельных CloudFront Веб-дистрибутивы, один для моей текущей, или A, среды, и один для моей новой, или B, среды. Я пытался использовать Route53 политика взвешенной маршрутизации где я добавил две записи для моей записи www.domain.com Route53, одна из которых указывает на CloudFront Distribution A с весом 1, а другая указывает на CloudFront Distribution B с весом 0. Планируется изменить веса, когда я хотите перейти с дистрибутива A на дистрибутив B. Однако только один дистрибутив CloudFront может иметь www.domain.com одновременно. Альтернативные доменные имена (CNAME) зарегистрировались или вы получите следующую ошибку:
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. У меня есть S3 и пользовательские источники, указывающие на мои среды A и B, а затем я обновляю CloudFront Поведение кеша чтобы указать на другое происхождение, когда я хочу перейти из одной среды в другую. Это очень беспорядочно, потому что эти обновления занимают 15-60 минут, ход обновления не виден, и в зависимости от характера вашего изменения вам может потребоваться следить за этим с помощью CloudFront Invalidation поэтому вы не обслуживаете кэшированный контент из старой среды вместе с новым контентом.
Спасибо за ваш совет!
Два дистрибутива Cloudfront
Поскольку AWS допускает перекрытие между альтернативными CNAME с подстановочными знаками в одной учетной записи AWS, вы можете переключаться между двумя облачными дистрибутивами следующим образом:
Однако два разных DNS-сервера распространения (* .cloudfront.net) могут указывать на одни и те же граничные узлы, что означает, что ваш контент обслуживается путем сопоставления CNAME cloudfront.net с обслуживающими его пограничными узлами, а затем сопоставления по имя хоста. В этом случае, если оба ваших дистрибутива используют одни и те же граничные узлы (это можно проверить, например, с помощью dig) разрез не будет чистым.
например Если оба дистрибутива совместно используют один или несколько граничных узлов, распределение 1 с альтернативным 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.
В это сообщение в блоге автор реализует a-b тестирование через отработку кода Lambda @ Edge из документации AWS (их примеры вы можете увидеть здесь: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html).
По сути, вы создаете единый дистрибутив Cloudfront, указывающий на два разных источника. Затем вы можете использовать Lambda @ Edge для направления трафика в любой источник (через файлы cookie), и, конечно же, вы можете реализовать другие вещи с помощью Lambda, такие как взвешивание трафика или его переворачивание и т. Д. Также легко добавить дополнительные источники и логику .
Я также занимался исследованием этой темы и нашел обходной путь (см. Ниже).
Задний план:
CloudFront требует, чтобы CNAME в конфигурации распространения был уникальным для всей вашей учетной записи. Поэтому управление синим / зеленым через DNS в разных дистрибутивах не сработает. Есть взлом, который использует подстановочные знаки, но это не дает гарантии, что обслуживаются правильные файлы. Управление синим / зеленым через DNS и CloudFront невозможно.
Кроме того, изменение любой конфигурации в CloudFront (включая CNAME) приводит к 15-60 минутам ожидания, пока изменения распространяются на пограничные серверы. Кроме того, не идеальная установка.
Обойти:
Для одностраничного приложения эта конфигурация может помочь:
Теперь настройте CloudFront на использование корзины для обслуживания файлов. На этом этапе все сводится к настройкам кеша. Поскольку CloudFront работает вечно, установите заголовок CacheControl для наших объектов S3. Для index.html мы используем 5 минут, все остальное - 1 день. Когда придет время переключаться, поменяйте местами имена каталогов S3. В течение 5 минут приложение будет доступно для любых целей.
Для приложений, которые уже запущены, у нас есть версия сборки, встроенная в код, и файл конфигурации сборки json в корне приложения. Затем приложение будет иногда запрашивать файл json, проверять версию, если она устарела, запрашивать обновление.
Ограничения
Вы не можете выполнять тесты на замачивание очень хорошо. Я полагаю, что можно увеличить TTL index.html до нескольких часов или дней (в зависимости от ваших потребностей), что поможет гарантировать, что клиенты получат новые версии по мере истечения срока их локального кеша.