Despliegue en instancias EC2 detrás de un equilibrador de carga; PHPStorm + GitHub

Sé que esto ha sido parcialmente respondido en un montón de lugares, pero las respuestas son tan … todo el map, anticuado y no bien explicado. Estoy buscando las mejores prácticas a partir de febrero de 2016.

La puesta en marcha:

Un service de aplicación RESTful basado en PHP que vive en una instancia de EC2. La instancia EC2 usa S3 para los datos de usuario cargados (files de image) y RDS MySql para su DB (estos dos puntos no son particularmente importantes).

Desarrollamos en PHPStorm, y nuestro control de fuente es GitHub. Cuando implementamos, solo utilizamos la implementación de SFTP incorporada de PHPStorm para cargar files directamente a la instancia de EC2 (tenemos una instancia para nuestro entorno de ensayo intermedio y otra para nuestro entorno de Producción). Despliegue a Escenario muy a menudo. Podría ser 20 veces al día. Simplemente hago clic en un file en PHPStorm y digo 'implementar en etapas', que hace la transferencia de SFTP. O bien, podría simplemente hacer clic en el proyecto completo y hacer clic en "implementar en etapas": ciertas carpetas y files se excluyen de la carga, que es parte de la configuration de implementación de PHPStorm.

Recientemente, puse nuestra instancia EC2 detrás de Load Balancer. Hice esto para poder aprovechar la oferta SSL gratuita de Amazon a través del Administrador de certificates, que no es compatible con instancias individuales de EC2.

Entonces, ahora mismo, hay un Load Balancer con solo una instancia de EC2 detrás. Mantengo una IP Elástica apuntando a la instancia EC2 para que pueda acceder a ella directamente (vea mi método de implementación actual más arriba).

Pregunta:

Aún no he tenido las agallas para crear instancias EC2 adicionales (clonar) detrás de Load Balancer, porque no estoy seguro de cómo debería implementarlas. Algunas ideas vinieron a la mente, pero todas son bastante hacky.

Dado el escenario anterior, ¿cuál es la mejor y más actual manera de A) implementar rápidamente una base de código en un set de instancias EC2 detrás de un Load Balancer, y B) realmente 'clonar' mi instancia EC2 actual para crear instancias adicionales.

Todavía no he podido imaginar una image clara de lo anterior en mi cabeza, a pesar de que he leído algunas sugerencias (muy técnicas).

¡Gracias!

Debe tratar su instancia de EC2 como 100% prescindible. Es decir, que se puede rescindir en cualquier momento y no debe preocuparse. Se iniciará una instancia EC2 de reemploop y se hará cargo del trabajo.

Hay 3 forms de lograr esto:

Método 1: cada implementación crea una nueva image AMI.

Cuando implementa su aplicación, la implementa en una instancia EC2 de un trabajador cuyo único propósito es la "configuration" de su aplicación. Una vez que se implementa la nueva versión, crea una nueva image AMI desde la instancia EC2 y actualiza la configuration de inicio de Auto Scaling con la nueva image AMI. Las instancias antiguas de EC2 se terminan y reemplazan con el nuevo código.

Las nuevas instancias de EC2 ya tienen el código reciente en ellas, por lo que están lists para agregarse al equilibrador de carga.

Método 2: cada implementación se realiza en un almacenamiento fuera de instancia (como Amazon S3).

Las instancias EC2 downloadán el código reciente de Amazon S3 y lo instalarán en el arranque.

Entonces, para poner el nuevo código en acción, finaliza las instancias antiguas y se lanzan nuevas para replacelas, que comienzan a usar el nuevo código.

Esto podría hacerse en una actualización de actualización o como una implementación azul / verde.

Método 3: similar al método 2, pero esta vez las instancias tienen cierta inteligencia y se pueden señalar para download e instalar el código.

De esta forma, no es necesario que finalice las instancias: se les dice a las instancias existentes que actualicen desde S3 y lo hacen por su count.

Algunas herramientas que pueden ayudar incluyen:

  • Cocinero
  • Ansible
  • CloudFormation

Actualizar:

Los methods 2 y 3 ambos comienzan con un AMI "básico" que está configurado para extraer los activos de la página web de S3. Este AMI no ha cambiado de versión a versión de su website.

Por ejemplo, AMI puede tener Apache y PHP ya instalados y en el arranque extrae los activos del website .php de S3 y los coloca en /var/www/html .

CloudFormation funciona bien para esto. Además, para el método 3, puede usar cfn-hup para esperar las señales de actualización. Cuando se lo señala, extrae los activos actualizados de S3.

Otra posibilidad es usar Elastic Beanstalk, que podría usarse para administrar todo esto por usted.

Actualizar:

Para get su image AMI de Git, intente lo siguiente:

  1. Configure una instancia de EC2 con todo lo instalado que necesita tener instalado para su aplicación web
  2. Instala Git y configura un repository local listo para Git pull .
  3. Apaga y crea una AMI de tu instancia.

Cuando implemente, haga lo siguiente:

  1. Git push a GitHub
  2. Inicie una nueva instancia EC2, basada en su image AMI.

Como parte de los Datos de usuario (especificados durante el lanzamiento de la instancia de EC2), especifique algo como lo siguiente:

 #!/bin/sh cd /git/app git pull ; copy files from repo to web folder composer install 

Cuando se hace así, los datos de usuario actúan como una secuencia de commands que se ejecutará en el primer arranque.