DevOps

CI/CD to praktyka i filozofia, która ma na celu automatyzację i usprawnienie procesu dostarczania oprogramowania. Składa się z dwóch głównych części: • Ciągła Integracja (Continuous Integration - CI): To praktyka, w której deweloperzy często i regularnie (nawet kilka razy dziennie) integrują swoje zmiany w kodzie do wspólnego repozytorium. Każda taka integracja automatycznie uruchamia proces budowania i zestaw testów, co pozwala na szybkie wykrywanie błędów integracyjnych. • Ciągłe Dostarczanie/Wdrażanie (Continuous Delivery/Deployment - CD): To rozszerzenie CI. Polega na tym, że każda zmiana, która pomyślnie przejdzie wszystkie etapy testów, jest automatycznie wdrażana na środowisko (np. testowe, a w przypadku Continuous Deployment – nawet na produkcyjne). Główne korzyści: 1. Szybsze dostarczanie wartości: Zmiany trafiają do użytkowników w ciągu godzin lub dni, a nie miesięcy. 2. Mniejsze ryzyko wdrożeń: Wdrażamy małe, inkrementalne zmiany, które są łatwiejsze do przetestowania i ewentualnego wycofania. 3. Wyższa jakość i niezawodność: Automatyzacja testów i wdrożeń eliminuje ludzkie błędy. 4. Większa produktywność deweloperów: Mogą oni skupić się na pisaniu kodu, a nie na manualnych procesach wdrożeniowych.

Infrastruktura jako Kod (Infrastructure as Code - IaC) to praktyka zarządzania i provisioningu (tworzenia) infrastruktury IT (serwerów, sieci, baz danych, load balancerów) za pomocą plików konfiguracyjnych, które są traktowane tak samo jak kod aplikacji – przechowywane w systemie kontroli wersji (np. Git), wersjonowane i poddawane przeglądom. Zamiast manualnie 'wyklikiwać' serwery w panelu chmurowym, opisujemy pożądaną infrastrukturę w sposób deklaratywny, np. w plikach Terraform lub CloudFormation. Główne zalety: • Powtarzalność i spójność: Gwarantuje, że za każdym razem tworzone jest identyczne środowisko, co eliminuje problemy typu 'u mnie działa, a na produkcji nie'. • Wersjonowanie i historia: Każda zmiana w infrastrukturze jest udokumentowana w Gicie, co ułatwia audyty i powrót do poprzednich wersji. • Szybkość i automatyzacja: Możemy w kilka minut odtworzyć całą skomplikowaną infrastrukturę od zera lub powielić ją dla nowego środowiska. • Unikanie 'dryfu konfiguracyjnego' (configuration drift): Zapobiega sytuacji, w której konfiguracja serwerów z czasem 'rozjeżdża się' w wyniku ręcznych, nieudokumentowanych zmian.

Obie technologie służą do izolacji aplikacji, ale robią to na zupełnie różnych poziomach abstrakcji. • Maszyna Wirtualna (VM): - Wirtualizuje cały sprzęt. Na fizycznym serwerze uruchomiony jest hypervisor, który tworzy wirtualne 'komputery'. Każda VM ma swój własny, pełny system operacyjny (tzw. 'guest OS'), własne jądro i wirtualne zasoby (CPU, RAM). - Zapewnia bardzo silną izolację, ale jest 'ciężka', wolno się uruchamia i zużywa dużo zasobów (każda VM to osobny OS). • Kontener (np. Docker): - Wirtualizuje system operacyjny. Kontenery działają na jednym systemie operacyjnym gospodarza (host OS) i współdzielą jego jądro. - Kontener zawiera tylko aplikację i jej zależności, a nie cały system operacyjny. - Dzięki temu kontenery są niezwykle lekkie (mierzone w megabajtach, a nie gigabajtach), uruchamiają się w ułamku sekundy i zużywają znacznie mniej zasobów. - Izolacja jest nieco 'słabsza' niż w VM, ale w zupełności wystarczająca dla większości zastosowań. W skrócie: VM to wirtualny komputer, a kontener to wirtualny proces. W nowoczesnym podejściu cloud-native kontenery stały się standardem.

Kubernetes (często skracany do K8s) to platforma open-source do orkiestracji kontenerów. Jej głównym zadaniem jest automatyzacja wdrażania, skalowania i zarządzania aplikacjami skonteneryzowanymi na dużą skalę, w klastrze serwerów. Gdy mamy do czynienia z setkami lub tysiącami kontenerów, ręczne zarządzanie nimi staje się niemożliwe. Kubernetes rozwiązuje ten problem, dostarczając zestaw potężnych mechanizmów: • Deklaratywne zarządzanie stanem: Opisujemy pożądany stan systemu (np. 'chcę, aby zawsze działały 3 instancje mojej aplikacji'), a Kubernetes sam dba o to, by rzeczywisty stan był z nim zgodny. • Samonaprawa (Self-healing): Jeśli kontener przestanie działać, Kubernetes automatycznie go restartuje. Jeśli cały serwer (węzeł) ulegnie awarii, Kubernetes przeniesie kontenery na inne, działające maszyny. • Automatyczne skalowanie: Może automatycznie zwiększać lub zmniejszać liczbę instancji aplikacji w odpowiedzi na obciążenie (np. użycie CPU). • Wykrywanie usług (Service Discovery) i Równoważenie obciążenia (Load Balancing): Automatycznie zarządza komunikacją między kontenerami i udostępnia je pod jednym, stabilnym adresem sieciowym. Kubernetes stał się de facto standardem dla uruchamiania aplikacji w chmurze i w środowiskach mikroserwisowych.

Potok CI/CD (CI/CD Pipeline) to zautomatyzowana sekwencja kroków (etapów), przez które przechodzi kod aplikacji od momentu jego zatwierdzenia (`commit`) w repozytorium Git, aż po wdrożenie na środowisko produkcyjne. Jest to serce automatyzacji w DevOps. Każdy etap w potoku jest uruchamiany automatycznie po pomyślnym zakończeniu poprzedniego. Typowy potok składa się z następujących etapów: 1. Budowanie (Build): Pobranie kodu źródłowego, kompilacja, pobranie zależności. 2. Testowanie (Test): Uruchomienie różnych poziomów testów automatycznych (jednostkowe, integracyjne, end-to-end), a także analiza statyczna kodu. 3. Pakowanie (Package): Stworzenie artefaktu gotowego do wdrożenia, np. obrazu Dockera. 4. Wdrażanie (Deploy): Automatyczne wdrożenie artefaktu na kolejne środowiska – najpierw deweloperskie, potem testowe/staging, a na końcu, po wszystkich zatwierdzeniach, na produkcyjne. Potok CI/CD zapewnia szybką, powtarzalną i niezawodną ścieżkę dostarczania zmian, minimalizując ryzyko ludzkiego błędu.

GitOps to nowoczesny model operacyjny dla aplikacji cloud-native, w którym repozytorium Git jest traktowane jako jedyne i ostateczne źródło prawdy (Single Source of Truth) dla deklaratywnego opisu pożądanego stanu całego systemu (zarówno infrastruktury, jak i aplikacji). Główne zasady GitOps to: 1. Cały system jest opisany deklaratywnie: Pożądany stan jest zdefiniowany w plikach (np. manifesty Kubernetes, pliki Terraform) przechowywanych w Gicie. 2. Repozytorium Git jest jedynym źródłem prawdy: Nie dokonuje się żadnych ręcznych zmian w środowisku. Każda zmiana musi przejść przez Git. 3. Zmiany są wprowadzane przez pull requesty: Wszelkie zmiany w stanie systemu są proponowane, recenzowane i zatwierdzane za pomocą standardowego procesu pull/merge request, co zapewnia pełną historię i audytowalność. 4. Automatyzacja i synchronizacja: W klastrze działa zautomatyzowany agent (np. Argo CD, Flux), który stale porównuje rzeczywisty stan systemu ze stanem zadeklarowanym w Gicie i w przypadku rozbieżności, automatycznie przywraca system do pożądanego stanu. GitOps łączy najlepsze praktyki DevOps, IaC i Gita, aby stworzyć wysoce zautomatyzowany, transparentny i niezawodny system zarządzania aplikacjami.