Artykuł ma na celu przybliżenie usług w chmurze AWS, szczególnie tych, które powtarzają się prawie w każdym z systemów. Artykuł poprowadzi przez najistotniejsze punkty, wyjaśniając kontekst technologiczny i biznesowy każdego z nich. W drugiej części dowiesz się jak to wszystko ze sobą połączyć i uzyskać zamierzony efekt – wdrożenie skonteneryzowanej aplikacji w chmurze AWS.
Zagadnienia, jakie będą poruszane to:
- Co to jest AWS
- Jak przenieść aplikację na AWS
- Z jakich komponentów składa się AWS
- Czym jest CDK i do czego służy
AWS – krótki słowniczek technologiczny
ECS (Elastic Container Service) – usługa do uruchamiania i zarządzania instancjami aplikacji zbudowanej przy pomocy obrazu Dockera
ECR (Elastic Container Registry) – usługa, do przechowywania zbudowanego obrazu dockerowego
Subnet – grupa adresów IP, którymi będziemy się posługiwać
Security Group – grupa reguł zabezpieczających sieć
S3 – dysk w chmurze z plikami
NFS – Network File System – protokół dzięki, któremu można zdalnie podpiąć się do dysku
EFS – Elastic File System – usługa, dzięki której można przechowywać pliki tymczasowe
CDK – Cloud Development Kit – narzędzie do tworzenia zasobów w AWS, dzięki znajomości języków programowania np. Python
VPC – Virtual Private Cloud – Usługa, która separuje usługi, dzięki czemu domyślnie nikt inny nie ma do nich dostępu.
Wstęp do systemu
Rozpoczynając nowy dzień w pracy, w końcu dostałeś swojego pierwszego taska. Klient chce wrzucić gotową aplikację na chmurę. Z tego co ustaliliście, aplikacja jest napisana w x i y. Dopytując się klienta o dokładniejsze informacje, dowiedziałeś się, iż w tej chwili leży ona na jakimś wykupionym serwerze on premise.
Może to brzmieć jak pułapka, gdzie ktoś manualnie uruchamia cały stos aplikacji. Powodem przejścia, jaki klient podał, był coraz większy problem z wydajnością aplikacji, szczególnie w krajach położonych dalej od naszego serwera. Wzrósł też koszt utrzymywania aplikacji i reagowania na awarię.
Wspólnie z klientem ustaliliście, iż aplikację przeniesiecie na Amazon Web Services i postaracie się wykorzystać jego serwisy do niezawodności i skalowalności.
Po zrobieniu audytu zauważyłeś kilka elementów, które będą wymagały szerszego zakresu prac. Elementem pierwszym jest skonteneryzowanie aplikacji używając Dockera. Będziesz chciał stworzyć obrazy zarówno dla frontendu, jak i backendu.
Kolejnym elementem jest wrzucenie tekstów w postaci prostego pliku txt na serwer wraz z możliwością podpięcia ich do działającego serwisu.
I najwięcej pracy to dzięki narzędzia CDK móc stworzyć i zarządzać infrastrukturą systemu. Pozwoli to na zautomatyzowanie systemu.
Architektura systemu na AWS
Architektura została przedstawiona w narzędziu miro, w którym to rozrysowana jest graficznie struktura. Nie martw się, jeżeli nie znasz tych usług, albo tego co się tutaj dzieje. W kolejnej części będzie dokładnie opisane punkt po punkcie, co się tutaj dzieje. Zawsze możesz tutaj wrócić ponownie.
To odtworzenia systemu będzie potrzebne konto na AWS, najlepiej free tier: https://aws.amazon.com/free/?all-free-tier=.
Opis komponentów w chmurze AWS
Cały produkt i jego architektura komponują się w jeden spójny system. Jest to istotne, ponieważ należy pamiętać o tym, żeby minimalizować ilość komponentów, aby mieć prostszą kontrolę nad zasobami i bezpieczeństwem.
Warto także stworzyć szablon systemu, z użyciem wszystkich narzędzi, które mogą okazać się wartościowe. Dzięki temu podejściu będzie łatwiej przewidzieć koszty, jak i niezbędne zasoby. Czasami niedoszacowanie kosztów może skończyć się z rachunkiem na kwoty rzędu 20 tysięcy dolarów.
W systemie są dwie części, które można podzielić na zarządzanie stanem systemu, i drugą część, gdzie aplikacja będzie działać. W pierwszej części znajdują się CloudFormation i Amazon Elastic Container Registry.
Usługa CloudFormation zawiera w sobie wszystkie informacje o utworzonych zasobach, które zdefiniujemy dzięki narzędzia CDK. Głównym pojęciem jest Stack. Oznacza on po prostu całość różnych serwisów połączonych ze sobą i zależnych od siebie. Czyli jeżeli chcesz wrzucić i utworzyć aplikację, to przyda się do tego i ustawienie API Gateway do podpięcia z publicznym internetem, jak i możliwość wrzucania i odczytania plików.
Drugą usługą jest AWS Container Registry, do którego zostanie wrzucony obraz dockerowy. Jest kilka sposobów na umieszczenie go tam. Jednym z nich jest przez wrzucenie artefaktu z procesu CI/CD. Innym to użycie CDK i przy jego pomocy umieszczenie obrazu dockerowego. Ten sposób poznasz w kolejnym artykule. Jak się przekonasz narzędzie CDK ma duży zasób możliwości.
Teraz najistotniejsza część, czyli działająca aplikacja na chmurze.
Sercem aplikacji jest Elastic Container Service, czyli usługa, która pozwala na stworzenie niezależnych klastrów ze zbudowanymi obrazami dockerowymi. Każda instancja obrazu jest nazywana Taskiem. To, co umożliwia ECS to skalowanie horyzontalne, monitoring, zarządzanie wersjami obrazów, jak ustawień instancji. Task daje szeroki zasób możliwości i łatwą kontrolę nad zabezpieczeniami, ustawieniami, logowaniem i bardzo szybką możliwością skalowania wertykalnie instancji.
Tutaj można doszukać się typowych opcji, które wyświetlą się przy komendzie docker run. I tutaj warto wspomnieć o Task Definition, czyli w dużym uproszczeniu opisie AWSowego kontenera. Można ustawić, jakie zasoby są potrzebne, a także opcje montowania, logowanie oraz wiele więcej…
Następne są usługi, dzięki którym będzie można zapisywać i odczytywać pliki.
Główną usługą, jaka obsługuje pliki jest S3. Jest to ogromna i globalna usługa, dzięki której można stworzyć własną przestrzeń z plikami, która nazywa się bucketem. Co istotne, przez to, iż usługa ta jest tania, ma swoje ograniczenia. Jednym z nich jest nazwa bucketu, która musi być unikalna.
Kolejnym ograniczeniem jest czas przetwarzania. W domyślnej usłudze, bez dodatkowych opcji, czas na przetworzenie pliku nie jest rewelacyjny. Mimo to, w większej części przypadków, bezproblemowy.
To, co jednak można zrobić, żeby mieć pliki podpięte w czasie uruchomienia aplikacji, zostanie stworzone przez kolejną usługę zwaną EFS. Elastic File System można opisać jako taki pendrive, na którym można pracować nad plikami. Jest prosty w użyciu, ale nie ma za dużej pamięci. Jednak dzięki swojej przenoszalności EFS można używać dla wielu instancji. I co najważniejsze jest bardzo szybkim nośnikiem.
Dlatego to, co będziemy chcieli uzyskać to przy utworzeniu instancji aplikacji podmontujemy EFS, wrzucimy z S3 wszystkie potrzebne pliki i będziemy go traktować jako miejsce do operacji na plikach. A co jakiś czas będziemy wykorzystywać synchronizację z S3.
Ostatnim punktem podróży po systemie są serwisy pozwalające na połączenie z publicznym internetem i problemu w przypadku dużego ruchu.
Standardowa usługa do udostępnienia usług publicznie w AWS nazywa się API Gateway. Daje ona możliwość kontroli i zabezpieczenia serwisów. Umożliwia również podpięcie w prosty sposób z usługą Load Balancera, który to ten ruch rozłoży na wiele instancji.
Czym jest CDK i dlaczego został wykorzystany do projektu?
CDK inaczej Cloud Development Kit. Jest to narzędzie Infrastructure as a Code, które transpiluje język np. JavaScript do języka CloudFormation (CF). Język CF jest to “natywny” język dla chmury AWS, za pomocą którego można stworzyć zasoby, zarządzać ich ustawieniami i łączyć ze sobą.
Alternatywą do tego narzędzia jest natywny język CF, Terraform, jak i SAM. To, co jest najważniejsze to, iż CDK jest pisany w języku programistycznym, przez co można łatwo w nim tworzyć, jak i testować natywnymi dla wybranego języka frameworkami.
Opis projektu
Aplikacja będzie się składała z trzech osobnych serwisów. Podejdziemy do tego metodologią monorepo, czyli każda część będzie w osobnym folderze w jednym repository.
Pierwszym modułem jest web, który to wykorzystuje framework Next.js, czyli nakładkę na Reacta. Będziemy wykorzystywać Server Side Rendering, przez co rozwiązanie będzie potrzebowało serwera. Pierwszym wyborem jest Nginx. Drugi moduł będzie zawierał w sobie API.
Kluczowym modułem będzie miejsce, gdzie tworzy się infrastrukturę. Nazwa adekwatna do tego to infrastructure. W nim znajdą się wszystkie skrypty CDK.
Podsumowanie
W Część pierwsza artykułu przechodzi przez wszystkie puzzle większej układanki. Mogliśmy zobaczyć wymagania biznesowe, których rozwiązanie zaprojektowaliśmy dzięki usług AWS. Udało się przejść przez każdą z usług i poznać jej znaczenie w całej aplikacji. Ostatnim punktem było poznanie technologi aplikacji i decyzji, dlaczego została ona wybrana.
W kolejnej części zobaczymy implementację kodu, jak i użycie narzędzi do przygotowania zasobów, żeby móc go wdrożyć na chmurę.
Autor
Mateusz Kubaszek — jest w świecie IT już od ponad 10 lat. w tej chwili mocno stara się rozwijać w tematyce solution architecture i distributed systems (w tym mocno w chmurach). Udało mu się brać udział w kilku ciekawych projektach, które są wykorzystywane w życiu codziennym. Poza pracą stara się mocno promować programowanie funkcyjne, multicloud, Event Storming i DDD. Prywatnie mąż i niedawno awansowany ojciec. Uwielbia chodzić po górach, grać w szachy, czytać fantastykę i jeść pizzę.