amazon web services - pricing - ¿Por qué cada vez que Elastic Beanstalk emite un comando a su instancia siempre se agotó el tiempo de espera?

elastic beanstalk docker

Question

Tengo una aplicación PHP implementada en Amazon Elastic Beanstalk. Pero noto un problema que cada vez que presiono mis cambios de código a través de git aws.push a Elastic Beanstalk, la aplicación implementada no detectó los cambios. Revisé el registro de eventos en mi entorno de Beanstalk de aplicación y noté que cada vez que se publicaba Beanstalk:

Despliegue de una nueva versión en instancia (s)

siempre es seguido por:

Las siguientes instancias no han respondido en el tiempo permitido de tiempo de espera del comando (aún pueden terminar por su cuenta): [i-d5xxxxx]

Lo mismo sucede cuando intento solicitar registros de instantáneas. Los problemas de Beanstalk:

requestEnvironmentInfo está comenzando

luego, después de unos minutos, es seguido de nuevo por:

Las siguientes instancias no han respondido en el tiempo permitido de tiempo de espera del comando (aún pueden terminar por su cuenta): [i-d5xxxxx].

Answer 1

De manera predeterminada, Elastic Beanstalk "arroja una excepción de tiempo de espera" después de 8 minutos (480 segundos definidos en la configuración) si sus comandos no se completaron a tiempo. Puede establecer un tiempo superior de hasta 30 minutos (1800 segundos).

{
"Namespace": "aws:elasticbeanstalk:command",
"OptionName": "Timeout",
"Value": "1800"
}

Lea aquí: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options.html

Answer 2

En el caso de implementación, una alternativa para apagar las instancias de EC2 y esperar a que Elastic Beanstalk reaccione, o meterse con instancias mínimas y máximas, es simplemente realizar un entorno de Reconstrucción en el entorno de destino.

Si una implementación anterior falló debido al tiempo de espera, entonces la nueva versión aún se registrará contra el entorno, pero debido al tiempo de espera no aparecerá operativa (en mi experiencia, la instancia parece seguir ejecutando la versión anterior).

La reconstrucción del entorno parece restablecer las cosas con la nueva versión que se usa.

Obviamente, la desventaja es la de un período de inactividad.

Answer 3

La implementación de Beanstalk (y otras características como Get Logs) funcionan al enviar comandos SQS a las instancias. El cliente SQS se implementa en las instancias y comprueba la cola cada 20 segundos (consulte /var/log/cfn-hup.log): 2018-05-30 10: 42: 38,605 [DEBUG] Recepción de mensajes para la cola https://sqs.us-east-2.amazonaws.com/124386531466/93b60687a33e19 ...

Si el cliente SQS se bloquea o tiene problemas de red en las instancias t1 / t2, no podrá recibir comandos de Beanstalk y la implementación caducará. La instancia de reinicio reinicia el cliente SQS y puede recibir comandos nuevamente.

Una manera más fácil de arreglar el cliente SQS es reiniciar el servicio cfn-hup:

sudo service cfn-hup restart

Answer 4

Tenía el mismo problema aquí (instancia única t1.micro).

Resolvió el problema reiniciando la instancia EC2 a través de la página EC2 en Management Console (y no desde la página EB).

Answer 5

Tuve este problema algunas veces. Parece afectar solo a casos particulares. Por lo tanto, se puede resolver cancelando la instancia EC2 (realizada a través de la página EC2 en Management Console). A partir de entonces, Elastic Beanstalk detectará que hay 0 instancias saludables y lanzará automáticamente una nueva.

Si este es un entorno de producción y solo tiene 1 instancia y desea un tiempo de inactividad mínimo

1. configure las instancias mínimas en 2, y Beanstalk iniciará otra instancia por usted.
2. finalice la instancia problemática a través de la pestaña EC2, Beanstalk lanzará otra instancia para usted porque la instancia mínima es 2
3. configure la instancia mínima en 1, Beanstalk eliminará una de sus dos instancias.