Skip to content
malak.cloud
  • Kontakt
  • O mnie
  • Search Icon

malak.cloud

Cloud Native na co dzień

Serverless API – Jak postawić API bez serwera

Serverless API – Jak postawić API bez serwera

13 sierpnia 2017

Modne jest ostatnio wszystko, co ma związek z pojęciem serverless. Dziś zobaczymy jak postawić serverless API, czyli API bez serwera. Może nie bez serwera, ale bez zajmowania się serwerem. Taka opcja może się przydać nie tylko w celach testowych. Używając AWS Lambda możemy zapomnieć o konieczności skalowania, dbania o serwery, coś takiego jak brak dostępności do naszego API to będzie legenda.

Wykorzystamy AWS API Gateway i AWS Lambda. Pokażę jak prostą aplikację napisaną w Pythonie z wykorzstaniem Flask wrzucić do chmury i zacząć z niej korzystać.

Tworzymy API

Nie będę pokazywał jak stworzyć samą aplikację, czyli API. Zakładam, że to potraficie zrobić. Jeżeli nie, na GitHub udostępniam źródło prostego rozwiązania. Pamiętajcie tylko o dodaniu Flaska, czyli pip install Flask.

W naszym API będziemy mieli dwa endpointy, jednen główny, oraz jeden z bardziej skomplikowaną ścieżką.

app = Flask(__name__)
@app.route('/')
def home():
    return 'Hello, it\'s your first API'

@app.route('/path')
def deeper():
    return 'Hello, it\'s another path'

Przygotowujemy i konfigurujemy nasze Serverless API

To tyle, jeżeli chodzi o kod. Teraz clue programu, Zappa. Zappa umożliwia deployment naszego rozwiązania w trzech krokach. Pierwszym z tych kroków jest dodanie jej (jej? Zappa to ona?) do naszego rozwiązania: pip install zappa Dodajemy ją korzystając koniecznie z VirtualEnv.

Czym jest Zappa? Magikiem 🙂 W poprzednich wpisach pokazywałem jak skonfigurować AWS API Gateway. Zappa zrobi to za nas. I nie tylko to. Wrzuci także nasz kod do chmury. Po chwili od uruchomienia zaczynamy używać naszego API. Używać naszego API jako serverless, czyli otrzymamy nasz kod pracujący jako funkcja Lambda, z dostępem do niego poprzez AWS API Gateway. Ale po kolei.

Zainstalowaliśmy Zappę. Czas na skonfigurowanie projektu. Wpisujemy w konsoli zappa init i zaczyna się dziać…
Zappa wita się z nami i pyta o środowisko, w którym chcemy pracować. Zostawmy domyślne dev

W kolejnym kroku podajemy nazwę bucketa S3, do którego Zappa będzie wrzucała uploadowane paczki z naszym kodem.

Zappa powinna rozpoznać typ naszej aplikacji, oraz zapyta o ścieżkę do funkcji.

Zostaniemy jeszcze zapytani czy chcemy uruchomić naszą funkcję globalnie (i nie, nie chcemy).

I powinna nam się ukazać propozycja konfiguracji utworzonej na podstawie naszych działań.

Możemy zawsze ten plik edytować lub usunąć i uruchomić kongirurację (zappa init) jescze raz. Po zatwierdzeniu dostaniemy instrukcję jak zrobić update naszej paczki w chmurze.

Wrzucamy do chmury

Mamy utworzoną konfugurację dla środowiska dev, spróbujmy wrzucić wszystko do chmury.
zappa deploy dev i po chwili powiiniśmy mieć wszystko gotowe.

Dostaliśmy nawet jakiegoś urla 🙂 Otwieramy więc naszą ulubioną przeglądarkę, wklejamy tego urla i, voilà…

Dodajemy do urla naszą „rozbudowaną” ścieżkę, czyli teraz nasz url będzie wyglądał tak https://3luszhyzq7.execute-api.eu-west-1.amazonaws.com/dev/path

I znowu działa. Magia, mamy API na AWS bez dotykania AWS. No prawie 😉

Zobaczmy co tam nasz automat namieszał. Mamy więc utworzone API, które pracuje jako proxy

i przekazuje requesty do funkcji Lambda

Mieszamy

Aplikacje nigdy nie są skończone, a przede wszystkim bezbłędne. Robimy update naszego rozwiązania. Dodamy do naszego API obsługę POST. Zmeniamy trochę nasz kod, który teraz wygląda tak

from flask import Flask
from flask import request

app = Flask(__name__)
@app.route('/')
def home():
    return 'Hello, it\'s your first API'

@app.route('/path')
def deeper():
    return 'Hello, it\'s another path'

@app.route('/hello', methods=['POST'])
def hello():
    data = request.json
    return 'Hello {0}'.format(data['name'])

i uaktualniamy nasze środowisko na AWS. zappa dev update w terminalu

po chwili mamy nasze uaktualnienie wrzucone do chmury.  Do przetestowania potrzebujemy jakiegoś klienta, mogącego wysłać POST request. Polecam Postmana, ale my zostaniemy w terminalu i wykorzystamy curla.

curl -X POST \
  https://3luszhyzq7.execute-api.eu-west-1.amazonaws.com/dev/hello \
  -H 'cache-control: no-cache' \
  -H 'content-type: application/json' \
  -H 'postman-token: 76fef9a0-74b1-e7ce-758c-594d2aa07c47' \
  -d '{
	"name" : "Przemek"
}'

i znowu wszystko zadziałało

Podsumowanie

Czy API korzystające z funkcji AWS Lambda, Azure Functions czy Google CloudFunctions będzie zawsze lepszym rozwiązaniem? Nie. Przed wybraniem rozwiązania trzeba się zastanowić, co tak naprawdę nasze API robi i jakich zasobów potrzebuje. Ale to już chyba temat na osobny wpis.
Mnie cieszy jednak rozwój całej otoczki wokół chmur. Ułatwienia codziennej pracy. Możliwość oszczędności.


AWS, CloudNative, DEV
AWS

Post navigation

PREVIOUS
Czyścimy Dockera
NEXT
Jak pracuję z SQL Server na Mac OS X
Comments are closed.
Cześć. Nazywam się Przemek Malak. Dzięki za wizytę. Mam nadzieję, że to o czym piszę Cię zainteresowało. Jeżeli chcesz ze mną pogadać, najłatwiej będzie przez LinkedIn.

Losowe wpisy

  • Łączymy Amazon GuardDuty z MS Teams i Slackiem

    1 maja 2021
  • AWS Lambda – Golang – Custom Runtime

    22 maja 2022
  • Serverless – drugi poziom wtajemniczenia

    18 czerwca 2019
  • AWS IoT ExpressLink

    22 sierpnia 2022
  • Czyścimy Dockera

    12 sierpnia 2017
  • Apps
  • AWS
  • CloudNative
  • Cookbook
  • Data
  • DEV
  • GCP
  • IoT
  • Istio
  • k8s
  • Security
  • Social
  • GitHub
  • LinkedIn
© 2023   All Rights Reserved.