Un ingénieur DevOps a déployé un modèle CloudFormation qui lance une application web (ALB, groupe cible, modèle de lancement utilisant une AMI Amazon Linux 2, groupe Auto Scaling, groupe de sécurité et une base de données RDS MySQL). Les données utilisateur du modèle de lancement exécutent un script pour installer et démarrer l'application. Après avoir mis à jour les données utilisateur vers une nouvelle version de l'application et redéployé via le pipeline CI/CD, les vérifications de santé de l'ALB échouent et toutes les cibles sont signalées comme non saines. La pile CloudFormation affiche UPDATE_COMPLETE, mais un journal d'instance EC2 montre qu'Apache n'a pas réussi à démarrer en raison d'une erreur de configuration. Comment l'ingénieur peut-il faire en sorte que CloudFormation échoue le déploiement si le script des données utilisateur ne se termine pas avec succès ?

L'option correcte est d'utiliser l'assistant cfn-signal avec la politique de mise à jour WaitOnResourceSignals. cfn-signal permet à une instance EC2 de signaler à CloudFormation si les scripts de données utilisateur (ou d'autres opérations de configuration) ont réussi ou échoué. En ajoutant WaitOnResourceSignals à la ressource Auto Scaling Group dans le modèle CloudFormation, CloudFormation attendra ces signaux avant de considérer le déploiement comme terminé. Si un signal d'échec est reçu ou si le délai d'expiration est atteint sans signal de succès, CloudFormation fera échouer la mise à jour, empêchant ainsi un déploiement incomplet ou défectueux. Les autres options sont incorrectes car : Créer une alarme CloudWatch sur UnhealthyHostCount ne permet pas de signaler directement l'échec de la configuration à CloudFormation pour arrêter le déploiement. Cela alerterait après l'échec. Un hook de cycle de vie Auto Scaling est conçu pour effectuer des actions pendant le lancement ou l'arrêt des instances, mais ne fournit pas un mécanisme direct pour signaler l'échec de la configuration à CloudFormation pour bloquer la mise à jour de la pile. Diffuser les journaux cloud-init et utiliser une fonction Lambda pour appeler SignalResource est une approche trop complexe et indirecte par rapport à la solution native cfn-signal qui est spécifiquement conçue pour ce cas d'utilisation.