¿Cómo actualizar automáticamente la lista de servidores ascendentes nginx cuando aws ec2 hostname cambia o aumenta?

Quiero configurar el autoescalado en AWS. No quiero usar Elastic Load Balancer.

La llamada automática en Amazon crea instancias de EC2 sin problemas durante los picos de demanda para mantener el rendimiento, y disminuye automáticamente durante las pausas de la demanda para minimizar los costos.

Dado que estas instancias EC2 se crean automáticamente, sus nombres de host son desconocidos para NGINX.

Lo sé y ya tengo una configuración ascendente en nginx a 10 instancias EC2.

Quiero poder agregar / actualizar / eliminar automáticamente nombres de servidor a mi configuración de nginx ascendente, cuando el escalado automático agrega / actualiza / elimina instancias EC2.

— Luis Lobo Borobia
fuente

Debe eliminar el "escalado automático" de su pregunta. Autoescalado es un término de AWS. Creo que lo que quiere decir es que desea escalar automáticamente (horizontalmente), agregando más nodos ascendentes a su nginx que actúan como un LB, y pregunta cómo modificar automáticamente su configuración nginx cuando se agregan / eliminan / modifican los nodos ascendentes. Si es así, edite su pregunta en consecuencia.

— talonx

bueno, en realidad, sé lo que es el autoescalado, y digo que lo diga. Quiero mezclar ambos. Actualizaré la pregunta.

— Luis Lobo Borobia

La pregunta es más clara ahora, en su intención. Quería votar para volver a abrir, pero no veo una opción, supongo que todavía no tengo suficiente representante.

— talonx

Gracias @talonx Espero que otros puedan votar para encontrar mi respuesta

— Luis Lobo Borobia

Creo que puede combinar las notificaciones de escalado automático de AWS (entregadas mediante SNS), suponiendo que devuelva el nombre de host de la instancia recién creada / terminada, y una de las API nginx de terceros para actualizar y volver a cargar su configuración nginx. Perdón por ser vago: no estoy muy familiarizado con la API de escalado automático.

— talonx

Respuestas:

Esto se puede lograr utilizando Amazon SDK (ya casi termino, lo pondré en github), utilizando el servicio SNS, EC2 y Autoscaling.

He seguido los siguientes pasos para lograr esto:

Habilite la notificación HTTP y suscribí mi servidor web.
Agregué un enlace de ciclo de vida con latido de 1 minuto (para esperar 1 minuto antes de finalizar) a mi grupo de escalado automático para finalizar el servidor
Creó un archivo de índice para analizar el mensaje y detectar qué tipo de mensaje es (es decir, Iniciar o Terminar)
Una vez que se decidió el tipo de evento, pregunté a EC2 para obtener la IP privada de la instancia
En caso de lanzamiento, espere hasta que se reciba el encabezado 200 y luego agregue la ip a la configuración nginx y vuelva a cargar
En caso de Terminar, elimine la IP de la configuración y vuelva a cargar nginx

Encuentre el script aquí https://github.com/singhupendra/aws-autoscale

— Upendra
fuente

¿Alguna posibilidad de que hayas publicado esto en github? Estoy tratando de hacer lo mismo y cualquier ayuda sería apreciada.

— Aaron

por favor, use - github.com/singhupendra/aws-autoscale

— Upendra

Gracias @talonx, he investigado un poco, Amazon Autoscale tiene una API para consultar el estado actual del grupo de escalado automático y enumera a sus miembros. Devuelve el ID de instancia ( http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/api_requests.html#query-example ), luego puede usar las herramientas de descripción para obtener el nombre del servidor ( http: // docs .aws.amazon.com / AWSEC2 / latest / CommandLineReference / ApiReference-cmd-DescribeInstances.html ) y finalmente recrea el archivo de inclusión ascendente. Pude sentir las notificaciones de Autoescalado para iniciar un proceso que realiza estas tareas.

Todavía no lo implementé, pero es un camino a seguir.

También se puede usar Autocaling con SNS http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/ASGettingNotifications.html

— Luis Lobo Borobia
fuente

Esto es básicamente lo que hice. Escribí un script de ruby que se ejecuta cada N minutos. Usando el SDK de AWS consulta a los miembros del ASG y usando una plantilla ERB genera una nueva configuración. Si la nueva configuración es diferente a la configuración actual, la copia en su lugar y le dice al demonio (haproxy en mi caso) que vuelva a cargar su configuración. Tenga en cuenta que las instancias permanecen en el ASG durante un tiempo después de su finalización, así que asegúrese de que instancia.status ==: en ejecución. También tenga en cuenta que si tarda N minutos después de que se inicie la instancia para atender solicitudes, no la use hasta ahora> instance.launch_time + N.

— Mark Wagner

Gracias @MarkWagner. ¿Hay alguna posibilidad de que puedas compartir ese script en alguna parte? Gist, github? ¡Gracias!

— Luis Lobo Borobia

¿Tuviste suerte con este script? ¿Hay un ejemplo en github o en otro lugar?

— Aaron

No, pero en este momento nginx-plus (la versión paga) permite esto más.

— Luis Lobo Borobia

Todavía no lo he implementado, pero estoy buscando usar la Reconfiguración sobre la marcha de NGiNX Plus . Estoy pensando que la AMI o la administración de la configuración (Puppet, Salt o similar) que configura una instancia de Auto Scaling Group podría llegar a la API de reconfiguración de NGiNX (tal vez, a través de un nombre de dominio interno de Route53, por lo que ninguna IP fija debe usarse) y agregarse al clúster ascendente para el proxy inverso. Después de eso, la comprobación de estado incorporada de NGiNX se haría cargo de esa instancia [agregada] y la abandonaría en caso de que no esté disponible. Esta parece ser la solución más limpia y no hay demora en agregar la instancia, y casi ninguna demora en descartarla ya que NGiNX Plus presenta un control de estado fuera de banda.

Este enfoque evita la necesidad de configurar un sistema de autodescubrimiento (Cónsul, Serf o similar) que para configuraciones más pequeñas a menudo parece una sobrecarga tanto en términos de configuración / administración como en instancias EC2 requeridas. El cónsul, por ejemplo, requiere un mínimo de tres instancias para ser estable. Quizás Serf podría ejecutarse en las instancias de ASG, pero aún queda la sobrecarga de mantenerlo, y si el ASG se reduce a una o dos instancias, perdería el quórum.

Finalmente, esto podría combinarse con una notificación automática de los cambios de Auto Scaling Group, tal vez en los servidores NGiNX que se usan para el equilibrio de carga. Un oyente activado por dicha notificación (esto puede ser a lo que Upendra también se refirió) podría agregar instantáneamente la nueva instancia a NGiNX a través de la API de modificación sobre la marcha. Además del costo de NGiNX Plus, esto hace que uno se pregunte por qué alguien usaría Elastic Load Balancer con sus numerosos problemas en primer lugar.

Editar 12.07.2015: ngx_openresty 's equilibrador-por-lua ( ver este hilo GitHub ) ofrece una otra posible solución de código abierto para hot-añadir / eliminar servidores del grupo aguas arriba Nginx. Todavía no he experimentado con esto, pero quería agregar una mención aquí para cualquiera que se encuentre con esta publicación.

— Ville
fuente