Quelles sont les bonnes pratiques pour implémenter des ressources personnalisées basées sur Lambda avec CloudFormation ?

Résolution

Lorsque vous implémentez des ressources personnalisées basées sur Lambda avec CloudFormation, suivez les bonnes pratiques ci-dessous.

Créer vos ressources personnalisées pour signaler, journaliser et gérer les échecs

Les exceptions peuvent entraîner la fermeture de votre code de fonction sans envoyer de réponse. CloudFormation requiert une réponse HTTPS pour confirmer si l'opération est une réussite ou un échec. Une exception non signalée oblige CloudFormation à attendre l'expiration de l'opération avant de lancer une restauration de pile. Si l'exception se reproduit pendant la restauration, CloudFormation attend à nouveau un délai d'expiration avant de se terminer par un échec de restauration. Pendant ce temps, vous ne pouvez pas utiliser votre pile.

Pour éviter les problèmes de délai d’expiration, incluez les éléments suivants dans le code que vous créez pour votre fonction Lambda :

• Logique de gestion des exceptions
• Possibilité de journaliser les erreurs pour les scénarios de dépannage
• Possibilité de répondre à CloudFormation par une réponse HTTPS pour confirmer l'échec d'une opération
• Une file d’attente de lettres mortes qui vous permet de capturer et de traiter les exécutions incomplètes
• Un module cfn-response pour envoyer une réponse à CloudFormation

Définir des délais d’expiration raisonnables et signaler quand ils sont sur le point d'être dépassés

Si une opération n'est pas exécutée dans le délai d’expiration imparti, la fonction déclenche une exception et n'envoie pas de réponse à CloudFormation.

Pour éviter ce problème, procédez comme suit :

• Définissez une valeur de délai d'expiration suffisamment élevée pour vos fonctions Lambda afin de gérer les variations du temps de traitement et des conditions du réseau.
• Définissez un minuteur dans votre fonction pour répondre à CloudFormation par un message d'erreur lorsqu'une fonction est sur le point d'expirer.

Élaborer à partir des événements Créer, Mettre à jour et Supprimer

En fonction de l'action de pile, CloudFormation envoie à votre fonction un événement Créer, Mettre à jour ou Suppression. Chaque événement étant géré différemment, vérifiez l’absence de comportement involontaire lorsque votre fonction reçoit l'un des trois types d'événements.

Pour plus d'informations, consultez la section Types de requêtes de ressources personnalisées.

Comprendre la manière dont CloudFormation identifie et remplace les ressources

Lorsqu'une mise à jour remplace une ressource physique, CloudFormation compare le PhysicalResourceId que votre fonction Lambda renvoie au PhysicalResourceId précédent. Si les ID diffèrent, CloudFormation suppose que la ressource est remplacée par une nouvelle ressource physique.

Toutefois, pour permettre d'éventuelles restaurations, CloudFormation ne supprime pas l'ancienne ressource. Une fois la mise à jour de la pile terminée, CloudFormation envoie une requête d’événement Supprimer avec l'ancien ID physique comme identifiant. Si la mise à jour de la pile échoue et qu'une restauration a lieu, CloudFormation envoie le nouvel ID physique lors de l'événement Supprimer.

Utilisez PhysicalResourceId pour identifier les ressources de manière unique. Ainsi, lorsque votre fonction reçoit un événement Supprimer, elle supprime uniquement les ressources appropriées lors d'un remplacement.

Concevoir vos fonctions avec l'idempotence

Vous pouvez répéter une fonction idempotente à plusieurs reprises avec les mêmes entrées, et le résultat est le même que si vous ne le faisiez qu'une seule fois. L’idempotence veille à ce que les nouvelles tentatives, les mises à jour et les restaurations ne créent pas de ressources dupliquées et n'introduisent pas d'erreurs.

Par exemple, CloudFormation invoque votre fonction pour créer une ressource, mais ne reçoit pas de réponse indiquant que la ressource a été créée avec succès. CloudFormation peut invoquer à nouveau la fonction et créer une deuxième ressource. La première ressource peut alors devenir orpheline.

Implémenter vos gestionnaires pour gérer correctement les restaurations

Lorsqu'une opération de pile échoue, CloudFormation tente de renvoyer toutes les ressources à leur état antérieur. Cette action entraîne des comportements différents selon que la mise à jour a entraîné le remplacement d'une ressource ou non.

Pour vous assurer que CloudFormation peut effectuer des restaurations, procédez comme suit :

• Évitez de supprimer implicitement les anciennes ressources jusqu'à ce que la fonction reçoive un événement Supprimer.
• Pour suivre les bonnes pratiques, utilisez cloudformation-accustom ou l’Assistant de ressource personnalisée sur le site web de GitHub.

Informations connexes

Créer une logique de provisionnement personnalisée avec des ressources personnalisées