poprzednim artykule z tej serii opisałem czym jest Serverless Framework i jakie problemy rozwiązuje. W tej części zajmiemy się jego instalacją, następnie skonfigurujemy go do pracy z chmurą AWS,  a na koniec przedstawię Ci kilka narzędzi, które ułatwią Ci pracę zarówno z Serverless Framework jak i z samą chmurą. Te trzy kroki pozwolą nam przejść płynnie do ostatniego artykułu z tej serii, gdzie pokaże Ci jak proste może być stworzenie aplikacji typu CRUD w oparciu o serverlesowy stack AWS z wykorzystaniem Serverless Framework.  

Instalacja Serverless Framework

Serverless Framework dostarcza nam interfejs CLI, za pomocą którego zarządzamy naszą opartą o funkcję aplikacją. CLI ten jest oparty o Node.js, który musimy mieć go zainstalowanego u siebie na komputerze. Minimalna wymagana wersja to Node v6, jednak polecam Ci zainstalować bądź zaktualizować się do rekomendowanej stabilnej wersji.  

Instrukcje do instalacji Node.js znajdziesz na jego oficjalnej stroniePo zainstalowaniu zweryfikuj czy wszystko działa poprawnie sprawdzając czy masz z poziomu terminala dostęp do poniższych komend 

node -v
npm -v 
 

NPM jest to domyślny menadżer paczek dla środowiska Node.js. Jest on instalowany wraz z Node.js i również dostarcza interfejs CLI, potrzebny między innymi do instalowania paczek z globalnego repozytorium. 

Gdy ten krok za nami pozostaje jeszcze tylko instalacja samego Serverless Framework. Do tego właśnie wykorzystamy npma i poniższą komendę

npm install -g serverless 
 

I podobnie jak z Node po instalacji możemy zweryfikować czy CLI SF działa z poziomu naszego basha.

serverless --version
sls --version 

# sls to po prostu skrót do polecenia serverless  

Konfiguracja konta AWS dla Serverless Framework

Serverless Framework CLI potrzebuję uprawnień do twojego konta AWS aby tworzyć i zarządzać zasobami w Twoim imieniu. Jest kilka sposobów na to aby nadać ten dostęp. My zrobimy to zgodnie ze sztuką tworząc dedykowanego Usera w IAM, wygenerujemy parę kluczy i podepniemy je do aws-cli.
Jeśli nie masz jeszcze zainstalowanego u siebie aws-cli to tutaj znajdziesz oficjalną instrukcje instalacji. 

Gdy to już za nami logujemy do naszej konsoli AWS i przechodzimy do panelu IAM w celu utworzenia dedykowanego użytkownika 

tworzenia usera IAM

Nasz użytkownik z założenia ma być wykorzystywany jedynie w ramach danego projektu więc jego nazwa powinna być jasno wskazująca jego zastosowanie. Zaznaczamy Programatics access, gdyż będziemy chcieli wygenerować parę kluczy i przechodzimy dalej. 

tworzenie polis IAM

Do naszego IAM Usera będziemy chcieli utworzyć nową polisę z ograniczonymi uprawnieniami. Tylko i wyłącznie z tymi, które będą wykorzystywane przez cli Serverless Framework. Przechodzimy w tym celu do okna gdzie będziemy mogli stworzyć taką polisę.

W zakładce JSON wklejamy zawartość 
TEGO pliku. Plik ten zawiera definicje polisy w formacie json, która określa jakie uprawnienia będzie miał nasz User po przypisaniu mu tej polisy.  Owa polisa posiada szerszy zakres uprawnień niż to co będziemy robić w ramach kolejnego artykułu, ale zezwala na wszystkie dostępne akcje z poziomu cli SF. Jeśli jednak nie czujesz się z nią pewnie, możesz wyciąć niektóre uprawnienia i dodać je dopiero gdy będą faktycznie przez Ciebie wykorzystywane. 

Klikamy Review policy, nadajemy sensowną nazwę oraz opis dla polisy i klikamy Create polisy

polisa i rola aws

Wracamy teraz do naszego okna gdzie tworzyliśmy Usera, odświeżamy listę polis wpisujemy w wyszukiwarkę nazwę nowo utworzonej polisy i ją zaznaczamy aby przypisać ją do użytkownika. Następnie przechodzimy dalej, aż naszym oczom ukaże się poniższy komunikat.

aws tworze nie użytkownika

W tym miejscu możemy podejrzeć nasz access i secret key, które posłużą nam do uwierzytelnienia naszego AWS cli a co za tym idzie również cli Serviceless Framework. 

Aby teraz skonfigurować credentionale do aws-cli wykonujemy poniższe polecenie, aby przejść przez konsolowego wizarda.

aws configure
AWS Access Key ID [None]: aws-key
AWS Secret Access Key [None]: aws-secret
Default region name [None]: eu-west-1 Default output format [None]: json 

Po tej akcji nasze klucze powinny zostać zapisane w pliku .aws/credentials, który znajduje się w głównym katalogu użytkownika.
Jeśli już wcześniej posiadałeś przypisanego użytkownika do swojego aws-cli możesz nadpisać tę dane, bądź dodać kolejny profil edytując plik .aws/credentials

[default]
aws_access_key_id = access_key
aws_secret_access_key = secret_key

[second_profile]
aws_access_key_id = access_key2
aws_secret_access_key = secret_key2 

Profil default jak sama nazwa wskazuje jest domyślny i to z niego korzysta aws-cli jeśli nie podasz mu ręcznie flagi z nazwą innego profilu.

Aby sprawdzić czy aws-cli działa poprawnie powinieneś być teraz w stanie wykonać poniższe polecenie

aws s3 ls 

Polecenie powinno wylistować wszystkie Twoje buckety z regionu, który ustawiłeś jako domyślny. Jeśli wszystko działa, możemy uznać, że setup mamy zakończony.

Hello world z Serverless Framework 

Teraz czas na szybkie setup projektu z gatunku hello-world. Będzie naprawdę szybko. Żadnego klikania w konsoli, ani ręcznego tworzenia zasobów. Wykonujemy polecenie sls w konsoli, przechodzimy przez krótkiego wizarda gdzie wybieramy nazwę projektu, środowisko deweloperskie i rezygnujemy z tworzenia konta w platformie Serverless, to nie będzie nam potrzebne przy naszych ćwiczeniach.

sls init

Nowy projekt utworzony, przechodzimy do utworzonego katalogu a w nim uruchamiamy polecenie sls deploy. Nasz projekt wygenerowany z szablonu zostanie zainstalowany w AWS i gotowy do działania.

sls deploy

Co tak naprawdę zadziało się pod spodem ? SF cli zbudowało naszą paczkę z kodem (plik handler.js) i na podstawie definicji deploymentu (serverless.yml) utworzyło odpowiedni szablon CloudFormation, który już wiedział jakie zasoby ma dla nas utworzyć w AWS. Taka prosta funkcja typu hello-world tak naprawdę nie tworzy zbyt wielu zasobów. Możesz sprawdzić  jakie zasoby zostały utworzone poprzez podejrzenie definicji szablonu CloudFormation w konsoli AWS.

cloud formation aws

Jak widzisz mamy tu jedynie naszą funkcję Lambda, rolę IAM przypisaną do tej funkcji oraz bucket S3, do którego trafił zipowany plik z kodem funkcji. Mała uwaga, domyślnie utworzony projekt serverlesowy prawdopodobnie zostanie utworzony regionie us-east-1 (N. Virginia) czyli w innym niż przypisaliśmy do aws cli, dlatego właśnie w tym regionie szukaj owych zasobów. 
Możemy się również pokusić o wywołanie naszej funkcji i podejrzenie jej logów poniższą komendą 

sls logs -f hello -t 

Tak jak wspomniałem wcześniej, na ten moment nasz deployment to jedynie funkcja Lambda. Nie jest on wystawiona przez API Gateway, więc nie możemy jej wywołać poprzez REST endpoint. W kolejnej części tego artykułu zaprezentuję Ci bardziej złożony projekt, który wystawia CRUDowe API poprzez API Gateway oraz wykorzystuje DynamoDB jako warstwę persystencji. Jeśli chodzi o nasz setup to udało nam się dobrnąć do końca. Pamiętaj, aby po zakończeniu eksperymentów z SF posprzątać na chmurze. Mimo iż za większość zasobów serverlesowych nie zostaniesz chargowany (jeśli ich nie używasz), to dla bezpieczeństwa i tak polecam Ci czyścić nieużywaną infrastrukturę :). Możesz to zrobić za pomocą poniższego polecenia.

sls remove 

Przydatne wtyczki do Visual Studio Code w pracy z Serverless Framework

Na koniec mały bonus. Z racji tego, że ostatnie przerzucam się z IDE od JetBrains na VS-Code (trochę z ciekawości) postanowiłem, że podzielę się z Tobą kilkoma przydatnymi rozszerzeniami, które mogą Ci się przydać do pracy z projektami serverless i nie tylko. Oto krótka lista:

  • AWS Toolkit – dzięki niemu będziesz miał możliwość zarządzania zasobami swojego konta AWS z poziomu IDE. Również wymagane jest przypisanie IAM Usera.

  • Serverless Framework – prosty podpowiadacz kodu, który ułatwi CI pisanie definicji yml w SF

  • Terminal – z racji tego, że praca z SF to w sporej mierze praca z terminalem, polecam Ci gorąco doinstalowanie sobie terminal bezpośrednio do IDE.

  • Local History – często zdarza się na etapie eksperymentowania z nową technologią, zmieniamy linijki kodu na czuja. Zmienimy coś w paru plikach i nagle apka przestaje działać. Z jakiejś dziwnej przyczyny nie zadziałał Ctrl + Z. Tutaj na ratunek przychodzi właśnie ta wtyczka. Śledzi ona lokalne zmiany w każdym z plików i tworzy historię, którą łatwo możemy podejrzeć i przywrócić.  



Dodaj komentarz

Close Menu