• Akademia
  • Blog
  • O Serverless
  • O stronie

Serverless DevOps - obraz dockera dla Twojego pipeline


"Jak pod艂膮czy膰 dysk EFS do funkcji Lambda?"

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:

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
2
3
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:

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:

  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.