Kanarek a AWS Lambda. Wersje, aliasy. Testy

Kanarek a AWS Lambda. Wersje, aliasy. Testy

Artykuł ukazał się pierwotnie na blogu Chmurowiska.

Co raz więcej z nas używa funkcji Lambda. Co raz częściej używamy funkcji Lambda. Rozwiązania serverless rozpychają się łokciami. Czym jest ta AWS Lambda?

Tan naprawdę AWS Lambda to usługa. Usługa która pozwala na to, żeby stworzyć jakąś funkcję, wgrać jej kod do AWS i używać. Bez troski o serwery, systemy operacyjne, patchowanie oprogramowania, skalowanie. W skrócie, piszemy jakiś kod, wzucamy go do AWS, wywołujemy. Działa, robi robotę, zwraca wyniki. My idziemy dalej.

W prawdziwym życiu programisty niestety nie wygląda to tak różowo. Klient chce lekko zmienić format odpowiedzi na request. Klient chce żeby kurs waluty do przeliczeń nie był brany z wczoraj. Chce z ostatniego wtorku w poprzednim miesiącu. Zamówienie zakupu wymaga zatwierdzenia przez od dziś (albo od wczoraj) kogoś wyżej. Znacie to? Życie. Nieustanne zmiany. Nie lubię zmian w oprogramowaniu. Lubię zasadę Działa. Nie ruszaj Nie zawsze, a tak naprawdę prawie nigdy, nie da się tej zasady wprowadzić w życie.

Ale my mamy swój kod wrzucony do chmury. Co robić? Nie chcemy zepsuć działającej aplikacji!

Wersje

Nie każdy wie, przynajmniej nie na początku pracy z AWS, że możemy stworzyć kilka wersji tej samej funkcji Lambda. Tej samej, ale nie takiej samej. Inna wersja dla produkcji, inna do testów. Jeszcze inna do R&D.

Najlepiej pokazać to na przykładach.

Wersja 1

Tworzymy funkcję Lambda.

Coś prostego, runtime nie jest istotny. Najprostsze uprawnienia dla funkcji także wystarczą. Ja po prostu zwrócę z Lambdy tekst „Cześć”.

def lambda_handler(event, context):
	return 'Cześć'

Mamy naszą lambdę. Zwróćcie uwagę na jej ARN arn:aws:lambda:eu-west-3:xxxxxxxxxxxx:function:ChmurowiskoLambda Jest to tak zwany unqualified ARN.

Aby opublikować wersję z manu Actions wybieramy opcję Publish new version

Ostatnia wgrana przez nas wersja to $LATEST. Każda zmiana kodu powoduje nadpisanie tej wersji. Na podstawie jej konfiguracji oraz kodu utworzony zostanie snapshot i to on będzie podstawą dla naszej nowo tworzonej wersji.

Dodajemy jakiś opis i publikujemy.

Zwróćcie jeszcze raz uwagę na ARN. Teraz wygląda on trochę inaczej.

Na końcu widzimy numer wersji. Tym razem jest to qualified ARN.

Jak pamiętacie, pisałem, że stworzyliśmy snapshot z naszej Lambdy. Raz utworzona wersja nie może być zmieniana. Aby edytować kod, należy „wrócić” do wersji $LATEST.

Wersje kolejne

W ten sam sposób możemy utworzyć wiele wersji jednej funkcji Lambda. Zmieńmy trochę kod

def lambda_handler(event, context):
	return 'Cześć. Tu wersja druga'

i opublikujmy jeszcze jedną wersję.

W ten sposób, mając adresy ARN do kolejnych wersji, możemy różne eventy wywołujące naszą funkcję podłączać pod różne wersje.

Możemy także przełączać się w konsoli AWS na poszczególne wersje

i testować je bezpośrednio.

Aliasy

Funkcje można wywoływać za pomocą adresów ARN. Ciężko jednak by było, za każdym razem gdy tworzymy nową wersję (i zmienia się jej ARN), poprawiać adresy Lambd w innych usługach, które do naszych funkcji sięgają. Tu z pomocą przychodzą Aliasy.

W chwili obecnej mamy trzy wersje naszej funkcji. Wersję 1, 2 oraz $LATEST. Dobrym zwyczajem jest stworzenie aliasa dla tej ostatniej wersji. Od tego zaczniemy.

Alias latest

W konsoli, ponownie wchodzimy do menu Actions. Tym razem wybieramy jednak opcję Create alias.

W tym momencie możemy podać nazwę dla naszego aliasa oraz wybrać wersję, na którą ma wskazywać.

PARN dla naszego aliasa wygląda następująco:

Możemy też na przykład nazwać ten alias DEV i korzystać z niego w trakcie rozwoju naszego oprogramowania.

Produkcja, testy

Możemy też stworzyć aliasy dla wersji produkcyjnej (PROD) praz testowej (TEST). Alias PROD będzie wskazywał na wersję 1, alias TEST na wersję 2.

Mając taką konfigurację, możemy cały ruch produkcyjny kierować na ARN arn:aws:lambda:eu-west-3:094104221953:function:ChmurowiskoLambda:PROD, a ruch testowy na arn:aws:lambda:eu-west-3:xxxxxxxxxxxx:function:ChmurowiskoLambda:TEST

Po pomyślnych testach, gdy chcemy aby wersja 2 była tą, która pracuje na produkcji nie będziemy mieli zbyt dużo pracy. Wystarczy zmienić aliasa PROD, tak aby wskazywał na wersję 2.

W tym momencie wszystkie usługi korzystające produkcyjnie z naszej funkcji będą miały do dyspozycji nową wersję.

Gdyby jednak okazało się, że chcemy wrócić na produkcji do starszej wersji? Nic trudnego. Po prostu wracamy do takiego ustawienia, w którym alias PROD wskazuje na wersję 1.

Lambda i Canary deployment

Często, zanim udostępnimy nową wersję naszego oprogramowania, chcemy przetestować ją na części użytkowników. W tym celu tworzymy przeważnie dwa środowiska (lub dzielimy jedno na dwie części) i kierujemy na nie poszczególne grupy użytkowników. Jeżeli testowana wersja nie sprawia problemów i funkcjonuje zgodnie z oczekiwaniami możemy ja udostępnić wszystkim. Sposobu kierowania ruchu mogą być różne.

W przypadku Lambdy mamy takie rozwiązanie gotowe. Możemy stworzyć aliasa, który część ruchu będzie kierował na jedną wersję, a część na drugą.

Załóżmy, że nasza wersja produkcyjna to wciąż wersja 1. Mamy jednak wstępnie przetestowaną wersję 2 i chcielibyśmy udostępnić ją 30% użytkowników.

Wchodzimy do menu Actions, wybieramy opcję Create alias

wybieramy odpowiednie wersje, ustawiamy podział ruchu i gotowe. Dostajemy nowy ARN

i w momencie gdy skierujemy na niego ruch 30% wywołań spowoduje wykonanie nowej wersji funkcji, a reszta wciąż zadowoli się starszą wersją.

Taki podział możemy uruchomić pomiędzy dowolnymi wersjami za wyjątkiem wersji $LATEST.

Podsumowanie

AWS rekomenduje publikowanie nowej wersji za każdym razem gdy dokonujemy zmian w kodzie lub konfiguracji. Szczególnie w przypadku, gdy nad jedną funkcją pracuje więcej osób.

Nie wiem czy jest to dobra wskazówka. Z jednej strony istnieje rzeczywiście obawa, że jeden developer nadpisze kod drugiego. Nie sądzę jednak, że istnieje tu aż tak duże zagrożenie. Osobiście wolę najpierw przetestować kod i dopiero dokonać publikacji kolejnej wersji. Do kontroli wersji znam lepsze narzędzia 🙂

Na pewno warto jednak używać wersji i aliasów aby ułatwić sobie konfigurację i codzienną pracę z Lambdą. Polecam.

Comments are closed.