Utiliser des hooks de cycle de vie avec un groupe d'instances pré-initialisées - Amazon EC2 Auto Scaling
Transitions de l'état du cycle de vieCibles de notification prises en charge

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utiliser des hooks de cycle de vie avec un groupe d'instances pré-initialisées

Les instances du groupe d'instances pré-initialisées gèrent leur propre cycle de vie indépendant, ce qui vous permet de créer l'action personnalisée appropriée pour chaque transition. Ce cycle de vie est conçu pour vous aider à appeler des actions dans un service cible (par exemple, une fonction Lambda) pendant qu'une instance est encore en cours d'initialisation et avant qu'elle ne soit mise en service.

Note

Les opérations d'API que vous utilisez pour ajouter et gérer des hooks de cycle de vie et des actions de cycle de vie complètes ne sont pas modifiées. Seul le cycle de vie de l'instance est modifié.

Pour plus d'informations sur l'ajout d'un hook de cycle de vie, consultez Ajouter des hooks de cycle de vie. Pour plus d'informations sur l'exécution d'une action de cycle de vie, consultez Effectuer une action de cycle de vie.

Pour les instances entrant dans le groupe d'instances pré-initialisées, vous aurez peut-être besoin d'un hook de cycle de vie pour l'une des raisons suivantes :

  • Vous souhaitez lancer des instances EC2 à partir d'une AMI dont l'initialisation est très longue.

  • Vous souhaitez exécuter des scripts de données utilisateur pour l'amorçage des instances EC2.

Pour les instances quittant le groupe d'instances pré-initialisées, vous aurez peut-être besoin d'un hook de cycle de vie pour l'une des raisons suivantes :

  • Vous pouvez utiliser un peu plus de temps pour préparer les instances EC2 à utiliser. Par exemple, certains de vos services pourraient devoir démarrer lorsqu'une instance redémarre pour que votre application puisse fonctionner correctement.

  • Vous souhaitez pré-remplir les données du cache pour vous assurer qu'un nouveau serveur n'est pas lancé avec un cache vide.

  • Vous souhaitez enregistrer de nouvelles instances en tant qu'instances gérées auprès de votre service de gestion de la configuration.

Transitions de l'état du cycle de vie pour les instances dans un groupe d'instances pré-initialisées

Une instance Auto Scaling peut passer par plusieurs états dans le cadre de son cycle de vie.

Le schéma suivant montre la transition entre les états Auto Scaling lorsque vous utilisez un groupe d'instances pré-initialisées :

Transitions de l'état du cycle de vie pour les instances dans un groupe d'instances pré-initialisées.

¹ Cet état varie en fonction du paramètre d'état du groupe d'instances pré-initialisées. Si l'état du groupe est défini sur Running, alors cet état est à la place Warmed:Running. Si l'état du groupe est défini sur Hibernated, alors cet état est à la place Warmed:Hibernated.

Lorsque vous ajoutez des hooks de cycle de vie, tenez compte des éléments suivants :

  • Lorsqu'un hook de cycle de vie est configuré pour l'action autoscaling:EC2_INSTANCE_LAUNCHING du cycle de vie, une instance nouvellement lancée s'arrête d'abord pour effectuer une action personnalisée lorsqu'elle atteint l'état Warmed:Pending:Wait, puis de nouveau lorsque l'instance redémarre et atteint l'état Pending:Wait.

  • Lorsqu'un hook de cycle de vie est configuré pour l'action EC2_INSTANCE_TERMINATING du cycle de vie, une instance en cours de résiliation s'arrête pour effectuer une action personnalisée lorsqu'elle atteint l'état Terminating:Wait. Toutefois, si vous spécifiez une politique de réutilisation des instances pour renvoyer les instances dans le groupe d'instances pré-initialisées à grande échelle au lieu de les arrêter, une instance qui y revient s'arrête pour effectuer une action personnalisée à l'état EC2_INSTANCE_TERMINATING pour l'action de cycle de vie Warmed:Pending:Wait.

  • Si la demande de votre application vide le groupe d'instances pré-initialisées, Amazon EC2 Auto Scaling peut lancer des instances directement dans le groupe Auto Scaling tant que le groupe n'atteint pas encore sa capacité maximale. Si les instances se lancent directement dans le groupe, elles ne sont mises en attente pour effectuer une action personnalisée à l'état Pending:Wait.

  • Pour contrôler la durée pendant laquelle une instance reste en état d'attente avant de passer à l'état suivant, configurez votre action personnalisée de manière à utiliser la commande complete-lifecycle-action. Avec les hooks de cycle de vie, les instances restent en attente soit jusqu'à ce que vous signaliez à Amazon EC2 Auto Scaling que l'action du cycle de vie est terminée, soit jusqu'à ce que le délai d'attente (défini par défaut sur une heure) soit écoulé.

Ce qui suit résume le processus d'un événement de montée en puissance.

Schéma de flux d'un événement de montée en puissance.

Lorsque les instances atteignent un état d'attente, Amazon EC2 Auto Scaling envoie une notification. Des exemples de ces notifications sont disponibles dans la EventBridge section de ce guide. Pour plus d’informations, consultez Exemples d’événements et de modèles de groupe chaud.

Cibles de notification prises en charge

Amazon EC2 Auto Scaling prend en charge la définition de l'un des éléments suivants en tant que cibles de notification pour les notifications de cycle de vie :

  • EventBridge règles

  • Rubriques Amazon SNS

  • Files d'attente Amazon SQS

Important

N'oubliez pas que si vous avez un script (cloud-init) de données utilisateur dans votre modèle de lancement ou configuration de lancement qui configure vos instances lors de leur lancement, vous n'avez pas besoin de notifications pour effectuer des actions personnalisées sur vos instances qui sont lancées ou relancées.

Les sections suivantes contiennent des liens vers la documentation décrivant comment configurer les cibles de notification :

EventBridge règles : pour exécuter du code lorsqu'Amazon EC2 Auto Scaling met une instance en état d'attente, vous pouvez créer une EventBridge règle et spécifier une fonction Lambda comme cible. Pour appeler différentes fonctions Lambda en fonction de différentes notifications de cycle de vie, vous pouvez créer plusieurs règles et associer chaque règle à un modèle d'événement et à une fonction Lambda spécifiques. Pour plus d’informations, consultez Créez des EventBridge règles pour les événements en piscine chaude.

Rubriques Amazon SNS : pour recevoir une notification lorsqu'une instance est mise en état d'attente, vous créez une rubrique Amazon SNS, puis configurez le filtrage des messages Amazon SNS pour fournir des notifications de cycle de vie différemment en fonction d'un attribut de message. Pour plus d’informations, consultez Recevoir des notifications à l'aide d'Amazon SNS.

Files d'attente Amazon SQS : pour configurer un point de livraison pour les notifications de cycle de vie où un consommateur pertinent peut les récupérer et les traiter, vous pouvez créer une file d'attente Amazon SQS et un consommateur de file d'attente qui traite les messages de la file d'attente SQS. Si vous souhaitez que le consommateur de file d'attente traite différemment les notifications de cycle de vie en fonction d'un attribut de message, vous devez également configurer le consommateur de file d'attente pour analyser le message, puis agir sur le message lorsqu'un attribut spécifique correspond à la valeur souhaitée. Pour plus d’informations, consultez Recevoir des notifications à l'aide d'Amazon SQS.