Support 24/7: +48 61 646 07 77
Z artykułu dowiesz się:
Pacific.org to poznański startup oferujący rozwiązania z zakresu technologii finansowych. Jego głównym produktem jest aplikacja mobilna, którą nazwano również Pacific.org.
Aplikacja ta oferuje m.in. takie funkcjonalności jak:
Aplikacja jest dostępna zarówno na telefony z systemem Android, jak i te z iOS. Jednym z priorytetów firmy jest dbanie o środowisko (np. karty płatnicze oferowane przez Pacific.org są stworzone z plastiku pozyskanego ze śmieci zalegających w morzach i oceanach).
Dodatkowo, spółka przeznacza 0,1% każdej transakcji płatniczej wykonanej za pomocą wspomnianych wyżej kart na rzecz fundacji oczyszczającej oceany. Więcej o tym projekcie tutaj.
Pacific.org zwrócił się do Centurii w maju 2021, poszukując profesjonalnego wsparcia w zakresie usług DevOps.
Naszym zadaniem było wdrożenie środowiska API Pacific w ramach chmury publicznej Google Cloud Platform oraz pomoc we wdrożeniu procesu CI/CD dla tej aplikacji. Z systemem tym łączy się aplikacja mobilna, a on sam komunikuje się z systemami informatycznymi banku.
Po okresie wdrożenia Centuria miała zająć się utrzymaniem wdrożonego systemu w trybie 24/7, zgodnie z wymaganiami klienta.
Aplikacja API od samego początku była tworzona i testowana przez Pacific.org w ramach chmury publicznej Google Cloud.
Partner zgłosił się do nas z gotową wizją, która zakładała jak największe użycie technologii cloud‑native oferowanych przez GCP. W szczególności potrzebne było zaprojektowanie infrastruktury pod kątem sieciowym, zapewnienie bezpiecznego dostępu VPN oraz szyfrowanej łączności site‑to‑site z systemami banku.
Dodatkowo, otrzymaliśmy prośbę dotyczącą przeprowadzenia migracji repozytorium kodu z Bitbucket na Gitlab, ze względu na dość częste problemy z dostępnością i niestabilność jej działania.
Tak, jak wspomnieliśmy wcześniej, projekt od początku był tworzony w GCP, więc tutaj przeniesienie do innego dostawcy nie było nawet rozważane. W teorii byłoby to oczywiście możliwe, ale oznaczałoby dla Pacific.org dodatkowy koszt i przede wszystkich znacznie dłuższy time‑to‑market.
Warto również podkreślić, że aplikacja mobilna korzysta z technologii Google, więc dzięki temu całość projektu pozostała spójna i istnieje możliwość centralnego zarządzania kwestią dostępów do jej zasobów za pomocą Google IAM.
Naszym zdaniem Google IAM jest świetnym narzędziem, w szczególności w połączeniu z Google Workspace lub jego darmową wersją, czyli Cloud Identity (którą w Centurii z powodzeniem wykorzystujemy).
Dużą zaletą Google Cloud jest na pewno jej obecność w Polsce. 13 kwietnia 2021 oficjalnie został otwarty region dla Google Cloud w Warszawie.
Istnieje jednak również kilka wad tego rozwiązania, które wynikają głównie z jego dynamicznego rozwoju:
W fazie wczesnego rozwoju aplikacja była budowana i utrzymywana w ramach jednego projektu GCP.
Po przejściu w fazę przedprodukcyjną otrzymaliśmy zadanie utworzenia oddzielnych projektów dla środowisk:
Dodatkowo potrzebne było wyniesienie do osobnych projektów środowisk:
W przypadku środowisk rozwojowych (dev i uat) stworzyliśmy mechanizm pozwalający na automatyczne okresowe wyłączanie zasobów i w konsekwencji realne oszczędności finansowe.
Do deploymentu środowiska użyliśmy narzędzia Terraform autorstwa firmy HashiCorp. Więcej informacji o narzędziu tutaj. Dzięki niemu uzyskaliśmy wersjonowanie konfiguracji i powtarzalności tworzonych środowisk.
Tak jak wcześniej wspomnieliśmy, interfejs GCP nie zawsze jest do końca przejrzysty. Wszystko da się oczywiście “wyklikać”, ale nawet przy dużej sprawności w tym temacie łatwo o czymś zapomnieć i w konsekwencji stracić długie godziny na diagnostykę.
Przygotowanie kodu modułów Terraform oznacza konieczność jednorazowego poświęcenia czasu, ale ta inwestycja zwraca się z nawiązką.
GCP na tę chwilę nie oferuje usługi VPN typu dial‑up. W związku z tym potrzebne było wybranie rozwiązania skalowalnego, łatwego w obsłudze, w rozsądnej cenie… a także będącego standardem branżowym. Razem z Pacific.org wybraliśmy OpenVPN Access Server.
Ma on wiele zalet:
Jedyną wadą tego rozwiązania jest fakt, że… nie jest to rozwiązanie Google typu cloud‑native 😊 Jeśli takowe by się pojawiło, to na pewno rozważylibyśmy jego użycie.
Użyty został Classic VPN, ponieważ HA VPN ma ograniczenia dotyczące zestawiania tuneli w ramach adresacji Google.
Jedyną opcją jest użycie HA VPN po obu stronach (co w naszym przypadku nie było możliwe). Zgodnie z dokumentacją samego Google: “HA VPN rejects Google Cloud IP addresses when they are configured in an external VPN gateway resource—for example, using the external IP address of a VM instance as the external IP address for the external VPN gateway resource. The only supported HA VPN topology between Google Cloud networks is where HA VPN is used on both sides,(…)”. Więcej informacji na temat tego rozwiązania tutaj.
Potrzebowaliśmy połączenia środowiska aplikacyjnego (dev,uat,prod) z monitoring‑logs. Tutaj świetnie sprawdził się VPC Peering – rozwiązanie bardzo proste do wdrożenia, eliminujące dodatkowe tunele site‑to‑site. Więcej szczegółów na temat VPC Peering tutaj.
Google Cloud DNS
To kolejny element typu cloud‑native. Pozwala na tworzenie prywatnych stref DNS, a także nadpisywanie publicznych wpisów.
Jego użycie znacząco ułatwia rozwijanie aplikacji, ponieważ umożliwia zastosowanie w kodzie nazw DNS, które są potem rozwiązywane przez Google Cloud DNS. Więcej o Google Cloud DNS tutaj.
Umożliwia proste i bezpieczne zarządzanie wszystkimi hasłami, tokenami, itd., których używa aplikacja. Dostęp ograniczany jest przez IAM.
Wady tego rozwiązania: nie każda usługa na tę chwilę jest w stanie bezpośrednio korzystać z Google Secret Managera (GSM). Przykładowo, GKE w tym momencie nie jest w stanie korzystać z certyfikatów SSL umieszczonych w GSM. Można mieć tylko nadzieję, że sytuacja się zmieni w przyszłości. Więcej informacji o Google Secret Manager tutaj.
Aplikacja API jest tutaj w pełni skonteneryzowana. To de facto modularny monolit, który korzysta z zewnętrznych usług (Cloud SQL i Elasticsearch). Kubernetes w Google ma sporo zalet.
Przede wszystkim autorem Kubernetes jest Google i to Google wypuściło pierwszy managed Kubernetes w 2015 roku.
Dodatkowo GKE jest, naszym zdaniem, najbardziej elastycznym rozwiązaniem tego typu. Ma, w porównaniu do Azure AKS i Amazon EKS, największą liczbę dostępnych wersji k8s (więcej informacji tutaj). Dobrze działa automatyczny upgrade control plane i node pool.
Każdy node może mieć włączoną opcję auto‑repair, która (jak sama nazwa wskazuje) jest w stanie przywrócić go do życia w wypadku problemów (więcej informacji tutaj).
Node’y używają Container‑Optimized OS, który został specjalnie stworzony i zoptymalizowany przez Google pod kątem obsługi kontenerów (więcej informacji tutaj).
Zarządzanie GKE możliwe jest z poziomu WebGUI, ale największą siłę ma jednak command line (więcej informacji tutaj).
Oczywiście, jeśli w swoim projekcie używamy konkretnych rozwiązań Microsoft lub Amazon, to użycie GKE niekoniecznie jest najlepszym wyjściem. Czas, który moglibyśmy wykorzystać na rozwijanie aplikacji stracimy na tworzenie i utrzymywanie integracji.
W naszym przypadku, jednak od początku chodziło o wykorzystanie usług Google, zatem nie było lepszej alternatywy niż wykorzystanie GKE.
GKE można polecić również dla projektów hybrydowych (on‑premise + cloud) oraz tych, które nie są wprost związane z jednym vendorem.
API korzysta z bazy PostgreSQL. Użycie natywnego Google Cloud SQL znacząco upraszcza zarządzanie instancją. Można kilkoma kliknięciami ustawić HA, automatyczne backupowanie bazy… a przywrócenie bazy jest równie proste. Więcej informacji o Google Cloud SQL tutaj.
Początkowo chcieliśmy użyć Elastic Cloud SaaS, natomiast w momencie uruchamiania projektu nie było możliwości zestawienia bezpiecznego (prywatnego) połączenia z GCP.
Z tego powodu zdecydowaliśmy się na Elastic Cloud on Kubernetes. W przyszłości to rozwiązanie daje możliwość łatwej migracji na Elastic Cloud SaaS, jeśli pojawi się taka potrzeba.
9 września 2021 ogłoszono możliwość użycia Google Cloud Private Service Connect, szczegółowe informacje na ten temat znajdziesz tutaj.
Pierwotnie zakładaliśmy, że cała aplikacja będzie budowana i testowana na Cloud Build. Niestety – wykryliśmy ograniczenia, które to uniemożliwiły.
O ile samo budowanie aplikacji nie sprawiało większych problemów, to testowanie w naszym przypadku wymagało bezpośredniego dostępu do usług (testowa baza danych Cloud SQL oraz instancja Elasticsearch).
Google dopiero sierpniu 2021 udostępniło Cloud Build Private Pools, które pozwalają na proste łączenie Cloud Build z VPC.
Próbowaliśmy również zrealizować budowanie obrazów bezpośrednio na Kubernetes z użyciem Kaniko, jednak problemy z cache spowodowały porzucenie tego pomysłu.
Problemy z Kaniko spowodowały zmianę koncepcji i powrót do Dockera, który był wcześniej wykorzystywany lokalnie przez deweloperów.
Ostatecznie zrezygnowaliśmy z Cloud Build na rzecz Gitlab, który początkowo tylko pełnił rolę repozytorium kodu i uruchamiał Cloud Build (gdzie był uruchamiany pipeline).
Aktualnie cały pipeline został przeniesiony do Gitlab, a budowanie i testowanie aplikacji odbywa się na maszynie wirtualnej z zainstalowanym Dockerem i Gitlab Runner.
Ze względu na dość specyficzne wymagania Klienta zaproponowaliśmy wdrożenie dedykowanego, zewnętrznego (ale hostowanego również w GCP) oprogramowania do monitoringu.
Dane zbierane są w ramach konkretnego środowiska i przesyłane do centralnej instancji umieszczonej w środowisku monitoring‑logs. Dodatkowo dane z monitoringu przesyłane są do naszej wewnętrznej instancji Prometheus, której Centuria ServiceDesk używa do monitoringu 24/7.
Wewnętrzne rozwiązanie do przechowywania i analizy logów (Google Cloud Logging) jest dosyć ciężkie i mało elastyczne. Dlatego wybraliśmy Graylog (darmowe oprogramowanie oparte na stacku ELK).
Jednym z naszych dodatkowych zadań było stworzenie automatyki wykrywającej numery kart kredytowych, które potencjalnie mogą być w jakiś sposób przetwarzane przez aplikację (a nie powinny).
Mieliśmy zamiar zrealizować temat za pomocą Grayloga, jednak okazało się to niemożliwe, ze względu na ograniczenia Elasticsearch, z którego sam Graylog korzysta.
Ostatecznie jako pośrednią warstwę filtrującą użyliśmy Fluent Bit, który sprawdził się bardzo dobrze w tej roli.
Aplikacja działa już produkcyjnie! Zespół programistów intensywnie pracuje nad nowymi wersjami i nowymi funkcjonalnościami. Ilość użytkowników aplikacji sukcesywnie rośnie.
Na pewno konieczna będzie dalsza analiza obciążenia infrastruktury, a także (być może) przeskalowanie zasobów. Z racji tego, że infrastruktura działa już kilka miesięcy i obserwujemy trendy zużycia zasobów, kolejnym krokiem będzie także skorzystanie ze zniżek związanych z jedno lub kilkuletnim commitmentem na zasoby.
Dobór odpowiedniego planu może znacznie obniżyć koszty infrastruktury o nawet kilkadziesiąt procent.
Dodatkowe informacje na temat zniżek związanych z commitmentem znajdziesz tutaj.
Przed nami także dużo żmudniejsza, ale równie ważna praca związana:
![Bezpieczeństwo środowisk testowych [krótki poradnik dla DevOps/SysOps]](https://centuria.pl/wp-content/uploads/2022/09/07-12-bezpieczenstwo-srodowisk-424x228.jpg)
