Kod, który piszemy implementując nasze funkcje Lambda to, po prostu, zwykły kod. Nie charakteryzuje się niczym specjalnym.
W związku z tym powinniśmy się z nim obchodzić tak samo, jak w innych projektach, tworząc monolity czy mikroserwisy. Mam na myśli przede wszystkim dobre praktyki i wzorce programistyczne. Osobiście, od kilku lat projektując funkcje Lambda, podążam za wytycznymi architektury heksagonalnej.
Kolejną niesamowicie ważną i wręcz oczywistą praktyką jest continuous integration. Tak to się przynajmniej nazywało, gdy rozpoczynałem pracę programisty dawno temu. 😉
Proces CI/CD
Dziś mamy DevOps oraz pipeliny CI/CD. Nie wchodząc w zbędne dywagacje na temat terminologii, chcę podkreślić to, co ważne. Kod należy automatycznie budować i deployować.
W serverless również.
Nawet jeśli Serverless Framework udostępnia nam niesamowicie prosty mechanizm sls deploy umożliwiający deployment z naszego komputera do chmury, powinniśmy tego unikać na korzyść prawidłowo zdefiniowanego procesu CI/CD.
Duża część moich komercyjnych projektów dla klientów jest budowana i wdrażana (deployment) przy wykorzystaniu BitBucket pipelines. BitBucket oraz inne konkurencyjne rozwiązania wykorzystują obrazy dockera do tworzenia tymczasowych workerów, które budują nasz kod. W konfiguracji naszego procesu CI/CD możemy ustawić dowolny obraz. Warto wybrać taki, który skróci czas budowania aplikacji oraz uprości konfigurację naszego pipeline.
Obraz serverless-framework-docker-image
Dla własnej i Twojej wygody stworzyłem samodzielnie taki obraz, który od razu posiada niezbędne składniki, z których korzystam w swoim procesie CI/CD.
Zawiera on:
Node.js@12.20AWS CLIv2- oraz oczywiście
Serverless Framework
Wyboru Node.js raczej nie muszę tłumaczyć, natomiast AWS CLI w wersji 2 jest przydatny, gdy w czasie deploymentu należy wykonać specjalne działania. Przykładowo, jedną z takich akcji, jest pobranie własnych bibliotek npm z prywatnego repozytorium AWS CodeArtifact.
Na marginesie, enkapsulacja powtarzającego się kodu do biblioteki, która jest używana w wielu projektach, to też dobra praktyka. Do tego stara jak świat! 😉
Źródła projektu serverless-framework-docker-image dostępne są na GitHub.
Natomiast gotowy obraz jest dostępny publicznie w Docker Hub.
Wersjonowanie
Obraz jest wersjonowany równolegle z Serverless Framework.
W chwili pisania tego artykułu dostępne są cztery wersje obrazu:
- Serverless Framework 2.18.0 - tag:
2.18- 2021/01/07 - Serverless Framework 2.17.0 - tag:
2.17- 2020/12/30 - Serverless Framework 2.16.0 - tag:
2.16- 2020/12/22 - Serverless Framework 2.4.0 - tag:
2.4- 2020/12/17
Projekt aktualizuje w miarę na bieżąco.
Jak z tego korzystać?
W konfiguracji Twojego pipeline podaj jakiego obrazu chcesz użyć, a po znaku : podaj wersje. Jeśli, tego nie zrobisz, zostanie użyta najnowsza latest.
1 | image: serverlesspolska/serverless-framework # it resolves `latest` |
Podanie numeru, właściwie tagu gitowego (np. 2.18) spowoduje użycie obrazu z zainstalowaną właśnie tą wersją Serverless Framework:
1 | image: serverlesspolska/serverless-framework:2.18 |
Jak wygląda mój pipeline CI/CD?
Na koniec w paru słowach dodam, że cały proces CI/CD jest oczywiście podzielony na kilka środowisk (dev, test, prod) i każde z nich jest budowane i deployowane osobno w trakcie różnych wywołań tego samego procesu / pipelineu.
W krokach można napisać, że wygląda to tak:
- Pipeline ściąga kod źródłowy z repozytorium gita.
- Instalacja bibliotek (
npm i) - Testowanie jednostkowe
- Deployment do chmury (
sls deploy -s <środowisko>) - Testowanie integracyjne korzystające z zasobów w chmurze (np. DynamoDB, kolejki SQS itd.)
- Testowanie e2e - end to end - automatycznie uruchamianie całych przebiegów lub przypadków użycia na aplikacji wdrożonej w chmurze. To też może być testowanie RESTowego API.
- Koniec builda.
Podsumowanie
Użycie własnego obrazu dockera z preinstalowanymi zależnościami ułatwia konfigurację pipelineu i skraca czas jego działania. Dodatkowo pozwala kontrolować wersję Serverless Framework, z której korzysta build. Przy zaawansowanych projektach, korzystających z wielu pluginów ma to znaczenie, gdyż czasem aktualizacje wprowadzają problemy z kompatybilnością i nie zawsze warto używać wszystkiego w najnowszych wersjach.
Przykładem może być wielotygodniowy brak kompatybilności między najnowszymi wówczas wersjami Serverless Framework od 2.5.0 w górę, a bardzo popularnym pluginem serverless-iam-roles-per-function w wersji 2.x.x. Dopiero wydanie go w wersji 3.0.0 rozwiązało ten problem. Dopóki to nie nastąpiło, większość ludzi blokowała aktualizacje i używała Serverless Framework w wersji 2.4.0.
Podsumowując, gorąco Cię zachęcam do używania starych, ale wciąż dobrych praktyk programistycznych (bez względu na to, jak się je teraz nazywa 😉). Konfigurując swój pipeline CI/CD, możesz wykorzystać mój gotowy obraz serverlesspolska/serverless-framework, dzięki czemu uprościsz swoją konfigurację i zaoszczędzisz trochę czasu wykonania każdego builda Twojego projektu.
