GitOps

Metodyka, w której repozytorium Git jest jedynym źródłem prawdy o konfiguracji infrastruktury i aplikacji. Zmiany wprowadza się przez commity, co umożliwia wersjonowanie i łatwe wycofywanie.

GitOps to sposób zarządzania infrastrukturą i aplikacjami, w którym repozytorium Git jest jedynym źródłem prawdy (single source of truth) o tym, jak ma wyglądać Twój system. Zamiast logować się na serwer i klikać czy wpisywać komendy ręcznie, opisujesz pożądany stan deklaratywnie w plikach (najczęściej YAML), wrzucasz je do repo, a wyspecjalizowany agent pilnuje, żeby rzeczywistość zgadzała się z tym, co zapisane w Git.

Jak to działa

Sednem jest pętla uzgadniania (reconciliation loop). Agent działający w klastrze co kilka-kilkadziesiąt sekund porównuje stan zadeklarowany w repozytorium ze stanem faktycznym i, jeśli wykryje różnicę (drift), sam ją naprawia. Ty nie pushujesz zmian na serwer — to system sam je z repo pobiera (model pull, bezpieczniejszy niż klasyczne push, bo dane dostępowe nie wychodzą poza klaster).

Praktyczne korzyści: każda zmiana to commit, więc masz pełną historię „kto, co i kiedy”, code review przez pull requesta, a rollback to zwykłe git revert. Audyt i zgodność robią się prawie za darmo, bo historia Git jest dziennikiem zmian. Najlepiej działa to z infrastrukturą deklaratywną — Kubernetes pasuje tu jak ulał, bo sam w sobie opiera się na stanie pożądanym.

Przykład z praktyki

Najpopularniejsze narzędzia to Argo CD i Flux (oba pod skrzydłami CNCF). Wyobraź sobie, że w repo masz manifest deploymentu z replicas: 3. Ktoś w panilce ręcznie zrobił kubectl scale deployment web --replicas=5. Przy podejściu GitOps Argo CD wykryje, że stan w klastrze (5) różni się od repo (3), pokaże status OutOfSync i — jeśli masz włączony auto-sync — przywróci wartość 3. Chcesz na stałe 5 podów? Zmieniasz liczbę w pliku, robisz commit i merge. Inaczej Twoja ręczna zmiana i tak zniknie.

Częste błędy i mity

  • Sekrety w repo. Klasyczna wpadka — hasła i klucze nie idą czystym tekstem do Git. Używasz SealedSecrets, External Secrets Operator albo Vault.
  • „GitOps to tylko CI/CD”. Nie. CI buduje i testuje artefakty (push), GitOps zarządza stanem środowiska (pull). Często działają razem, ale to dwie różne rzeczy.
  • „GitOps wymaga Kubernetesa”. Najczęściej z nim chodzi, ale samą ideę można stosować np. z Terraform przez Atlantis.
  • Ręczne kubectl apply na produkcji. Łamie cały model — wprowadzasz drift, którego nikt nie zobaczy w historii.

Pojęcia powiązane

Infrastructure as Code (IaC), Kubernetes, Argo CD, Flux, CI/CD, deklaratywna konfiguracja, reconciliation loop, drift detection, Terraform.