Projekt wewnętrzny Coderise · DevOps / Cloud

Automatyczne wdrożenia aplikacji Spring Boot i Angular na AWS

Jak zastąpiliśmy ręczne wdrożenia kontrolowanym pipeline’em GitLab CI/CD — od testów i obrazu Docker po backup, smoke testy, rollback oraz IndexNow.

Typ projektu
Realizacja wewnętrzna
Publikacja
Obszar
CI/CD, bezpieczeństwo, AWS
  1. Verifybackend + frontend
    passed
  2. ImageDocker → AWS ECR
    sha256
  3. Deploybackup + recreate
    passed
  4. Notifymapa witryny → IndexNow
    202
Produkcja odpowiada prawidłowo
Uproszczony widok działającego procesu. Każdy etap kończy się jednoznacznym wynikiem.
OIDC
dostęp do AWS bez stałych kluczy w GitLabie
5
ostatnich obrazów zachowanych w AWS ECR
Rollback
automatyczna reakcja na nieudany smoke test

Wdrożenie działało, ale zależało od ręcznej sekwencji.

Aplikacja Coderise łączy frontend Angular z backendem Spring Boot i działa w kontenerze na AWS Lightsail. Wcześniejsze wydanie nowej wersji wymagało połączenia z serwerem, pobrania zmian i ręcznego odtworzenia kontenera. Taki proces pozwalał wdrażać aplikację, ale nie gwarantował za każdym razem identycznego przebiegu.

Problem był szczególnie widoczny po zmianie wartości sekretu w AWS Secrets Manager. Spring odczytuje konfigurację podczas startu, więc samo zapisanie nowej wartości sekretu nie aktualizowało działającego procesu. Potrzebne było kontrolowane odtworzenie aplikacji, bez przypadkowego zatrzymania bazy danych.

Jedna ścieżka od kodu do zweryfikowanej produkcji.

Pipeline rozdziela budowanie artefaktów od decyzji o wdrożeniu. Produkcja jest chronionym, ręcznie zatwierdzanym krokiem, a wszystkie operacje wykonuje skrypt o ograniczonym zakresie uprawnień na runnerze przypisanym do projektu.

  1. 01

    Weryfikacja

    Testy Maven, lint oraz produkcyjny build aplikacji Angular są uruchamiane przed pakowaniem.

    verify
  2. 02

    Wspólna paczka

    Prerenderowany frontend trafia do zasobów Spring Boot, dzięki czemu wydanie jest spójne.

    package
  3. 03

    Obraz Docker

    Obraz jest publikowany w AWS ECR i wskazywany niezmiennym adresem z digestem SHA-256.

    publish
  4. 04

    Autoryzacja OIDC

    GitLab otrzymuje krótkotrwały dostęp przez AWS STS zamiast przechowywać stałe klucze.

    authorize
  5. 05

    Kontrolowane wdrożenie

    Powstaje dump bazy i kopia konfiguracji, po czym odtwarzany jest wyłącznie kontener aplikacji.

    deploy
  6. 06

    Test i zgłoszenie

    Publiczny smoke test potwierdza wersję, a po sukcesie adresy z mapy witryny trafiają do IndexNow.

    notify

Bezpieczeństwo wynika z całego przepływu, nie z jednego narzędzia.

Digest zamiast „latest”

Dokładnie wiadomo, jaki obraz trafia na serwer.

Job wdrożeniowy akceptuje wyłącznie adres obrazu z repozytorium Coderise i pełnym digestem SHA-256.

OIDC zamiast stałego klucza dostępu

Dostęp do AWS jest krótkotrwały.

Rola IAM ufa tokenowi konkretnego projektu i chronionej gałęzi, więc nie trzeba rotować klucza dostępowego w CI.

Sekret podczas wdrożenia

Aktualna konfiguracja jest ładowana podczas uruchamiania aplikacji.

Aktualna wartość z Secrets Manager nie trafia do obrazu. Odtworzenie aplikacji powoduje ponowne załadowanie jej przez Spring podczas uruchamiania.

Kontrolowana awaria

Nieudany smoke test uruchamia rollback.

Skrypt przywraca poprzedni obraz i plik środowiskowy, a całe wdrożenie zostaje oznaczone w GitLabie jako nieudane.

Błąd ma prowadzić do znanego stanu, a nie do improwizacji.

Przed zmianą wersji tworzony jest dump PostgreSQL oraz kopia konfiguracji wydania. Po uruchomieniu kontenera pipeline wielokrotnie sprawdza publiczny endpoint kontrolujący stan aplikacji. Dopiero pozytywna odpowiedź kończy wdrożenie sukcesem.

Health 2xxWersja pozostaje na produkcji
Brak gotowościPoprzedni obraz i konfiguracja wracają

Wydanie stało się powtarzalnym procesem.

Jedno kryterium ukończenia wdrożenia

Sukces oznacza nie tylko uruchomiony kontener, lecz także pozytywny test dostępności z internetu.

Przewidywalny powrót do poprzedniej wersji

Obraz i konfiguracja sprzed wdrożenia są znane, więc reakcja na błąd nie zależy od pamięci osoby wykonującej wdrożenie.

Aktualna konfiguracja przy każdym wdrożeniu

Odtworzenie kontenera ładuje bieżący sekret i eliminuje osobny, ręczny restart po zmianie konfiguracji.

Rozwiązanie jest dopasowane do obecnej skali.

Produkcja działa obecnie na pojedynczym kontenerze aplikacji, dlatego jego odtworzenie może powodować krótką niedostępność. Gdy wymagane będą wdrożenia bez przerwy w działaniu (zero downtime), naturalnym krokiem będzie uruchomienie równoległej instancji oraz przełączanie ruchu dopiero po health checku.

Rollback przywraca obraz aplikacji i konfigurację, ale celowo nie cofa migracji bazy danych. Zmiany schematu muszą więc zachowywać kompatybilność wsteczną. Samodzielnie utrzymywany runner wymaga również regularnych aktualizacji i monitoringu.

Każde narzędzie odpowiada za określony etap procesu.

  • Angular 20
  • Nx
  • Spring Boot
  • Maven
  • Docker Compose
  • PostgreSQL
  • GitLab CI/CD
  • GitLab Runner
  • AWS ECR
  • AWS Lightsail
  • AWS Secrets Manager
  • AWS STS / OIDC
  • IndexNow

Chcesz uporządkować wdrożenia własnej aplikacji?

Możemy zacząć od obecnego procesu, ryzyk i wymagań dotyczących dostępności.

Umów rozmowę