Migracja z Heroku do AWS

Cele

Migracja z Heroku do AWS jest zazwyczaj motywowana chęcią obniżenia kosztów lub poprawy skalowalności aplikacji. W przypadku tego projektu konieczne było wdrożenie tzw. PAM (Privileged Account Management), który współpracuje z AWS, ale nie jest kompatybilny z Heroku.

Ponieważ klient końcowy działał w sektorze finansowym, duży nacisk położono na kwestie bezpieczeństwa. PAM zapewnia większą kontrolę nad systemem, wgląd w historię logowań i inne mechanizmy zwiększające bezpieczeństwo. Dodatkowo klient oczekiwał stworzenia skalowalnego, wysoko dostępnego środowiska zarówno dla produkcji, jak i developmentu.

Devopsity zostało zatrudnione do projektu przez software house obsługujący klienta końcowego - firmę Ideamotive. Firma rozważała dwie oferty, a decyzję podjęto ostatecznie na podstawie wewnętrznej rekomendacji - Devopsity i Ideamotive współpracowały wcześniej, m.in. przy migracji z Heroku do AWS.

Metody

Pierwszym krokiem był audyt istniejących zasobów w Heroku, SemaphoreCI i Cloudflare. Zespół szczegółowo przeanalizował, z jakich usług korzysta aplikacja, jak została zbudowana i jakie istnieją zależności między jej komponentami oraz mikroserwisami. Następnie sprawdzono już istniejące zasoby w AWS, ponieważ część z nich była już wcześniej tworzona i wykorzystywana przez aplikację.

Kolejnym etapem był wybór usług AWS, które mogłyby w pełni zastąpić rozwiązania dostępne w Heroku, oraz zaprojektowanie architektury zgodnej z najlepszymi praktykami w zakresie bezpieczeństwa, niezawodności i skalowalności. Po jej zaprojektowaniu środowisko developmentowe zostało przeniesione na nową infrastrukturę, aby przetestować działanie aplikacji. Równolegle przygotowano proces CI/CD oraz system monitorowania wszystkich usług dla środowiska AWS.

Po zakończeniu audytu i przygotowaniu architektury zespół Devopsity przystąpił do prac wdrożeniowych. Korzystając z narzędzia Terragrunt, rozpoczęto tworzenie poszczególnych komponentów infrastruktury oraz konteneryzację aplikacji z Heroku (jako środowisko uruchomieniowe wybrano ECS Fargate).

Stworzono następujące komponenty infrastruktury:

• Compute / Workload – ECS
• PostgreSQL – RDS
• ElasticSearch – OpenSearch
• Redis – ElastiCache
• Cron Scheduler – EventBridge
• Zmienne środowiskowe – Systems Manager
• Load Balancer – Application Load Balancer
• Zawartość statyczna – CloudFront + S3
• Rejestr kontenerów – ECR

Po przygotowaniu tych elementów rozpoczęto proces migracji aplikacji do ECS. Dla każdego komponentu aplikacji utworzono odpowiednią usługę w ECS, a w razie potrzeby dołączano Application Load Balancer. Po połączeniu wszystkich części aplikacja działała zgodnie z oczekiwaniami, a wszelkie błędy konfiguracyjne były rejestrowane i analizowane za pomocą CloudWatch, gdzie skonfigurowano oddzielne logi dla każdego komponentu.

W czasie gdy aplikacja była testowana przez QA, zespół rozpoczął budowę procesu CI/CD dla nowego środowiska, wykorzystując istniejące narzędzie w projekcie – SemaphoreCI. Było to pierwsze zetknięcie zespołu z tym narzędziem, ale okazało się ono intuicyjne, a różnice w składni YAML w porównaniu do innych narzędzi CI/CD nie były znaczące. Dzięki temu udało się sprawnie zbudować cały proces budowania i wdrażania aplikacji do ECS oraz dystrybucji zawartości statycznej przez S3 + CloudFront.

Wyzwania, z którymi zespół musiał się zmierzyć podczas realizacji projektu:

• Konteneryzacja aplikacji oraz przekazywanie sekretów podczas budowania i uruchamiania aplikacji
• Dynamiczne generowanie definicji zadań z nową wersją obrazu podczas procesu budowania i wdrażania aplikacji
• Stworzenie rozwiązania umożliwiającego programistom łatwe dodawanie własnych zadań cron (EventBridge + ECS)
• Automatyczne czyszczenie nieużywanych obrazów w ECR