Page AWS ELB «Désolé, le site est en panne»

J'ai un site ELB v2 basique. Pas de clustering ou quoi que ce soit encore. Je suis assez inexpérimenté avec AWS.

Ma pile est nginx / uwsgi / django + quelques autres services.

Je me demandais si quelqu'un avait pensé à faire une page de style "désolé, le site Web est actuellement en panne ..." (le texte personnalisé que je peux mettre à jour le temps d'arrêt prévu est un bonus!) Chaque fois qu'il y a un temps d'arrêt pour une raison quelconque, et la santé de l'instance est rouge. Il ne semble pas qu'Amazon offre cette capacité - me manque-t-il quelque chose? Existe-t-il un moyen de créer une instance super minuscule distincte qui est UNIQUEMENT servie si la principale est rouge ou quelque chose?

Merci!

La solution simple et cool ici est de mettre votre ELB derrière CloudFront.

Si le serveur d'origine (l'ELB dans ce cas) génère une erreur 5XX (ou 4XX si vous le souhaitez), CloudFront peut renvoyer une page d'erreur personnalisée , que vous pouvez configurer CloudFront pour extraire d'un compartiment S3 en créant une deuxième origine pointant vers le et créer un routage de comportement de cache (par exemple) /errors/static/*vers le compartiment.

Cela fonctionne mieux que le basculement Route 53 pour une raison importante ... une faille fatale, si vous voulez ... les navigateurs sont terribles à propos de la mise en cache des recherches DNS pendant beaucoup plus longtemps que prévu. Le DNS TTL n'est pas pertinent.

Essentiellement, une fois qu'un navigateur a une entrée DNS en main, il continue d'essayer de l'utiliser ... généralement, jusqu'à ce que toutes les fenêtres du navigateur soient fermées.

Donc, si votre site tombe en panne pour un visiteur qui était déjà sur le site, il est peu probable qu'il voit le site alternatif.

Pire encore, si un visiteur accède à votre site pour la première fois alors qu'il est en panne, il "collera" sur la page de maintenance jusqu'à ce qu'il ferme toutes les fenêtres du navigateur.

Si vous utilisez le DNS de basculement, ce n'est vraiment bon que si la cible de basculement est toujours votre application, peut-être juste plus loin.

Vous pouvez désactiver la mise en cache de CloudFront si vous n'en avez pas besoin.

Vous pouvez également configurer la mise en cache TTL des erreurs de CloudFront sur une valeur différente de zéro si vous souhaitez qu'il cesse de marteler votre site pendant qu'il est en panne et tente de récupérer. Pour une page donnée qui génère une erreur, il continuera d'afficher la page d'erreur et ne dérangera pas votre serveur avec plus de demandes pour cette page jusqu'à l'expiration de l'Erreur CachingTTL.

Utilisez DNS Route53 et le routage de basculement . Vous devriez pouvoir obtenir un compartiment S3 hébergeant un site Web statique d'une seule page. Je ne pense pas que vous puissiez le faire avec juste ELB.

Amazon a un article de blog qui vous explique comment le faire ici .

Mise à jour: comme Michael le dit, il y a un inconvénient à la mise en cache DNS du navigateur, voir sa réponse pour plus d'informations. Route 53 est probablement une option plus simple que CloudFront, mais CF a d'autres avantages, performances et dans certains cas d'utilisation peut réduire les coûts.

Plusieurs solutions ont déjà été mentionnées, notamment CloudFront et Route53. CloudFront est une excellente solution et, selon mon expérience, n'a pas du tout ralenti les choses, mais cela entraîne des coûts supplémentaires. Et Route53 a les problèmes de mise en cache DNS déjà mentionnés.

Jusqu'à ce qu'ALB prenne en charge les pages d'erreur personnalisées (ce qui peut ou non se produire), il existe potentiellement une nouvelle solution après l' annonce récente des réponses fixes d'ALB , mais ce n'est pas pointer et cliquer: vous pouvez configurer une fonction Lambda qui ajoute temporairement une règle à votre équilibreur de charge, fournissant une réponse fixe avec le contenu de votre «page d'erreur».

Outre l'écriture de la Lambda, vous devrez trouver un moyen de le déclencher `` on '' et `` off '', ce qui pourrait éventuellement se faire via un bilan de santé Route53 ou un bilan de santé du groupe cible de l'équilibreur de charge (probablement via l'alarme CloudWatch -> SNS - > Lambda).

Ce n'est pas exactement simple, mais cela fonctionnerait probablement bien une fois installé!

Comme écrit par @Tim et @Micheal, vous avez le choix d'utiliser DNS Route53 et le routage de basculement , ou CloudFront avec des pages d'erreur personnalisées . Les deux méthodes ont leurs avantages et leurs inconvénients.

Si vous n'utilisez pas déjà Cloudfront, je pense que Route53 est une solution plus simple. Voir le blog mis à jour d'AWS (qui comprend désormais une méthode plus simple pour l'intégration ELB).

CloudFront est beaucoup plus compliqué à configurer et cela prendra environ 15 minutes pour chaque mise à jour. Cloudfront met également en cache (comme prévu), il n'est donc pas clair si cela sera plus lent à répondre que les problèmes de cache DNS avec Route 53.

Notez que si votre site Web ELB ne répond qu'à SSL, vous ne pouvez pas utiliser la solution S3 simple comme décrit dans le blog AWS 3 . Dans ce cas, vous devrez ajouter Cloudfront devant le compartiment S3 pour ajouter le SSL, ce qui complique la solution de routage des échecs DNS.