Czy GitOps to kolejna wielka koncepcja w DevOps?

Git jest narzędziem o znaczeniu krytycznym w procesie tworzenia oprogramowania, które wykorzystuje przepływy pracy oparte na pull requestach i przeglądach kodu. Pull requesty zwiększają widoczność nadchodzących zmian w bazie kodu i sprzyjają komunikacji, wymianie poglądów i recenzowaniu zmian.

Pull requesty są podstawowym elementem procesu programistycznego opartego na współpracy i zrewolucjonizowały sposób, w jaki zespoły i firmy tworzą oprogramowanie. Nadają one przejrzystość i wymierność procesowi, który wcześniej był mało czytelny. Pull requesty w Git przyczyniły się do włączenia procesów DevOps do dziedziny tworzenia oprogramowania. Administratorzy systemów, którzy zazwyczaj byli niechętni zmianom, teraz wdrażają nowe praktyki programistyczne, takie jak Agile i DevOps.

Administrowanie systemami jako rodzaj rzemiosła nie może poszczycić się chlubną historią. Dawniej administratorzy systemów zarządzali sprzętem ręcznie przez podłączanie i aprowizację urządzeń w fizycznych szafach serwerowych lub za pośrednictwem interfejsu API do aprowizacji w chmurze. Oprócz ręcznego procesu aprowizacji, regularnie wykonywano ogromną liczbę ręcznych prac konfiguracyjnych. Administratorzy przechowywali niestandardowe kolekcje imperatywnych skryptów i konfiguracji, łącząc je razem i umieszczając w różnych miejscach. W każdej chwili te skrypty mogły ulec uszkodzeniu lub mogło dojść do ich utraty. Współpraca stanowiła wyzwanie, ponieważ niestandardowe łańcuchy narzędzi nie były regularnie dokumentowane ani udostępniane.

Na gruncie tych pierwotnych mokradeł administracji systemami zrodził się ruch DevOps. DevOps zaczerpnął najlepsze pomysły z dziedziny inżynierii oprogramowania i zastosował je do administrowania systemami, przekształcając zlepek narzędzi w kod objęty kontrolą wersji.

Jedną z największych rewelacji, jakie przyniósł ruch DevOps, była koncepcja infrastruktury jako kodu (IaC). Dotychczas administratorzy systemów preferowali konfigurację systemów przy użyciu imperatywnych skryptów. W oprogramowaniu imperatywnym do uzyskania pożądanego stanu wykonuje się sekwencję kroków, na przykład:

Oprogramowanie imperatywne jest często podatne na błędy i łatwo je uszkodzić, zmieniając kolejność zdarzeń. W nowoczesnych procesach tworzenia oprogramowania odchodzi się od wzorców imperatywnych na rzecz wzorców deklaratywnych.

W oprogramowaniu deklaratywnym stosuje się deklarację oczekiwanego stanu, zamiast sekwencji poleceń. Poniżej przedstawiamy porównanie imperatywnych i deklaratywnych instrukcji DevOps.

Przykładowe instrukcje imperatywne:

1. Zainstaluj system operacyjny na tym komputerze.
2. Zainstaluj te zależności.
3. Pobierz kod z tego adresu URL.
4. Przenieś kod do tego katalogu.
5. Powtórz tę operację 3 razy na 3 innych komputerach.

Deklaratywna wersja tych samych instrukcji brzmiałaby następująco: na 4 komputerach zainstalowano w tym katalogu oprogramowanie pobrane z tego adresu URL.

Wiele korzyści, które oferuje GitOps, pokrywa się z tym, co zapewnia przepływ prac programistycznych Agile oparty na gałęziach funkcji. Pierwszą główną korzyścią jest łatwość wdrożenia dzięki możliwości wykorzystania powszechnie stosowanych narzędzi. Git jest de facto standardem wśród systemów kontroli wersji i popularnym narzędziem do tworzenia oprogramowania stosowanym przez większość programistów i zespołów programistycznych. Ułatwia to programistom znającym Git dołączenie do grona interdyscyplinarnych współautorów i uczestnictwo w GitOps.

Korzystanie z systemu kontroli wersji pozwala zespołowi śledzić wszystkie modyfikacje konfiguracji systemu. W ten sposób zespół zyskuje „źródło rzetelnych informacji” oraz cenny dziennik audytu, który można sprawdzić w razie usterki lub nieoczekiwanego zachowania. Zespoły mogą przejrzeć historię GitOps i zobaczyć, kiedy wprowadzono regresję. Ponadto taki dziennik audytu może posłużyć jako odniesienie w przypadku audytów zgodności lub bezpieczeństwa. Historię GitOps można wykorzystać jako dowód modyfikacji lub aktualizacji takich elementów, jak certyfikaty szyfrowania.

GitOps zapewnia przejrzystość i zrozumienie potrzeb infrastrukturalnych organizacji w zakresie centralnego repozytorium. Umieszczenie wszystkich konfiguracji systemów w centralnym repozytorium ułatwia skalowanie wkładu wnoszonego przez poszczególnych członków zespołu. Hostowane usługi Git do wykonywania pull requestów, takie jak Bitbucket, oferują rozbudowane narzędzia do przeglądu kodu i prowadzenia dyskusji w komentarzach. Dzięki temu powstają pasywne pętle komunikacyjne, które dają całemu zespołowi inżynierskiemu możliwość obserwowania i monitorowania zmian w infrastrukturze.

GitOps może znacznie zwiększyć produktywność zespołu DevOps. Pozwala jego członkom przeprowadzać szybkie eksperymenty z nowymi konfiguracjami infrastruktury. Jeśli nowe zmiany nie zachowują się zgodnie z oczekiwaniami, zespół może użyć historii Git, aby przywrócić zmiany do znanego poprawnego stanu. Jest to niezwykle przydatne, ponieważ umożliwia stosowanie znanej funkcji „cofnij” w złożonej infrastrukturze.

Procedury GitOps są wykonywane za pośrednictwem podstawowego systemu orkiestracji. GitOps stanowi jedynie niezależny wzorzec najlepszych praktyk. Wiele popularnych rozwiązań GitOps wykorzystuje obecnie przede wszystkim Kubernetes jako system orkiestracji. Na rynku pojawiają się również alternatywne narzędzia GitOps, które obsługują bezpośrednie manipulacje na platformie Terraform.

Do uzyskania pełnej instalacji GitOps potrzebna jest platforma do obsługi pipeline'ów. Popularnymi narzędziami do obsługi pipeline'ów zgodnymi z GitOps są na przykład Jenkins, Bitbucket Pipelines czy CircleCi. Pipeline'y automatyzują pull requesty w Git i zamykają lukę między nimi a systemem orkiestracji. Po ustanowieniu hooków pipeline'ów i wyzwoleniu ich z poziomu pull requestów polecenia są wykonywane po stronie systemu orkiestracji.

Nowy wzorzec lub komponent wprowadzony specjalnie za pomocą GitOps jest „operatorem” GitOps, czyli mechanizmem umiejscowionym między pipelinem a systemem orkiestracji. Pull request inicjuje pipeline, który następnie wyzwala operatora. Operator sprawdza stan repozytorium i rozpoczyna orkiestrację oraz synchronizację. To właśnie operator jest magicznym składnikiem GitOps.

Wyobraź sobie, że zespół zidentyfikował wąskie gardło ograniczające wydajność lub dostrzegł nagły wzrost ruchu, a do tego zauważa, że moduł równoważenia obciążenia nie działa zgodnie z oczekiwaniami. W związku z tym zespół przygląda się repozytorium GitOps, w którym znajduje się konfiguracja infrastruktury, i wyszukuje konkretny plik odpowiedzialny za konfigurację i wdrożenie modułu równoważenia obciążenia. Członkowie zespołu mogą go przejrzeć w swojej witrynie internetowej hostującej system Git. Po dokonaniu przeglądu i omówieniu problemu stwierdzają, że niektóre wartości konfiguracji modułu równoważenia obciążenia nie są optymalne i wymagają dostosowania.

Członek zespołu otwiera nowy pull request, który optymalizuje wartości modułu równoważenia obciążenia. Pull request zostaje zrecenzowany i zatwierdzony przez drugiego członka zespołu, a następnie scalony z repozytorium. Scalenie uruchamia pipeline GitOps, który wyzwala operator GitOps. Operator widzi, że konfiguracja modułu równoważenia obciążenia została zmieniona. Za pomocą narzędzia do orkiestracji systemów potwierdza, że jest niezgodna z konfiguracją działającą w klastrze zespołu.

Operator sygnalizuje systemowi orkiestracji aktualizację konfiguracji modułu równoważenia obciążenia. Orkiestrator zajmuje się resztą i automatycznie wdraża nowo skonfigurowany moduł równoważenia obciążenia. Następnie zespół monitoruje nowo zaktualizowany działający system, obserwując, jak wraca do właściwego stanu. Jest to idealny scenariusz GitOps. Rozwińmy go dalej, aby zademonstrować narzędzie GitOps.

Wyobraźmy sobie, że zamiast drobnej korekty wartości modułu równoważenia obciążenia tak, aby były bardziej optymalne, zespół podejmuje agresywną decyzję o wdrożeniu zupełnie nowego modułu równoważenia obciążenia. Członkowie zespołu uważają, że obecny moduł równoważenia obciążenia jest zasadniczo wadliwy i chcą wypróbować alternatywną opcję. Przepływ pracy jest taki sam jak w przypadku korekty wartości. Zespół tworzy pull request, który wprowadza zupełnie nową konfigurację modułu równoważenia obciążenia i usuwa starą konfigurację. Zostaje on zatwierdzony i wdrożony za pośrednictwem pipeline'u.

Niestety zespół stwierdza, że nowy typ modułu równoważenia obciążenia jest niezgodny z niektórymi innymi usługami w ich klastrze. Nowy moduł równoważenia obciążenia powoduje krytyczne błędy ruchu i wstrzymuje operacje użytkowników. Na szczęście zespół może szybko cofnąć wprowadzone zmiany modułu równoważenia obciążenia, ponieważ dysponuje kompletnym pipelinem GitOps. Zespół wykonuje kolejny pull request, który przywraca repozytorium do starego modułu równoważenia obciążenia, który działał. Ta operacja ponownie zostanie odnotowana przez pipeline GitOps i automatycznie wdrożona. Pozwoli to błyskawicznie naprawić infrastrukturę i polepszyć ocenę niezawodności zespołu.

GitOps to niezwykle zaawansowany wzorzec przepływu pracy do zarządzania nowoczesną infrastrukturą chmurową. Choć przede wszystkim koncentruje się on na zarządzaniu klastrami Kubernetes, społeczność DevOps stosuje i publikuje rozwiązania GitOps także dla systemów innych niż Kubernetes. GitOps może przynieść zespołowi inżynierskiemu wiele korzyści, takich jak poprawa komunikacji, widoczności, stabilności i niezawodności systemu. Jednym z kluczowych wymagań środowiska GitOps jest nowoczesna platforma do hostingu systemu Git, taka jak Bitbucket.