web-dev-qa-db-fra.com

Pourquoi chaque fois que Elastic Beanstalk envoie une commande à son instance, il expire toujours

J'ai une application PHP déployée sur Amazon Elastic Beanstalk. Mais je remarque un problème: chaque fois que j'applique des modifications de code via git aws.Push à l'Elastic Beanstalk, l'application déployée n'enregistre pas les modifications. J'ai vérifié le journal des événements sur mon environnement d'application Beanstalk et j'ai remarqué que chaque fois que Beanstalk rencontrait des problèmes:

Déploiement d'une nouvelle version sur une ou plusieurs instances

il est toujours suivi de:

Les instances suivantes n'ont pas répondu dans le délai imparti pour l'exécution de la commande (elles pourraient toujours finir par elles-mêmes): [i-d5xxxxx]

La même chose se produit lorsque j'essaie de demander des journaux d'instantanés. Les problèmes de haricot magique:

requestEnvironmentInfo commence

puis, après quelques minutes, il est à nouveau suivi de:

Les instances suivantes n'ont pas répondu dans le délai imparti pour l'exécution de la commande (elles pourraient toujours finir seules): [i-d5xxxxx]. 

amazon-web-serviceselastic-beanstalk
35
ardfard

J'ai eu ce problème à quelques reprises. Cela semble ne concerner que des cas particuliers. Vous pouvez donc résoudre ce problème en mettant fin à l'instance EC2 (via la page EC2 de la console de gestion). Par la suite, Elastic Beanstalk détectera qu'il y a 0 instance en bon état et en lancera automatiquement une nouvelle.

S'il s'agit d'un environnement de production et que vous ne disposez que d'une instance et que vous souhaitez un temps d'indisponibilité minimal

  1. configurez un minimum d'instances à 2 et Beanstalk lancera une autre instance pour vous.
  2. mettre fin à l'instance problématique via l'onglet EC2, Beanstalk lancera une autre instance pour vous car l'instance minimale est de 2
  3. si vous configurez l’instance minimale à 1, Beanstalk supprimera l’une de vos deux instances.
39
chongzixin

Par défaut, Elastic Beanstalk "lève une exception de délai d'attente" après 8 minutes (480 secondes définies dans les paramètres) si vos commandes ne se sont pas terminées dans le temps imparti . Vous pouvez définir un délai supérieur, jusqu'à 30 minutes (1800 secondes).

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

Lire ici: http://docs.aws.Amazon.com/elasticbeanstalk/latest/dg/command-options.html

5
daveoncode

Avait le même problème ici (unique instance t1.micro). 

Le problème a-t-il été résolu en redémarrant l'instance EC2 via la page EC2 de la console de gestion (et non depuis la page EB)?.

1
mirzik

Le déploiement Beanstalk (et d'autres fonctionnalités telles que Get Logs) fonctionne en envoyant des commandes SQS aux instances. Le client SQS est déployé sur les instances et vérifie la file d'attente environ toutes les 20 secondes (voir /var/log/cfn-hup.log):2018-05-30 10: 42: 38,605 [DEBUG] Réception de messages pour la file d'attente https : //sqs.us-east-2.amazonaws.com/124386531466/93b60687a33e19 ...

Si SQS Client se bloque ou a des problèmes de réseau sur les instances t1/t2, il ne pourra pas recevoir de commandes de Beanstalk et le déploiement expirerait. Le redémarrage de l'instance redémarre le client SQS et celui-ci peut à nouveau recevoir des commandes. 

Un moyen plus simple de réparer le client SQS consiste à redémarrer le service cfn-hup:

Sudo service cfn-hup restart
1
Victor Gavrilenko

Dans le cas du déploiement, une alternative à la fermeture des instances EC2 et à l'attente de la réaction d'Elastic Beanstalk, ou au désordre avec des instances minimum et maximum, consiste simplement à effectuer un Reconstruire environnement sur l'environnement cible.

Si un déploiement précédent échouait à cause de l'expiration du délai, la nouvelle version serait toujours enregistrée dans l'environnement, mais en raison de l'expiration du délai, elle ne semblerait pas être opérationnelle (d'après mon expérience, l'instance semble toujours exécuter l'ancienne version).

La reconstruction de l'environnement semble réinitialiser les choses avec la nouvelle version utilisée.

De toute évidence, il y a l'inconvénient d'une période d'indisponibilité.

0
Dan Gravell

Je pense que la manière correcte de traiter cela ..___ Je pense que la bonne façon de traiter ceci est de déterminer la cause du délai d'attente en faisant ce que { cette réponse suggère } _.

_ { la réponse de chongzixin } _ est ce qui doit être fait si vous avez besoin de cette résolution immédiate avant de rechercher la raison d'un délai d'attente.

Cependant, si vous do devez augmenter le délai d’expiration, reportez-vous aux sections suivantes:

Ajoutez des fichiers de configuration à votre code source dans un dossier nommé .ebextensions et déployez-le dans votre ensemble de sources d'application.

Exemple:

option_settings:
  "aws:elasticbeanstalk:command":
    Timeout: 2400

* "valeur" représente le délai avant l'expiration du délai, en secondes.

Référence: https://serverfault.com/a/747800/496353

0
Pranay Majmundar

"Redémarrer le ou les serveurs d'applications" dans le menu "Actions" du tableau de bord de gestion Elastic Beanstalk suivi de eb deploy le corrige pour moi.

Indication visuelle de la première instruction

0
Anuj Verma