all systems operational +48 697 610 212
Firma produktowa · Polska · 60 aplikacji

Z Apache i Dockera na Kubernetes z GitOps

Środowisko 60 aplikacji wyrosło organicznie: połowa na Apache2, połowa w Dockerze, deploye ręczne, rollback przez SSH i backup.

Przed

  • ~50% aplikacji na Docker, ~50% na Apache2
  • Ręczne i półautomatyczne deploye
  • Rollback przez SSH + przywracanie backupu
  • Konfiguracja rozproszona po serwerach
  • Brak separacji środowisk DEV/RC/PROD

Po

  • RKE2: osobny klaster per środowisko
  • GitOps z ArgoCD — stan klastra zawsze zgodny z repo
  • Rollback jednym commitem Git
  • Uniwersalny Helm Chart dla wszystkich aplikacji
  • Pełna powtarzalność DEV/RC/PROD
60aplikacji zmigrowanych
−87%redukcja rozmiaru obrazów Docker
~30sczas buildu (z ~6 minut)
0przestojów przy migracji
Jak to zrobiliśmy

Przebieg projektu

Zaczęliśmy od inwentaryzacji: które aplikacje mają identyczny kształt wdrożenia, które wymagają indywidualnego podejścia, gdzie żyje konfiguracja. Na tej podstawie powstał jeden uniwersalny Helm Chart, parametryzowany per aplikacja — zamiast 60 osobnych konfiguracji.

Obrazy bazowe przebudowaliśmy na wielostopniowe buildy (multi-stage), co zmniejszyło ich rozmiar średnio o 87% i skróciło build z ~6 minut do ~30 sekund. Środowiska DEV, RC i PROD dostały osobne klastry RKE2, a deploy odbywa się przez ArgoCD — merge do gałęzi środowiska to wdrożenie, revert commita to rollback.

Migracja przebiegała falami, aplikacja po aplikacji, z ruchem przełączanym dopiero po weryfikacji — dzięki temu obyło się bez ani minuty przestoju.

Wersja techniczna tego case study na blogu →

RKE2KubernetesArgoCDHelmGitLab CIDockerGitOps

Planujesz podobną migrację?

Porozmawiaj z inżynierem, który ją przeprowadził. Bezpłatnie.

Darmowa konsultacja