Jak wykorzystać Pythona w chmurze AMAZON WEB SERVICES?

Jak wykorzystać Pythona w chmurze AMAZON WEB SERVICES?

python-w-chmurze

Jak wykorzystać Pythona w chmurze AMAZON WEB SERVICES?

Tomek-Sapalski-Picture

TOMEK SAPALSKI

W dzisiejszym wpisie chciałbym Wam przedstawić kilka sposobów, jak wykorzystać Pythona w chmurze Amazon Web Services, czyli AWS.

1. Function as service i aplikacje bezserwerowe

Pierwszą metodą, o której opowiem jest „function as a service”, czyli usługa dostępna w każdej chmurze. Polega na tym, że umożliwia wybranie funkcji pythonowskiej i umieszczenie jej kodu źródłowego na usłudze w chmurze. W Amazon Web Services usługa ta nazywa się Lambda. Dzięki niej możemy napisać prostą funkcję i dołączyć do niej zewnętrzne biblioteki (w przypadku, kiedy AWS nie posiada standardowych). Następnie możemy testowo wejść w chmurę, wywołać funkcję i sprawdzić, czy spełnia swoje zadania, czy łączy się z jakimiś dodatkowymi stronami internetowymi, itp. Za pomocą jednej funkcji lambda można również wywołać inne funkcje lambda. W ten sposób, łącząc je ze sobą możemy zbudować całe programy – jednak, nie jest to najbardziej popularna metoda ich tworzenia.

Najczęściej spotykany sposób opiera się na użyciu API, czyli do funkcji podłączamy link url i to za jego pomocą wywołujemy naszą funkcję pythonowską. Tą metodą tworzy się również całe programy, które wywołują jeden – drugi. Można dla przykładu zbudować sobie stronę na front-endzie, która będzie w javascriptcie z całym front-endowym zapleczem, i po naciśnięciu określonych przycisków lub wywołaniu jakiejś innej akcji, można wywołać API, które zostaną przekierowane do back-endu, czyli naszych funkcji lambda. Następnie one będę dokonywać np. jakichś zmian w bazie danych, wracać i wyświetlać wynik na stronie internetowej.

Powyższy sposób opisuje, jak buduje się tzw. aplikacje bezserwerowe. Skąd ta nazwa? No stąd właśnie, że mimo, że musimy ich użyć, jednak nie musimy się nimi bezpośrednio zajmować. Wygląda to w taki sposób, że Amazon tworzy dynamicznie serwer z zainstalowanym Pythonem, wywołuje na nim naszą funkcję, po czym zwraca nam wynik i kasuje serwer. Dzięki temu nie musimy się martwić systemem operacyjnym, miejscem na dysku, RAMem, czy procesorem. Nas interesuje tylko przekazanie kodu źródłowego funkcji, a cała reszta jest zadaniem Amazona.

Amazon, cały proces (tworzenie serwera – wywołanie funkcji – zwrócenie wyniku -skasowanie serwera) wykonuje bardzo szybko – trwa to najczęściej 100-200 milisekund. Zapytacie, jak monitorować takie aplikacje? Oczywiście dzięki dostępowi do logów. W Amazonie możemy skorzystać z usługi CloudWatch, która zbiera dla nas logi na swoje repozytorium, skąd możemy je później przeglądać. Główna zaleta tego rozwiązania polega na tym, że jeśli nie musimy tworzyć serwerów, mamy możliwość odtworzenia jednocześnie wielu funkcji na raz i nie musimy martwić się infrastrukturą.

Rozwiązanie to jednak nie jest pozbawione wad – korzystając z niego trudno jest ogarnąć powiązania. Przede wszystkim dlatego, że jeśli wcześniej mieliśmy do dyspozycji jeden program to dokładnie wiedzieliśmy, jak będzie działał w określonych sytuacjach. W tym przypadku mamy już np. 1000 małych programików i zmiana w jednym z nich może pociągnąć za sobą zmiany gdzie indziej, co może być dla nas trudne do przewidzenia. W związku z tym funkcje muszą być tworzone w na tyle uniwersalny sposób, żeby zwracały wyniki, których jesteśmy pewni w 100% i które nie będą zależały od innych czynników, jak np. prosta funkcja, która zwraca godzinę.  

Kolejna rzecz, na którą musimy zwrócić uwagę, to fakt, że nasz kod źródłowy znajduje się na chmurze. To oznacza, że jest dostępny i można go dowolnie przerabiać. Nie powinno się tak zdarzyć (wszystko powinno iść zgodnie z procesem CICD, o którym pisałem tutaj – link), ale jednak istnieje ryzyko, że ktoś z uprawnieniami wejdzie do funkcji lambda i ją po prostu wyedytuje. W tej sytuacji kod lambda, który jest na repozytorium będzie różnił się od tego, który faktycznie został wgrany na chmurę.

Warto wspomnieć również o tzw. rozgrzewaniu lambdy, co być może nie jest jakimś bardzo znaczącym problemem (Amazon pracuje nad rozwiązaniem), niemniej może być czasami nieco uciążliwe. Zjawisko to polega na tym, że kiedy funkcja lambda zostanie postawiona i uruchomiona na serwerze Amazona po raz pierwszy, to po jej zakończeniu Amazon nie usunie tego serwera. Dlaczego? Amazon czeka i sprawdza, czy być może nie chcielibyśmy za jakiś czas ponownie jej uruchomić – gdyby tak się zdarzyło to nie musi tworzyć serwera ponownie. Z tego względu, pierwsze wywołanie lambdy po długim okresie będzie trwało więcej czasu, a już kolejne będą znacznie krótsze. Czasem programiści na wszelki wypadek odpalają funkcję lambda co parę minut, tylko po to, żeby w razie czego uniknąć rozgrzewania.

Przykłady aplikacji, które, używają bezserwerowych metod działania to przede wszystkim wszelkie klony youtube.com. Polegają one właściwie głównie na fronte-endzie. Oprócz tego, w jakiś repozytoriach są umieszczone duże pliki video, a back-end polega tylko na tym, żeby ten plik video pobrać z repozytorium i wrzucić go na front-end, żeby widz mógł go obejrzeć. Dodatkowo, jest superskalowalny, bo każdy widz niejako dostaje nowy serwer i tylko u niego na serwerze ta aplikacja jest uruchamiana (każda lambda swój serwer). Tego typu aplikacje bardzo dobrze działają na lambdzie. Jeśli chcesz zobaczyć przykład, jak w AWSie taką prostą lambdę się tworzy, to zapraszam do obejrzenia krótkiego filmowego demo: https://www.tomeksapalski.pl/lambdademo

Serwery EC2

Kolejne zastosowanie jest już bardziej serwerowe, czyli można sobie stworzyć serwer i zainstalować na nim Pythona i stworzyć aplikacje, ale to już nie jest tak do końca rozwiązanie chmurowe. W związku z tym zostały zaprojektowane serwery gotowe, jak np. django, z których również możemy skorzystać na Amazonie. Może być postawiony na Windowsie lub Linuxie – to nie ma większego znaczenia, bo nie mamy potrzeby instalowania niczego więcej. Wraz z tym serwerem możemy dodatkowo stworzyć sobie infrastrukturę, czyli dodatkowych kilka serwerów które będą razem działały – będzie za to odpowiedzialny load balancer. Z jego pomocą możemy sobie przełączać się między serwerami zyskując większe możliwości działania. Możemy zastosować również auto scaling – serwery będą się tworzyć i kasować dynamicznie w zależności od ruchu na stronie.

To, o czym trzeba pamiętać podczas tworzenia takich serwerów (szczególnie w auto scalingu) jest to, że jeżeli trzymamy logi na serwerze to w przypadku jego usunięcia stracimy również logi. W tej sytuacji warto skorzystać z takiej usługi jak EFS (Elastic File System), który pełni funkcję share drive, na którym możemy zapisać nasze logi. Można w tym celu wykorzystać też CloudWatch, o którym wspomniałem wcześniej przy lambdzie, niemniej ta metoda jest już nieco bardziej zaawansowana.

Biblioteka Boto3

Kolejna metoda, którą możemy zastosować to biblioteka Boto3. Nie służy ona jednak do tworzenia aplikacji jako takich. Boto3 to biblioteka pythonowska, za pomocą której stworzysz infrastrukturę bezpośrednio na chmurze AWS. Czyli za pomocą funkcji pythonowskich możemy powiedzieć, że chcemy np. nowy serwer albo 3 nowe serwery, bazę danych, load balancery, czy nawet funkcję lambda – cokolwiek Amazon oferuje w gamie swoich usług w AWS. Możemy tę całą infrastrukturę tworzyć wykorzystując komendy i polecenia pythonowskie, nie będąc na konsoli AWS na stronie internetowej. To bardzo wygodne rozwiązanie – można nawet podpiąć domenę pod serwer i w ten sposób stworzyć cały szkielet aplikacji.

Możemy również taki szkielet aplikacji stworzyć do aplikacji bezserwerowej, czyli na S3 przechowywać pliki. API gateway do tego, żeby dostać swoje API do naszej funkcji i na koniec funkcje lambda i jakąś bazę danych. Podsumowując, wszystkie te rzeczy możemy stworzyć w Pythonie po to, żeby potem również w Pythonie zbudować całą aplikację. Później możemy już działać zgodnie z modelem CICD i wszystko po kolei automatyzować.

Dla przykładu, taki mój mały use case – kiedyś mieliśmy klientów, którzy chcieli demo naszej aplikacji. Było to wówczas zorganizowane w taki sposób, że jak klient wysyłał maila, z prośbą o udostępnienie demo, to mieliśmy aplikację w wersji demo i bazę danych w wersji demo z danymi demo. Dzięki temu, ja mogłem tylko odpalić sobie program w Pythonie, który tworzył mi całą infrastrukturę, wrzucał aplikację, sprawdzał działanie linka i następnie wysyłał go do klienta. Po tym jak klient przetestował aplikację, mogłem całą infrastrukturę po prostu usunąć.

CDK – Cloud Development Kit

Na koniec, ostatni sposób wykorzystania Pythona, czyli CDK – dosyć zaawansowa metoda tworzenia infrastruktury w Pythonie na chmurze AWS. Przydaje się ona najbardziej w sytuacji, kiedy chcielibyśmy stworzyć kilkaset różnych sieci i do tego podpinać tysiące serwerów, czyli do tworzenia bardzo skomplikowanych infrastruktur i konfigurowania ich między sobą.

CDK działa na dużym poziomie abstrakcji – zamienia setki linii kodu albo nawet tysiące linii kodu na pojedyncze linie. W tym procesie dużo rzeczy działa automatycznie i jest ustawianych domyślnie, co powoduje, że nie musimy się zbyt dużo martwić. AWS CDK działa w oparciu o chmurowe best practice – także zazwyczaj zyskujemy bardzo dobrze skonfigurowane sieci.

Jeśli chcesz wypróbować demo, żeby zobaczyć, jak wygląda CDK w praktyce, to polecam warsztat Amazonowy: https://www.tomeksapalski.pl/cdkdemo

To już wszystko w dzisiejszym wpisie. Na koniec, chciałbym Was bardzo serdecznie zaprosić do obejrzenia mojego darmowego video, z którego dowiecie się, jak działa Python na AWS i jak postawić swoje pierwsze kroki w Amazon Web Services. Jeśli jesteście zainteresowani, zajrzyjcie tutaj:
https://www.tomeksapalski.pl/awsdemo