Migracja do chmury i inżynieria platform

Żeby przenieść platformę z OVH na AWS, buduje się środowisko docelowe w kodzie, sprawdza je na środowisku testowym z zanonimizowanymi danymi, przenosi bazę i dopiero potem przełącza produkcję, a stare serwery zostawia do czasu, aż powstanie kopia zapasowa. Tak przebiegła migracja Ticket Club, platformy do sprzedaży biletów na wydarzenia. Produkcja przeszła na AWS 3 września 2024 roku, a przełączenie odbyło się bez przestoju. Stare instancje OVH zarchiwizowano jako kopię zapasową i wyłączono 1 października 2024 roku.

Budowa środowiska docelowego

Napisaliśmy kod Terraform, który tworzy infrastrukturę pod wdrażanie kontenerów na ECS, i skonfigurowaliśmy CI/CD w GitHub Actions. Baza Ticket Club ma triggery, więc przeniesienie jej danych do nowej bazy było osobnym zadaniem, nastawionym na spójność danych. Do nowego środowiska testowego przygotowaliśmy zanonimizowaną kopię produkcji i skopiowaliśmy na nie media oraz zasoby produkcyjne. Te prace trwały od listopada 2023 do lutego 2024 roku.

Kontenery, sekrety i monitoring

W marcu i kwietniu 2024 roku zaszyfrowaliśmy sekrety w sops, wydzieliliśmy osobne miejsce do uruchamiania zadań cron, udostępniliśmy dane geoip między kontenerami ECS i uruchomiliśmy komunikację websocket między kontenerami w klastrze. Do monitoringu aplikacji po przeniesieniu wybraliśmy Sentry, po porównaniu go z alarmami CloudWatch.

1. Start projektu: zbieramy dostępy do repozytorium, AWS, plików środowiskowych oraz środowisk produkcyjnego i testowego, a także ustalamy zasady code review, pokrycia testami i hooków pre-commit. Tydzień po dołączeniu nowej osoby do projektu pytamy ją o opinię: czy zna założenia, czy ma wiedzę potrzebną do pracy i czy wie, do kogo się zwrócić.
2. Inwentaryzacja: gdy infrastruktura już istnieje, pierwszym krokiem jest sprawdzenie istniejących zasobów AWS i kodu Terraform. Tak zaczęliśmy w Centrum Komunikacji, platformie z tłumaczem języka migowego dla Polskiego Związku Głuchych, przed konfiguracją infrastruktury wdrożeniowej.
3. Środowisko w kodzie: Terraform tworzy środowisko, a CI/CD wdraża na nie aplikację.
4. Środowisko testowe z danymi: powstaje przed produkcją i dostaje dane, dzięki którym zachowuje się jak produkcja.
5. Migracja danych: baza z triggerami dostaje osobne zadanie na spójność danych.
6. Przełączenie produkcji: ruch przechodzi na nowe środowisko.
7. Wygaszenie starego środowiska: stare serwery najpierw archiwizujemy, potem wyłączamy.

Infrastruktura jako kod oznacza, że każdy zasób chmurowy jest opisany w wersjonowanych plikach, a migracja wprowadza istniejące zasoby do tego opisu.

Enerace: Terraform zastępuje CloudFormation

Enerace, platforma do zakupu energii, działała na CloudFormation od 13 listopada 2019 roku. Terraform przejął ją 20 lutego 2023 roku na środowisku testowym i 27 lutego 2023 roku na produkcji. Infrastruktura AWS mieści się dziś w module backendu Terraform z 15 plików: sieć, grupy bezpieczeństwa, load balancer, IAM, logi, S3, Redis, RDS, parametry SSM, ECS, DNS i sekrety. Środowisko testowe i produkcyjne mają osobne korzenie Terraforma. Przenieśliśmy też repozytoria front-endu, back-endu i aplikacji mobilnej z GitLaba na GitHub, a CI z GitLab CI na GitHub Actions.

Zeronest: Lambdy i API w Terraformie

Zeronest, platforma do zarządzania energią, działa na pełnym stosie AWS: ECS, RDS, S3, Lambda, Cognito i SNS, zarządzanym w Terraformie. Funkcje Lambda przenieśliśmy do Terraforma między 19 a 24 czerwca 2024 roku, API do 26 czerwca 2024 roku, a kod Terraform zweryfikowaliśmy do 17 lipca 2024 roku. Od stycznia do kwietnia 2025 roku usunęliśmy z produkcji nieużywane zasoby (funkcje Lambda ETL, scheduler i DynamoDB), gdy przetwarzanie przeszło na Django i PostgreSQL.

Żeby przenieść bazę z MS SQL na PostgreSQL, przenosi się schemat i dane, a potem dostosowuje dialekt SQL w kodzie aplikacji.

Odejście od MS SQL

W 2025 roku przenieśliśmy na PostgreSQL system firmy produkującej oprogramowanie do centrów monitoringu. Przygotowaliśmy procedury i konfigurację wdrożeń, a potem zmigrowaliśmy schemat i dane. Przeanalizowaliśmy zmiany dialektu SQL w kodzie Pascala i zautomatyzowaliśmy je. Przeszkoliliśmy zespół klienta z PostgreSQL i jego administracji. Na koniec zaprojektowaliśmy replikację, failover i wysoką dostępność dla środowiska Windows.

Replikacja w czasie rzeczywistym z RDS

Dla klienta z branży fintech uruchomiliśmy replikację danych w czasie rzeczywistym z Amazon RDS do Microsoft SQL Server przez AWS Database Migration Service. Tunel VPN między AWS a infrastrukturą partnera klienta dawał dostęp do brokera Kafka.

W Centrum Komunikacji hosting i dane zostają w UE. Ruch idzie wyłącznie przez TLS 1.3, a load balancer rozmawia z serwerami przez mTLS. Dostęp prowadzi przez VPN, wdrożenia idą tylko przez tunel, a SSH jest zamknięte od zewnątrz. Panel administratora ma uwierzytelnianie dwuskładnikowe. Monitoring łączy SIEM Wazuh z ELK, Grafaną i Sentry. Baza to klaster PostgreSQL z failoverem, Redis działa z Sentinel, a własny LiveKit skaluje instancje automatycznie. Przejrzeliśmy też i ograniczyliśmy zewnętrzne dostępy do infrastruktury.

Zeronest loguje użytkowników jednorazowym kodem przez Cognito, a logowanie hasłem wyłączono w styczniu 2025 roku.

Jak postępujemy z danymi klientów

Każdy projekt ma umowę powierzenia przetwarzania danych i imienne konta. Korzystamy z AWS IAM Identity Center i zasady najmniejszych uprawnień, a dyski są szyfrowane. Incydent zgłaszamy najpóźniej w ciągu 24 godzin, a dane usuwamy lub zwracamy w ciągu 10 dni roboczych. Na starcie projektu wpisujemy go do rejestrów RODO, a przy zmianie składu zespołu aktualizujemy, kto ma dostęp do danych. Od 9 października 2026 roku działa wewnętrzne narzędzie do śledzenia dostępów. Więcej na stronie Bezpieczeństwo i RODO.

Pipeline'y CI/CD przenoszą kod z repozytorium na środowisko produkcyjne, a praca DevOps obejmuje pipeline'y, kod infrastruktury i standardy wokół nich.

Centrum Komunikacji

Centrum Komunikacji ma pipeline wdrożeniowy produkcji dla front-endu, back-endu i serwera mediów oraz produkcyjny pipeline aplikacji mobilnych na iOS i Androida. Migracje bazy i pliki statyczne to osobne zadania wdrożeniowe, co skraca wdrożenia. Zoptymalizowaliśmy też konfigurację Nginx, Daphne i Django.

Zeronest i Enerace

Pipeline GitHub Actions w Zeronest buduje obraz Docker, wysyła go do ECR (osobne repozytorium obrazów na każde środowisko), uruchamia Terraform dla modułu backendu, a potem skrypt po wdrożeniu. Wdrożenia z gałęzi dev, release/staging i main działają automatycznie od 5 sierpnia 2024 roku, a status wdrożenia trafia na Slacka od 4 kwietnia 2025 roku.

Back-end Enerace jest wdrażany przez GitHub Actions od 5 sierpnia 2024 roku, a wcześniej działał GitLab CI, używany od 18 listopada 2021 roku. Pipeline buduje obrazy Django i Nginx, wysyła je do ECR i wdraża Terraformem: środowisko testowe z gałęzi release/staging, produkcję z mastera. Przy pull requestach działają lint, sprawdzanie formatowania i testy w kontenerze z tymczasową bazą PostgreSQL.

Azure, aplikacje mobilne i nasze standardy

Dla Skyfri prowadzimy CI/CD w Azure DevOps, używamy Terraforma zamiast ARM Templates i Azure CLI, a kolejne serwisy objęliśmy pełnym CI/CD i infrastrukturą jako kodem. Dla klienta z aplikacją mobilną wdrażamy buildy na iOS i Androida przez Fastlane i GitHub Actions. Produkcja i środowisko deweloperskie mają osobne projekty Firebase, a cotygodniowy alert na Slacku ostrzega o wygasających certyfikatach Apple. Wewnętrznie utrzymujemy obraz CI dla Terraforma i standard zmiennych środowiskowych w Terraformie, a w 2024 roku przeszkoliliśmy zespół z Terraforma.

Kyoto Group to norweska firma od magazynowania energii cieplnej. W 2024 roku skonfigurowaliśmy dla niej load balancer AWS z uwierzytelnianiem OIDC względem Azure Entra ID i stopniowo zautomatyzowaliśmy wdrażanie.

Enerace codziennie importuje dane z kilku źródeł rynku energii: ICE, ENTSO-E, AGSI/ALSI, TGE i PSE. Dla innego klienta zbudowaliśmy platformę dla trzech marek, które współdzielą jedną bazę użytkowników w AWS Cognito i są zintegrowane z systemem automatyzacji marketingu. Platforma działa na AWS (ECS, Lambda, S3, RDS i CloudFront) i jest zarządzana w Terraformie.

Zeronest na produkcji

Produkcja Zeronest uruchamia API i workery Celery na ECS, PostgreSQL w RDS z repliką odczytową, Redis (Valkey) w ElastiCache oraz load balancer. Logi trafiają do osobnych grup logów CloudWatch, a w całość wpięty jest Sentry. Przestrzeń RDS rośnie automatycznie dzięki ustawieniu trzymanemu w Terraformie, a alert ostrzega o braku danych albo zatkanej kolejce Celery.

Dane monitoringu Celery zostają teraz w Redisie przez 6 godzin zamiast 24, a cache Django leży w osobnej bazie logicznej. Razem te zmiany obniżyły zajętość pamięci Valkey z około 99,8% do około 52,7%, bez zmiany wielkości instancji.

Enerace na ECS Fargate

Enerace uruchamia aplikację Django i Celery jako osobne usługi Fargate. Usługa Django skaluje się automatycznie według obciążenia CPU z celem 60%, od 1 do 4 zadań, a może też skalować się według pamięci i liczby żądań na cel.

Trzynaście alarmów CloudWatch obejmuje RDS (CPU, wolne miejsce, opóźnienia odczytu i zapisu, wolną pamięć), Redisa (CPU, pamięć, wypieranie kluczy), ECS (CPU i pamięć osobno dla Django i Celery) oraz czas odpowiedzi load balancera.

PostgreSQL w RDS przechowuje kopie zapasowe przez 14 dni, a Redis 7 w ElastiCache replikuje dane między kilkoma strefami. Konfiguracja leży w AWS Parameter Store (39 parametrów) i Secrets Manager, a wersja PostgreSQL 17.11 jest ustawiona w Terraformie. Do kontenerów produkcji logujemy się przez ECS Execute Command, pliki środowiskowe i klucze szyfrujemy ansible-vault, a adresy e-mail anonimizujemy przy każdym kopiowaniu danych produkcji do środowisk testowych.

Praca nad kosztami

Od października 2026 roku optymalizacja kosztów środowiska AWS Ticket Club jest częścią naszego wsparcia i trwa. Dla przemysłowej platformy IoT do inspekcji przygotowaliśmy analizę kosztów infrastruktury oraz wariantów pełnego lub częściowego przejścia z usług zarządzanych na tańsze.

Pracujemy na AWS, Azure i Hetznerze, a AWS jest naszym domyślnym wyborem, bo naszym zdaniem ma najlepsze narzędzia. Większość dowodów na tej stronie pochodzi właśnie stamtąd: w całej firmie zrealizowaliśmy ponad 50 wdrożeń AWS.

Azure w Skyfri

Od stycznia 2024 roku pracujemy przy platformie Skyfri z Azure IoT Hub i Edge, Azure Data Explorer, Databricks i Azure DevOps. Nasi ludzie pracują w zespole klienta. Jego system zarządzania energią obejmuje 7 obiektów, z ponad 5 MWh pojemności magazynów i ponad 4 MW mocy baterii. Przeczytaj opis projektu Skyfri.

IoT na AWS w Global Green

Dla Global Green pracujemy z AWS IoT Core i kontami AWS oraz prowadzimy środowisko symulacyjne na AWS. Pierwszą konfigurację AWS IoT wykonaliśmy między kwietniem a czerwcem 2026 roku.