Comment affichez-vous une page de maintenance pour AWS lorsque vos instances sont derrière un ELB?
Comment affichez-vous une page de maintenance dans AWS lorsque vous souhaitez déployer de nouvelles versions de votre application derrière un ELB? Nous souhaitons que le trafic de routage ELB se dirige vers l'instance de maintenance pendant que les nouvelles instances à mise à l'échelle automatique s'annoncent, et que nous "retournions" vers les nouvelles instances une fois qu'elles sont complètement actives. Nous utilisons la mise à l'échelle automatique pour réduire les instances existantes et les nouvelles instances contenant le nouveau code.
Le scénario que nous essayons d'éviter est que le ELB envoie le trafic vers les nouvelles instances EC2 tout en gérant la page de maintenance. Etant donné que les sessions persistantes ne sont pas activées, nous voulons empêcher l'utilisateur de basculer entre la page en mode maintenance et l'application déployée dans une instance EC2. Nous ne pouvons pas non plus simplement nous adapter (disons de 2 à 4 instances, puis de nouveau à 2) pour introduire les nouvelles instances, car les modifications de code pourraient impliquer des modifications de base de données qui rompraient les modifications apportées à l'ancien code.
Le moyen le plus simple sur AWS consiste à utiliser Route 53 , leur service DNS.
Vous pouvez utiliser la fonction Pondéré Round Robin .
"Vous pouvez utiliser WRR pour mettre des serveurs en production, effectuer des tests A/B, Ou équilibrer votre trafic dans des régions ou des centres de données de tailles différentes "
Plus d'informations dans documentations AWS sur cette fonctionnalité
EDIT: Route 53 a récemment ajouté une nouvelle fonctionnalité permettant le basculement DNS vers S3. Consultez leur documentation pour plus de détails: http://docs.aws.Amazon.com/Route53/latest/DeveloperGuide/dns-failover.html
Route53 n'est pas une bonne solution à ce problème. Il faut beaucoup de temps pour que les entrées DNS expirent avant que la page de maintenance ne s'affiche (et il faut ensuite autant de temps avant qu'elles se mettent à jour une fois la maintenance terminée). Je me rends compte que les déclencheurs Lambda et CodeDeploy n'existaient pas au moment où cette question a été posée, mais je voulais faire savoir aux autres que Lambda peut être utilisé pour créer une solution relativement propre pour cela, que j'ai détaillée dans un article de blog: http://blog.ajhodges.com/2016/04/aws-lambda-setting-temporary.html
La solution consiste à souscrire une fonction Lambda aux événements CodeDeploy, qui remplace votre ASG par une micro-instance servant une page statique dans votre équilibreur de charge lors de déploiements.
Nous avons eu une autre solution qui fonctionne très bien pour nous. Voici les étapes:
- Répliquez votre environnement EB pour en créer un autre, appelez-le par exemple
app-environment-maintenance, par exemple. - Modifiez la configuration pour la mise à l'échelle automatique et définissez les serveurs min et max sur zéro. Cela ne vous coûtera aucun serveur EC2 et l'environnement deviendra gris et restera dans votre liste.
- C'est une exigence, mais nous utilisons Cloudfront, comme beaucoup de gens le feront pour HTTPS, etc. Cloudfront a des pages d'erreur.
- Créez un nouveau compartiment d'hébergement de site Web S3 avec vos pages d'erreur. Envisagez de créer des fichiers séparés pour les codes de réponse, 503, etc. Voir le n ° 6 pour connaître les exigences en matière de répertoire et les itinéraires.
- Ajoutez le compartiment S3 à votre distribution Cloudfront.
- Ajoutez un nouveau comportement à votre distribution Cloudfront pour un itinéraire tel que
/error/*. - Configurez une page d'erreur dans Cloudfront pour gérer les codes de réponse 503 et la rediriger vers votre route de compartiment S3, telle que
/error/503-error.html. Enfin, vous pouvez utiliser l'AWS CLI pour permuter maintenant l'environnement CNAME afin de passer votre environnement principal en mode maintenance. Par exemple:
aws elasticbeanstalk swap-environment-cnames \ --profile "$awsProfile" \ --region "$awsRegion" \ --output text \ --source-environment-name api-prod \ --destination-environment-name api-prod-maintenance
Cela échangerait votre environnement app-prod en mode de maintenance. Cela ferait en sorte que l'ELB envoie un 503 puisqu'il n'y a aucune instance EC2 en cours d'exécution, puis Cloudfront interceptera le 503 et renverra votre page d'erreur 503 respective.
Et c'est tout. Je sais qu'il y a pas mal d'étapes et j'ai essayé beaucoup des options suggérées, y compris Route53, etc. Mais toutes ont des problèmes de fonctionnement avec les ELB et Cloudfront, etc.
Notez qu'après avoir échangé les noms d'hôte pour les environnements, il faut environ une minute pour se propager.
Je réalise que c'est une vieille question, mais après avoir affronté le même problème aujourd'hui (décembre 2018), il semble qu'il existe un autre moyen de résoudre ce problème.
Plus tôt cette année, AWS a pris en charge les redirections et réponses fixes à Application Load Balancers . En un mot:
- Localisez votre ELB dans la console.
- Affichez les règles pour l'auditeur approprié.
- Ajoutez une règle de réponse 503 fixe pour le nom d'hôte de votre application.
- Vous pouvez éventuellement fournir une réponse
text/plainoutext/html(c'est-à-dire votre page de maintenance HTML). - Sauvegarder les modifications.
Une fois que la règle a été transmise à l'ELB (cela m'a pris environ 30 secondes), lorsque vous essayez de visiter votre hôte dans votre navigateur, la page de maintenance 503 s'affiche.
Lorsque votre déploiement est terminé, supprimez simplement la règle que vous avez ajoutée.
Notre processus de déploiement exécute d’abord une information cloud pour créer une micro-instance ec2 (instance de maintenance) qui copie des pages statiques prédéfinies de s3 sur ec2. Cloudformation est fourni avec les elb auxquels l'instance micro ec2 est attachée. Ensuite, un script (powershell ou cli) est exécuté pour supprimer les instances Web (ec2) de l'instance de maintenance sortant d'elb.
De cette façon, nous basculons vers l'instance de maintenance pendant le processus de déploiement.
Dans notre cas, nous avons deux elb, l’un pour l’extérieur et l’autre pour l’intérieur. Notre elb interne ne sera pas mis à jour au cours de ce processus et nous procédons ainsi au test de fumée post-déploiement. Une fois le test terminé, nous exécutons un autre script pour attacher des instances Web à elb et supprimer la pile de maintenance.