Inżynier DevOps wdrożył szablon CloudFormation, który uruchamia aplikację internetową (ALB, grupę docelową, szablon uruchamiania używający Amazon Linux 2 AMI, grupę Auto Scaling, grupę zabezpieczeń i bazę danych RDS MySQL). Dane użytkownika szablonu uruchamiania uruchamiają skrypt do instalacji i uruchomienia aplikacji. Po zaktualizowaniu danych użytkownika do nowej wersji aplikacji i ponownym wdrożeniu za pośrednictwem potoku CI/CD, kontrola stanu ALB kończy się niepowodzeniem, a wszystkie cele są niezdrowe. Stos CloudFormation pokazuje status UPDATE_COMPLETE, ale dziennik instancji EC2 pokazuje, że Apache nie uruchomił się z powodu błędu konfiguracji. Jak inżynier może sprawić, aby CloudFormation zakończył wdrożenie niepowodzeniem, jeśli skrypt danych użytkownika nie zostanie pomyślnie ukończony?

Poprawna odpowiedź to użycie pomocnika cfn-signal i polityki WaitOnResourceSignals. cfn-signal umożliwia instancji EC2 wysłanie sygnału sukcesu lub niepowodzenia do CloudFormation po zakończeniu skryptu danych użytkownika. Polityka WaitOnResourceSignals w zasobie CloudFormation (np. grupie Auto Scaling) wstrzymuje postęp stosu do momentu otrzymania sygnału lub upływu limitu czasu. Jeśli skrypt danych użytkownika zakończy się niepowodzeniem, cfn-signal może wysłać sygnał niepowodzenia, co spowoduje wycofanie zmian w stosie CloudFormation. Pozostałe opcje są mniej odpowiednie: Alarm CloudWatch dla UnhealthyHostCount wykryje problem, ale nie spowoduje bezpośrednio wycofania CloudFormation. Hak cyklu życia Auto Scaling może powiadomić o problemie, ale nie ma wbudowanego mechanizmu do sygnalizowania niepowodzenia do CloudFormation w celu wycofania. Strumieniowanie dzienników i Lambda z SignalResource jest zbyt złożone i nie jest standardowym rozwiązaniem dla tego problemu.