Déploiements bleu / vert avec CloudFront

16

Je cherche un moyen de faire des déploiements Blue / Green avec CloudFront .

Quelqu'un a-t-il une bonne solution pour passer d'une distribution CloudFront à une autre ou tout le monde crée-t-il vraiment sa distribution et ne la touche plus jamais?

Ma distribution CloudFront se compose d'une origine S3 pour le contenu statique (javascript, etc.) et d'une origine personnalisée pointant vers un ELB AWS.

Aucune modification de CloudFront

Dans des circonstances normales, nous n'apportons aucune modification à notre distribution CloudFront. Nous mettons à jour notre contenu statique dans l'origine S3 en modifiant le nom des fichiers de contenu statique dans S3 et effectuons des déploiements roulants vers des instances EC2 sous Elastic Load Balancer (ELB). Cependant, il y a des moments où nous devons tester et apporter des modifications à la distribution CloudFront elle-même ou apporter des modifications suffisamment importantes à notre environnement pour que nous devons pointer vers un nouvel ELB dans un nouvel environnement.

Deux distributions CloudFront

La première option que j'ai tentée était d'avoir deux distributions Web CloudFront distinctes , une pour mon environnement actuel, ou A, et une pour mon nouvel environnement, ou B,. J'ai tenté d'utiliser une stratégie de routage pondérée Route53 où j'ai ajouté deux enregistrements pour mon enregistrement Route53 www.domain.com, l'un pointant vers CloudFront Distribution A avec un poids de 1 et l'autre pointant vers CloudFront Distribution B avec un poids de 0. Le le plan serait de changer les pondérations lorsque je souhaite passer de la distribution A à la distribution B. Cependant, une seule distribution CloudFront à la fois peut avoir les noms de domaine alternatifs (CNAME) www.domain.com enregistrés ou vous obtenez l'erreur suivante:

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)

Une distribution CloudFront

La deuxième option consiste à conserver une distribution Web CloudFront. J'ai des origines S3 et personnalisées pointant vers mes environnements A et B, puis je mets à jour le comportement du cache CloudFront pour pointer vers l'autre origine lorsque je veux passer d'un environnement à un autre. Ceci est extrêmement compliqué car ces mises à jour prennent 15 à 60 minutes, il n'y a pas de visibilité sur la progression de la mise à jour et selon la nature de votre changement, vous devrez peut-être suivre cela avec une invalidation CloudFront afin de ne pas servir de contenu mis en cache de l'ancien environnement avec un nouveau contenu.

Merci pour vos conseils!

deployment amazon-cloudfront Peter M
la source
Avez-vous trouvé une solution? Nous avons le même problème dans notre projet et la façon dont nous le faisons maintenant - nous modifions manuellement le point de terminaison cloudfront dans notre projet.
Dmytriy Voloshyn
1
malheureusement non - je ne pense pas qu'il y en ait un bon. La meilleure pratique consiste à utiliser une distribution cloudfront, à versionner tout contenu dans des compartiments s3 et à utiliser des enregistrements DNS pondérés route53 pour les origines pointant vers du contenu dynamique. il vous suffit de mettre à jour route53 pour modifier le contenu dynamique et vous n'avez pas besoin de toucher cloudfront. Nous maintenons une distribution cloudfront distincte pour les dev et les qa. EX: stackoverflow.com/questions/9130555/…
Peter M

Réponses:

9

Deux distributions Cloudfront

Étant donné qu'AWS permet le chevauchement entre des CNAME alternatifs génériques dans le même compte AWS, vous pouvez basculer entre deux distributions cloudfront de la manière suivante:

  • Utilisez www.domain.com comme CNAME alternatif pour la distribution Prod 1
  • Utilisez * .domain.com comme CNAME alternatif pour la distribution Prod 2
  • Pointez votre DNS CNAME www.domain.com vers la distribution 1 ou la distribution 2. (* .cloudfront.net).
  • Supprimez le CNAME alternatif de la distribution dont vous ne souhaitez plus diffuser le contenu.

Cependant, les deux DNS de distribution différents (* .cloudfront.net) peuvent pointer vers les mêmes nœuds périphériques, ce qui signifie que la façon dont votre contenu est servi consiste à faire correspondre le CNAME cloudfront.net aux nœuds Edge qui le desservent, puis à faire correspondre par nom d'hôte. Dans ce cas, si vos deux distributions utilisent les mêmes nœuds de bord (cela peut être vérifié par exemple avec dig) la coupe ne sera pas nette.

Par exemple, si les deux distributions partagent un ou plusieurs nœuds périphériques, la distribution 1 avec Alt CNAME www.domain.com aura priorité sur la distribution 2 avec le plus générique * .domain.com jusqu'à ce que le CNAME soit supprimé de la configuration de la distribution 1 dans tous les nœuds périphériques. . La version récupérée d'une requête peut donc être différente de l'autre pendant la période de transition.

mpaf
la source
En raison du temps de prolifération des modifications prolongé dans CloudFront, c'est vraiment votre seule option.
CloudWalker
Merci - c'est une réponse extrêmement intéressante. Je n'ai jamais pensé à le faire de cette façon. Je vais le marquer comme correct car il passe d'une distribution à l'autre, cependant, je dois éviter le temps de prolifération prolongé et le risque de servir le mauvais contenu pendant la transition, donc je ne peux pas l'utiliser dans mon cas . Je suis d'accord avec @CloudWalker qu'il n'y a pas d'autre option.
Peter M
3

Un peu tard dans le jeu ici, mais pour tous ceux qui le recherchent. Je pense que cela peut être fait en utilisant lambda @ edge. Similaire aux tests A / B. https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html . Vous pouvez implémenter une fonction lambda déclenchée lorsqu'un utilisateur demande une URL. Choisissez de diffuser le contenu bleu / vert de différentes origines ou préfixe d'URL. Une valeur de cookie déterminera quel déploiement sera servi. Lorsque la première demande arrive (pas de cookie), réglez le cookie au hasard, dites 95% bleu 5% vert.

Gary H
la source
1

Prise de vue depuis la hanche, combien de temps faut-il pour changer l'origine dans une distribution de front de nuage? 1) déployez le nouveau code derrière ELB, réchauffez-le 2) ajoutez cet ELB en tant que nouvelle origine à votre distribution frontale cloud tout en supprimant l'ancienne origine 3) une fois basculé, détruisez l'ancien code derrière l'ancien ELB.

Pour éviter les retards associés aux mises à jour CloudFront ou aux mises à jour DNS, vous pouvez échanger le groupe de mise à l'échelle automatique derrière votre ELB. 1) déployez le nouveau code dans le nouvel ASG, réchauffez-le 2) enregistrez votre ELB existant avec ce nouvel ASG 3) désenregistrez l'ancien ASG de votre ELB 4) une fois basculé, supprimez l'ancien ASG.

Ken Krueger
la source
0

J'ai également fait des recherches sur ce sujet et j'ai une solution de rechange (voir ci-dessous).

Contexte:

CloudFront requiert que le CNAME dans la configuration de distribution soit unique sur l'ensemble de votre compte. Donc, contrôler le bleu / vert via DNS sur différentes distributions ne fonctionnera pas. Il y a un hack qui utilise des caractères génériques, mais cela ne garantit pas que les fichiers corrects sont servis. Le contrôle du bleu / vert via DNS et CloudFront n'est pas possible.

De plus, la modification de toute configuration dans CloudFront (y compris CNAME) entraîne une attente de 15 à 60 minutes pendant que les modifications sont propagées aux serveurs de périphérie. De plus, ce n'est pas une configuration idéale.

Solution de contournement:

Pour une application d'une seule page, cette configuration peut faire l'affaire:

  • URL de l'application: app.mydomain.com/app
  • Structure S3:
    • app / (votre site en direct)
    • app2 / (votre site pas si vivant)

Configurez maintenant CloudFront pour utiliser votre compartiment pour servir les fichiers. À ce stade, tout se résume à vos paramètres de cache. Étant donné que CloudFront prend une éternité, définissez l'en-tête CacheControl sur nos objets S3. Pour index.html, nous utilisons 5 minutes, tout le reste, 1 jour. Lorsque vient le temps de changer, échangez les noms de répertoire S3. Dans les 5 minutes, l'application sera opérationnelle à toutes fins utiles.

Pour les applications qui sont déjà en cours d'exécution, nous avons la version de build intégrée dans le code et un fichier json de configuration de build à la racine de l'application. Ensuite, l'application demandera occasionnellement le fichier json, vérifier la version, si elle est obsolète, demander une actualisation.

Limites

Vous ne pouvez pas très bien effectuer des tests de trempage. Je suppose qu'il est possible d'augmenter la durée de vie de index.html à quelques heures ou jours (selon vos besoins), ce qui aiderait à garantir que les clients obtiennent de nouvelles versions à mesure que leur cache local expire.

vangorra
la source
0

Dans cet article de blog, l'auteur implémente les tests ab via Lambda @ Edge en utilisant le code dans la documentation AWS (vous pouvez voir leurs exemples ici: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda- examples.html ).

Fondamentalement, vous créez une distribution Cloudfront unique pointant vers deux origines différentes. Ensuite, vous pouvez utiliser Lambda @ Edge pour diriger le trafic vers l'une ou l'autre origine (via les cookies), et bien sûr, vous pouvez implémenter d'autres choses via la Lambda telles que pondérer le trafic ou le retourner, etc. Il est également facile d'ajouter d'autres origines et une logique .

user3399551
la source