Serverless DevOps - obraz dockera dla Twojego pipeline

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.20
• AWS CLI v2
• 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.

image: serverlesspolska/serverless-framework # it resolves `latest`
# or
image: serverlesspolska/serverless-framework:latest

Podanie numeru, właściwie tagu gitowego (np. 2.18) spowoduje użycie obrazu z zainstalowaną właśnie tą wersją Serverless Framework:

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:

1. Pipeline ściąga kod źródłowy z repozytorium gita.
2. Instalacja bibliotek (npm i)
3. Testowanie jednostkowe
4. Deployment do chmury (sls deploy -s <środowisko>)
5. Testowanie integracyjne korzystające z zasobów w chmurze (np. DynamoDB, kolejki SQS itd.)
6. 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.
7. 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.