J'ai un modèle de formation de cloud que j'ai configuré une condition d'attente pour recevoir un signal lorsque le script de données utilisateur a terminé pour exécuter. Cela fonctionne parfaitement!
Maintenant, j'utilise CFN-HUP pour mettre à jour mon application avec une nouvelle version. Je mettez à jour la pile avec un nouveau paramètre et un script Téléchargez la nouvelle version et installez-la sur le serveur. Mais comme je ne mettant pas à jour la ressource de condition d'attente, il n'est pas recréé et n'attendez pas que le signal. Y a-t-il de toute façon forcer la récréation des ressources de condition d'attente?
3 Réponses :
Pour mettre à jour une application avec cloudformation, vous mettez à jour les données de la section "Metadata" d'une instance ou d'un élément Laucnconfig. Dans votre cas, vous modifiez la valeur d'un paramètre qui est référencé dans la section "Metadata". Je suppose qu'une "source" est mise à jour? Un travail de cron sur votre instance est défini pour exécuter CFN-HUP et, lorsqu'il s'agit, il lit les informations de la pile de formations sur cloud et qui voit qu'elle a changé. Ensuite, il effectue les actions spécifiées dans le fichier Hooks.Conf (ou celles spécifiées dans les fichiers du répertoire Hooks.D), qui est généralement exécutée CFN-init. La commande cfn-init récupère tous les fichiers des sources spécifiées et exécute toutes les commandes spécifiées dans la section "Metadata". Le résultat est une application mise à jour.
Pour la condition d'attente pour "réactiver" quelque chose qu'il faudrait le dire, lequel, BTW, je ne pense pas que cela soit possible. Depuis que la seule chose que vous changez, c'est une métadonnée d'instance, et toutes les actions se produisent locales à l'instance, je ne pense pas ce que vous essayez de faire serait possible. Une nouvelle condition d'attente devrait être créée et signalée par le signal CFN (qui devrait être appelée à Hooks.conf, je crois). Un scénario intéressant: Et si ce qui suit s'est produit: vous renommez la condition d'attente et changez les métadonnées pour la mise à jour. L'instance ne parvient pas à signaler complète et cloud de formation renvoie le modèle à l'état précédent. Lors de l'appel suivant à CFN-HUP, l'instance voit que la pile a changé, mais la réversion est suspendue et ne parvient pas à signaler complète. Serions-nous coincés dans une boucle infinie?
Donc, fondamentalement, ce que j'essaie de faire n'est pas possible et je devrais chercher une autre façon de vérifier si ma mise à jour a été réussie?
Je ne veux pas dire que ce n'est pas possible. Je ne vois tout simplement pas comment.
Grande question. Je cherche une solution moi-même, mais il semble que cela ne soit pas possible. À partir d'une nouvelle session de 2013:
- cfn-hup ne peut pas interagir avec le flux de travail de cloudformation
- Workflow n'attendra pas le CFN-HUP
- CFN-HUP ne peut pas échouer le flux de travail
- cfn-hup ne peut pas injecter des données dans la pile
"Si CFN-HUP se bloque et brûle et échoue de manière misérablement, le cloudformation Le flux de travail dira que la mise à jour est terminée. "
Source: https://www.youtube.com/watch?v=zhgmaw67yu0&t= 36m39s
Bonjour, merci de partage, j'ai rencontré le problème similaire. Et j'ai créé ma propre solution de contournement, même ce n'est pas gentil mais je suis heureux de le partager ici:
Merci de partage, j'ai rencontré le problème similaire et j'ai créé ma propre solution de contournement, même ce n'est pas gentil mais je suis heureux de le partager ici:
Le problème de la clé ici est Voici ma solution:
- dans le cadre de pas élégant mais ça marche :) CFN-HUP fonctionne de manière asynchrone et il n'y a aucun moyen pour nous de la raccrocher sur CloudFormation.
cfn-auto-reload.conf ,
- Nous invoquons le cfn-init cmd à mettre à jour la pile,
- et nous utilisons un autre script pour capturer le code de sortie de cfn-init cmd et la version de l'application installée,
- Ensuite, mettez-les dans un fichier sur S3.
Merci pour la suggestion. L'inconvénient est que votre mise à jour de la pile CF ne reflète pas le statut que vous le souhaitez. S'il y a une défaillance, pendant que votre pipeline peut refléter cela, votre pile CF indiquera "update_commete", correct?
Je ne pense pas que ce soit possible. Que voulez-vous faire si la nouvelle condition d'attente échoue? Voulez-vous supprimer la pile?
Non, je veux que ce soit annulé. Cela fonctionne si je crée une nouvelle condition d'attente avec un nom de logique différent, mais je ne veux pas faire cela parce que je devrais changer le gabarit. Je voudrais juste forcer la condition d'attente à recréer chaque mise à jour ou si une instance BIT EC2 est mise à jour.
Question fantastique. Avec le soutien de "updatepolicy" sur les ressources d'autocalegroup, qui peut créer de nouvelles ressources, le même problème existe. La création de la pile suit la commande appropriée, mais nous sommes incapables de générer de manière dynamique une nouvelle serviette pour vous assurer que non seulement la nouvelle boîte "en cours d'exécution", mais a été correctement provisionnée via le bloc UserData avant de commencer davantage la mise à jour des autres ressources. en bas de la chaîne de dépendance. Si je le faisant travailler avec ASG, je vais commenter à nouveau sur ceci, car c'est une approche très similaire.