amazon-web-services - through - que es amazon web services

La mejor manera de administrar los cambios de código para la aplicación en Amazon EC2 con Auto Scaling

Question

Tengo varias instancias ejecutándose detrás del equilibrador de carga con Auto Scaling en AWS.

Ahora, si tengo que impulsar algunos cambios de código en estas instancias y en cualquier nueva instancia que pueda iniciarse debido a la política de escalado automático, ¿cuál es la mejor manera de hacerlo?

La única forma que conozco es crear una nueva AMI con el último código, modificar la política de autoescalado para usar esta nueva AMI y luego terminar las instancias existentes. Pero esto podría implicar un tiempo de inactividad más prolongado y no estoy seguro de que todo el proceso se pueda automatizar.

Cualquier puntero en esta dirección será muy apreciado.

Answer 1

Configuramos nuestra configuración de inicio para usar una AMI "limpia" y lista para usar, usamos estas: http://aws.amazon.com/amazon-linux-ami/

Una de las características de estas AMI es CloudInit - https://help.ubuntu.com/community/CloudInit

Esta característica nos permite entregar algunos datos a la instancia de EC2 original de vainilla creada recientemente. Específicamente, le damos a la instancia un script para ejecutar.
El script (en pocas palabras) hace lo siguiente:

1. Actualizaciones en sí (para asegurarse de que se apliquen todos los parches de seguridad y correcciones de errores)
2. Instala Git y Puppet.
3. Clones un repo de Git de Github.
4. Aplica un script de títere (que forma parte del repositorio) para configurarse a sí mismo. Puppet instala el resto de los módulos de software necesarios.

Lleva más tiempo que arrancar desde una AMI preconfigurada, pero nos saltamos el proceso de hacer estas AMI cada vez que actualizamos el software (un par de veces a la semana) y los servidores siempre están "limpios", sin parches manuales. Todos los módulos de software están actualizados, etc.

Ahora, para actualizar el software, usamos un script de boto local. La secuencia de comandos mata los servidores que ejecutan el código antiguo uno por uno. El mecanismo de Auto Scaling lanza servidores nuevos (y actualizados).

Asegúrese de usar as-terminate-instance-in-auto-scaling-group porque usar ec2-terminate-instance hará que el ELB continúe enviando tráfico a la instancia de cierre, hasta que falle la comprobación de estado.

Interesante publicación de blog relacionada: http://blog.codento.com/2012/02/hello-ec2-part-1-bootstrapping-instances-with-cloud-init-git-and-puppet/

Answer 2

La forma en que hago los cambios de código es tener un servidor maestro que edito en el código. Todos los servidores esclavos que escalan entonces rsync a través de ssh por un trabajo cron para actualizar todos los archivos. Todos los servidores se sincronizan cada 30 minutos + - unos segundos aleatorios para evitar acceder a él exactamente en el mismo segundo. (tenga en cuenta que dejé el Maestro fuera del equilibrador de carga para que los usuarios siempre tengan el mismo código que se les envía. De manera similar, cuando decido publicar mis cambios de código, hago un rsync desde mi servidor de prueba a mi servidor maestro.

Usando este enfoque, simplemente tiene que poner el comando de sincronización en el inicio y no tiene que preocuparse por el estado del código en la imagen del esclavo, ya que estará actualizado después de que se inicie.

EDITAR: hemos dejado de usar este método ahora y empezamos a usar el nuevo servicio AWS CodeDeploy que se hace para este propósito exacto:

http://aws.amazon.com/codedeploy/

Espero que esto ayude.

Answer 3

Parece que puede duplicar manualmente el tamaño del grupo de escala automática, creará instancias de EC2 utilizando AMI desde la configuración de inicio actual. Ahora, si reduce el grupo de escalado automático al tamaño anterior, las instancias antiguas se eliminarán y solo las instancias creadas a partir de una nueva AMI sobrevivirán.