Синьо / зелені розгортання з CloudFront

Я шукаю спосіб зробити Blue / Green розгортання з CloudFront .

Хтось має гарне рішення для переходу від одного дистрибутива CloudFront до іншого чи все справді просто створює свій дистрибутив, а потім ніколи не торкається його знову?

Мій розподіл CloudFront складається з одного джерела S3 для статичного вмісту (javascript тощо) та спеціального джерела, що вказує на AWS ELB.

CloudFront не має змін

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

Дві дистрибуції CloudFront

Перший варіант, який я спробував, - це мати два окремі веб-дистрибуції CloudFront , один для мого поточного або A середовища, а інший для мого нового або B середовища. Я спробував використати зважену політику маршрутизації Route53, де я додав два записи для свого запису www.domain.com Route53, один вказує на розподіл CloudFront A масою 1, а інший вказує на розподіл CloudFront B з вагою 0. План полягає в тому, щоб змінити ваги, коли я хочу перейти від дистрибутива А до дистрибутива В. Однак, лише один розподіл CloudFront одночасно може зареєструвати альтернативні доменні імена домену (CNAME) 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, щоб вказати на інше походження, коли я хочу перейти з одного середовища в інше. Це надзвичайно безладно, тому що ці оновлення займають 15-60 хвилин, не спостерігається видимість прогресу оновлення, і залежно від характеру змін вам може знадобитися дотримуватися цього питання з Invalidation CloudFront, щоб ви не розміщували кешований вміст від старого середовища разом з новим змістом.

Дякую за вашу пораду!

Дві дистрибуції Cloudfront

Оскільки AWS дозволяє накладати між одними підстановочними альтернативними CNAME у тому самому обліковому записі AWS, ви можете перемикатися між двома розповсюдженнями хмари, таким чином:

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

Однак два різних DNS-дистрибуції (* .cloudfront.net) можуть вказувати на однакові крайові вузли, а це означає, що спосіб подання вашого вмісту - це зіставлення cloudfront.net CNAME з вузлами Edge, які його обслуговують, а потім зіставлення за ім'я хоста У цьому випадку, якщо обидва ваші дистрибутиви використовують однакові крайові вузли (це можна перевірити, наприклад, за допомогою dig), зріз не буде чистим.

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

Трохи запізнюємось у грі тут, але для тих, хто шукає цього. Я вважаю, що це можна зробити за допомогою лямбда @ краю. Аналогічно тестам 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 config config. Тоді додаток час від часу запитуватиме файл json, перевіряє версію, якщо вона застаріла, вимагає оновлення.

Обмеження

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

У цій публікації в блозі автор впроваджує тестування ab через Lambda @ Edge, працюючи над кодом у документації AWS (їх приклади можна переглянути тут: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda- example.html ).

В основному, ви робите це створення єдиного розподілу Cloudfront, що вказує на два різних джерела. Тоді ви можете використовувати Lambda @ Edge для спрямування трафіку на будь-яке походження (за допомогою файлів cookie), і, звичайно, ви можете реалізувати інші речі за допомогою Lambda, такі як зважування трафіку або гортання тощо. Також легко додати подальші джерела та логіку .