Stwórz zrównoważone potoki CI/CD

W momencie nieuchronnej awarii chcesz uniknąć pechowego wdrożenia. Dlatego też autorzy rozpoczną od krótkiej historii, która obrazuje cel tego artykułu.

Zespół DevOps właśnie rozpoczął aktualizację bazy danych z planowanym 30-minutowym przestojem. Zespół zautomatyzował cały przepływ aktualizacji, uruchomił potok CI/CD bez interwencji człowieka, a aktualizacja przebiega płynnie. Następnie, po 20 minutach, potok utknął, a uaktualnienie nie postępuje. Okres konserwacji wygasł i klienci nie mogą dokonywać transakcji. Utworzyłeś zgłoszenie do pomocy technicznej, a inżynier AWS potwierdził, że uaktualnienie kończy się niepowodzeniem z powodu działającego incydentu AWS Health w regionie us-west-2. Inżynier polecił zespołowi DevOps dalsze monitorowanie strony status.aws.amazon.com pod kątem aktualizacji dotyczących rozwiązywania incydentów. Wydarzenie trwało przez trzy godziny, podczas których klienci nie mogli dokonywać transakcji. Po rozwiązaniu problemu zespół DevOps ponowił próbę uszkodzonego potoku i ta zakończyła się pomyślnie.

Po tym zajściu zespół DevOps zbadał możliwości uniknięcia tego typu incydentów w przyszłości. Zespół został poinformowany o interfejsie AWS Health API, który zapewnia programowy dostęp do informacji AWS Health. W tym artykule autorzy pomogą zespołowi DevOps w maksymalnym wykorzystaniu interfejsu API AWS Health, aby w przyszłości aktywnie zapobiegać niezamierzonym przestojom.

AWS zapewnia klientom Business i Enterprise Support dostęp do AWS Health API. Klienci mogą mieć dostęp do uruchomionych zdarzeń w infrastrukturze AWS, które z kolei mogą mieć wpływ na wykorzystanie ich usług. Zdarzenia mogą mieć charakter regionalny, AZ, a nawet konta. Podczas tych incydentów nie zaleca się wdrażania ani zmieniania usług, na które ma wpływ zdarzenie.

Za pomocą tego artykułu zostaniesz przeprowadzony przez proces osadzania wglądu AWS Health API w potokach CI/CD, aby automatycznie zatrzymywać wdrożenia za każdym razem, gdy zdarzenie AWS Health zostanie zgłoszone w regionie, w którym działasz. Ponadto przekonasz się w jaki sposób może to zautomatyzować wykrywanie i naprawę.

Wersja demonstracyjna

W wersji demo autorzy użyją AWS CodePipeline do zademonstrowania pomysłu. Zbudują prosty potok, który zademonstruje koncepcję bez wchodzenia w szczegóły kompilacji, testowania i wdrażania.

CodePipeline Flow

Przepływ CodePipeline składa się z trzech kroków:

1. Etap źródłowy, który pobiera szablon CloudFormation z AWS CodeCommit. Szablon zostanie wdrożony w ostatnim etapie.
2. Niestandardowy etap, który wywołuje funkcję AWS Lambda w celu oceny kondycji AWS. Funkcja Lambda wywołuje interfejs API AWS Health, ocenia ryzyko zdrowotne i odwołuje CodePipeline z wynikiem oceny.
3. Etap wdrażania, który wdraża szablony CloudFormation pobrane z CodeCommit w pierwszym etapie.

Lambda evaluation logic

Funkcja Lambda ocenia, czy wdrożenie może mieć wpływ na działające zdarzenie AWS Health. W takim przypadku należy spełnić następujące kryteria, aby można było uznać go za bezpieczny do wdrożenia:

• Wdrożenie będzie miało miejsce w regionie Północnej Wirginii i odpowiednio funkcja Lambda będzie filtrować w regionie us-east-1.
• Zamknięty event nie ma znaczenia. Funkcja Lambda odfiltruje zdarzenia, które mają tylko status otwarty.
• AWS Health API może zwracać różne typy zdarzeń, które mogą nie być istotne, takie jak: Zaplanowana konserwacja oraz powiadomienia o kontach i rozliczeniach. Funkcja Lambda odfiltruje tylko zdarzenia typu „Problem”.

Interfejs API AWS Health jest zgodny z wieloregionalną architekturą aplikacji i posiada dwa regionalne punkty końcowe w konfiguracji aktywny-pasywny. Aby obsługiwać aktywne-pasywne przełączanie awaryjne DNS, AWS Health udostępnia globalny punkt końcowy. Kod Pythona jest dostępny na GitHub, a więcej informacji w README na temat budowania pakietu kodu Lambda.

Funkcja Lambda wymaga następujących uprawnień AWS Identity and Access Management (IAM), aby uzyskać dostęp do AWS Health API, CodePipeline i publikować logi w CloudWatch:

Architektura rozwiązania

W CodePipeline utwórz nowy etap za pomocą jednej akcji, aby asynchronicznie wywołać funkcję Lambda. Funkcja wywoła API AWS Health DescribeEvents w celu pobrania listy aktywnych incydentów dotyczących zdrowia. Następnie funkcja zakończy analizę zdarzeń i zdecyduje, czy może to wpłynąć na uruchomione wdrożenie. Na koniec funkcja wywoła kod CodePipeline z wynikami oceny za pomocą operacji interfejsu API PutJobSuccessResult lub PutJobFailureResult.

Jeśli ewaluacja Lambdy się powiedzie, wywoła potok za pomocą interfejsu API PutJobSuccessResult. Z kolei potok oznaczy krok jako pomyślny i zakończy wykonanie.

Jeśli ewaluacja Lambdy nie powiedzie się, wywoła potok z interfejsem API PutJobFailureResult, który określi komunikat o błędzie. Gdy zespół DevOps zostanie poinformowany, że zdarzenie zostało rozwiązane, wybierz przycisk Ponów, aby ponownie ocenić stan kondycji.

Twój zespół DevOps musi być świadomy nieudanych wdrożeń. Dlatego dobrym pomysłem jest skonfigurowanie alertów, aby powiadomić zainteresowane strony o nieudanych realizacjach etapów. Utwórz regułę powiadomienia, która opublikuje wiadomość Slack, jeśli etap się nie powiedzie. Aby uzyskać szczegółowe instrukcje, zobacz Tworzenie reguły powiadomień – AWS CodePipeline. W przypadku awarii powiadomienie Slack zostanie wysłane przez Chatbota AWS.

Bardziej „eleganckie” rozwiązanie polega na przekazaniu powiadomienia do tematu SNS, który z kolei wywołuje funkcję Lambda, aby ponowić próbę nieudanego etapu. Funkcja Lambda wyodrębnia identyfikator etapu niepowodzenia potoku, a następnie wywołuje interfejs API RetryStageExecution CodePipeline.

Wnioski

Dowiedziałeś się jak tworzyć automatyzację, która ocenia ryzyko związane z kontynuowaniem wdrożenia w połączeniu z uruchomionym zdarzeniem AWS Health. Następnie automatyzacja decyduje, czy kontynuować wdrożenie, czy zablokować postęp, aby uniknąć niezamierzonych przestojów. W związku z tym skutkuje to lepszą dostępnością Twojej aplikacji.

To rozwiązanie nie dotyczy wyłącznie CodePipeline. Jednak wzorzec można zastosować do innych narzędzi CI/CD używanych przez zespół DevOps.

źródło: AWS