Je ne l'ai pas encore implémenté moi-même, mais je cherche à utiliser la reconfiguration à la volée de NGiNX Plus . Je pense que l'AMI, ou la gestion de la configuration (Puppet, Salt, ou autre) qui met en place une instance Auto Scaling Group, pourrait atteindre l'API de reconfiguration NGiNX (peut-être, via un nom de domaine Route53 interne afin qu'aucune IP fixe ne le fasse doivent être utilisés) et s’ajouter au cluster en amont pour le proxy inverse. Après cela, le contrôle de santé intégré de NGiNX prendrait alors le relais pour cette instance [ajoutée] et la supprimerait au cas où elle deviendrait indisponible. Cela semble la solution la plus propre et il n'y a aucun délai pour ajouter l'instance, et pratiquement aucun délai pour la supprimer, car NGiNX Plus propose un contrôle d'intégrité hors bande.
Cette approche évite d'avoir à mettre en place un système de détection automatique (Consul, Serf, ou autre) qui, pour les configurations plus petites, semble souvent être une surcharge, tant en termes de configuration / administration que d'instances EC2 requises. Consul, par exemple, nécessite un minimum de trois instances pour être stable. Serf pourrait peut-être s'exécuter sur les instances ASG elles-mêmes, mais il reste la charge de le maintenir, et si l'ASG se réduit à une ou deux instances, vous perdriez le quorum.
Enfin, cela pourrait être combiné avec une notification automatique des modifications du groupe Auto Scaling, peut-être sur le (s) serveur (s) NGiNX utilisé (s) pour l'équilibrage de charge. Un auditeur déclenché par une telle notification (c'est peut-être ce à quoi Upendra a également fait référence) pourrait alors ajouter instantanément la nouvelle instance à NGiNX via l'API de modification à la volée. Outre le coût de NGiNX Plus, cela fait que l'on se demande pourquoi quelqu'un utiliserait Elastic Load Balancer avec ses nombreux problèmes en premier lieu.
Edit 2015-12-07 : ngx_openresty 's balancer-by-lua ( voir ce fil GitHub ) offre une autre solution open source possible pour ajouter / supprimer des serveurs à chaud du groupe en amont NGiNX. Je n'ai pas encore expérimenté cela moi-même, mais je voulais ajouter une mention ici pour quiconque tombe sur ce post.