Zarządzanie chmurą z użyciem Serverless Framework

serverless framework

Zarządzanie chmurą z użyciem Serverless Framework

lukado
Ponad 14 lat w branży IT. Konsultant i architekt projektów Amazon Web Services. Entuzjasta rozwiązań serverless. Współtwórca AWS User Group (3500+ osób). AWS Community HERO. Masz pytanie, napisz do mnie.
pl flag
en flag
Voiced by Amazon Polly

Chwila, chwila, jeszcze raz, „Zarządzanie chmurą z użyciem Serverless Framework” 😎?

Zgadza się, dzisiaj będzie o tym jak możesz łatwo i szybko użycie Serverless Framework przez elementach ogólnej orkiestracji platformą AWS.

Na taki koncept trafiłem ostatnio w jednym z projektów, gdzie do zbudowania pewnego (NDA) elementu związanego z zarządzaniem i bezpieczeństwem użyto właśnie Serverless Framework.

Postanowiłem zatem pobawić się tym chwilę i przy okazji odpalić jakieś małe demo, aby pokazać Ci w jaki sposób w kilku krokach możesz również zrobić coś podobnego. Mój przykład będzie trochę inny, ale chodzi o sam koncept.

Serverless Framework

Serverless Framework to narzędzie które, pozwala na tworzenie i deployment rozwiązań i aplikacji opartych usługi typu serverless. W tym wypadku chodzi przede wszystkim o tworzenie rozwiązań opartych o funkcję Lambda i wszystko z czym funkcje mogą wchodzić w interakcje. 

Z pewnością moi koledzy developerzy mogą powiedzieć więcej nt. korzyści używania Serverless Framework. Na potrzeby tego wpisu wystarczy, że zapamiętasz, że jest to jedno z narzędzi, które pozwala w dość łatwy sposób tworzyć i wdrażać aplikacje typu serverless. Jeśli chcesz pogrzebać więcej to zajrzyj na stronę serverless.com

Przykład rozwiązania – Tagowanie instancji EC2

Spójrzmy zatem, na jakiś najprostszy przykład rozwiązania. Załóżmy, niech będą „znów” te nieśmiertelne wirtualne maszyny. 

Jak wiadomo, to zazwyczaj jeden z bardziej drenująnch portfel komponentów infrastruktury chmurowej. Dlatego ważne jest aby uruchamiać i płacić za to co rzeczywiście jest używane i potrzebne. Zwłaszcza gdy pracujemy w większym zespole, warto zadbać o to aby odpowiednie zarządzać oznaczać zasoby itp. Nie ma nic gorszego jak maszyna która ma nie ma nazwy lub o wiele bardziej wymowną nazwę „nie wyłączać”.

Zatem aby nie grzebać po logach z CloudTrail zrobimy dzisiaj proste rozwiązanie, które będzie dodawać do maszyny dodatkowy Tag o nazwie Creator, a jego wartość będzie uzupełniania nazwą użytkownika, który takową maszynę utworzył.

Samo rozwiązanie jest dość proste, co widać na załączonym diagramie.

Diagram konfiguracji
  1. Amazon EventBridge zawiera definicję reguły „nasłuchującej” na zdarzenie utworzenie nowej maszyny (RunInstance).
  2. Następnie wywoływana jest funkcja Lambda, która za payload wyciąga dane użytkownika oraz id serwera.
  3. W ostatnim kroku funkcja taguje maszynę nazwą użytkownika.

Zatem powyższe przykład wdrożymy z wykorzystaniem Serverless Framework.

Instalacja Serverless Framework

W pierwszym kroku trzeba zainstalować sobie serverless framework. Czy to na komputerze lokalnym czy Cloud9 czy innym bycie, to już zostawiam Tobie.

Robota bajecznie prosta wystarczy wywołać (zakładam, że masz już node.js zainstalowanego):

npm install -g serverless

Pełną dokumentację znajdziesz TUTAJ

W następnym kroku, trzeba zapewnić dostęp do konta AWS, na którym będzie wykonywany deployment. Można użyć pary kluczy, lub aws cli-owych profili. Więcej szczegółów znajdziesz TUTAJ.

Ja używam aplikacji Leapp która loguje się do AWS i która ładuje tymczasowe profile cli na mój komputer.

DEMO TIME

Mając już zainstalowany serverless tool, czas przygotować paczkę do wdrożenia.

W tym celu tworzę sobie katalog roboczy, w którym przygotuję sobie wszystko co będzie mi potrzebne. Przykład jest dość prosty i zawiera dwa pliki.

Pierwszy to kod mojej funkcji lambda (taglambda.py), a drugi to plik konfiguracyjny (serverless.yml) na podstawie którego serverless framework będzie wiedział co ma wdrożyć.

Kodu funkcji nie będę teraz zbytnio analizować, zajmę się jedynie tym co jest najistotniejsze w pliku serverless.yml.

provider:
  name: aws
  runtime: python3.7
  region: eu-west-1

Zaczynamy od definicji providera, czyli platformy chmurowej, w naszym wypadku jest to oczywiście AWS. Dodatkowo wbiłem sobie od razu region w którym będę wdrażał swoje rozwiązanie (można to również podać w trakcie deploymentu). Od razu określam runtime mojej funkcji lambda (w tym wypadku python3.7).

Generalnie wszystko co jest zdefiniowane w sekcji provider jest dziedziczone potem w funkcjach, które tworzymy dalej. Np. jeśli dodałbym jeszcze konfigurację memorySize: 512, to wszystkie funkcje będą miały po 512MB pamięci. Oczywiście można ten parametr nadpisać już w samej definicji funkcji (per funkcja). 

Domyślnie dla funkcji tworzona jest podstawowa IAM rola, jednak jeśli potrzebuję nadać dodatkowe uprawnienia, to opisane jest to również w sekcji provider. Moja Lambda potrzebuje uprawnień, które pozwolą jej na dodanie TAGa do maszyny.

provider:
  name: aws
  runtime: python3.7
  region: eu-west-1
  iam:
    role:
      statements:
        - Effect: 'Allow'
          Action:
            - 'ec2:CreateTags'
          Resource: 'arn:aws:ec2:*:*:*'

Teraz przechodzę do definicji samej funkcji. 

functions:
  GOV-EC2-TAG:
    handler: taglambda.lambda_handler

Funkcje tworzone są w sekcji functions, w moim przypadku jest tylko jedna funkcja póki co. Tutaj określam między innymi konfigurację handlera. Opis jest dość prosty, pierwszy część wskazuje na plik funkcji lambda (taglambda.py), a drugi to definicja funkcji która jest wywoływana w momencie uruchamiania lambdy.

def lambda_handler(event, context):

Tutaj dodatkowo mogę definiować dodatkowe parametry dla tej funkcji jak ilość pamięci, timeout itp. Na potrzeby tego demo zostawię to defaultowo.

W tym momencie można by już właściwie wykonać deployment takiej konfiguracji. Wystarczy teraz wywołać proste polecenie:

serverless deploy

Cała magię zacznie się dziać pod spodem. To co zostanie wykonane, to tak naprawdę serverless framework przygotuje cloudformation template, który następnie wdroży na naszym koncie.

Konfiguracja Event Rule

Oczywiście póki co mam funkcję, ale nie mam jeszcze konfiguracji związanem z tym co będzie wywoływać tę lambdę.

Moje rozwiązanie wykorzystuję Amazon EventBridge i rule, która ma wyłapywać wszystkie API Calle z eventem „RunInstance„, czyli utworzenie nowej maszyny EC2.

Zatem czas na konfigurację eventu:

functions:
  GOV-EC2-TAG:
    handler: taglambda.lambda_handler
    events:
      - eventBridge:
          pattern: 
            source:
              - 'aws.ec2'
            detail-type:
              - 'AWS API Call via CloudTrail'
            detail:
              eventSource:
                - ec2.amazonaws.com
              eventName:
                - RunInstances

W tym celu dodaje sekcję events i w niej określam co będzie „triggerować” moją funkcję lambda. W tym wypadku jest to eventBridge, ale można wykorzystać tak naprawdę wszystko co wspierane jest przez Lambda (API Gateway, SNS, SQS itp.).

Teraz mając już pełną konfigurację, czas na ponowny deployment i przetestowanie. 

Dodanie Triggera do funkcji Lambda

Teraz już pozostaje tylko uruchomić nową instancje EC2 i sprawdzić, czy wszystko działa jak należy….

OK ale co z innymi zasobami?

Załóżmy, że chcemy aby nasze rozwiązanie dodatkowo odkładało w tabeli DynamoDB wszystkie instancje które zostały utworzone z dodatkowym opisem użytkownika, które je utworzył.

Potrzebujemy utworzyć tabelę DynamoDB (albo jakiś inny dowolny zasób AWS). W takiej sytuacji, wystarczy w pliki serverless.yml dodać sekcję resources i w nomenklaturze Cloudformation definiujemy pozostałe zasoby.

provider: aws
functions:
 
resources: # CloudFormation template syntax
  Resources:
    usersTable:
      Type: AWS::DynamoDB::Table
      Properties:
        TableName: ec2Instances
        AttributeDefinitions:
          - AttributeName: instanceID
            AttributeType: 
.......

Teraz należałoby jeszcze dostosować moją funkcję lambda do tego, aby mogła zapisywać dane do dynamodb. Pamiętać należy jeszcze o uprawnieniach. W tym wypadku nie będę już dobudowywał tej części, potraktuj to tylko jako wskazanie tego w jaki sposób dodawać inne zasoby. 

PODSUMOWANIE

Jak widzisz, dość łatwo udało mi się wdrożyć poniższe rozwiązanie. To prosty przykład, który mam nadzieję, że Cię zaciekawi i zachęci do dalszego zgłębienia możliwości jakie daje Serverless Framework.

Jak widzisz, nie dotykałem tutaj elementów multi-account deployment czy generalnej automatyzacji całego procesu. To może kiedyś w jakimś kolejnym wpisie.

Patrząc jednak na sam nakłada pracy, wydaję się to dość proste. Przede wszystkim widać od razu, że mniej jest „pisania”. W momencie deploymentu tworzony jest template cloudformation i tu od razu można sprawdzić i porównać o ile dłuższy będzie do tego co mamy tutaj.

Jeśli chcesz się pobawić tym, to kod rozwiązania znajdziesz na moim repozytorium LINK.

Cheers!



5 USŁUG AWS, KTÓRE WARTO POZNAĆ.