Większość z nas, zauważając nowy termin w świecie IT, na blogach lub konferencjach, prędzej czy później zadaje sobie pytanie: „Co to jest? Kolejne modne słowo, „buzzword” czy coś, co naprawdę zasługuje na naszą uwagę i przestudiowanie, obiecując nowe horyzonty?” Tak samo stało się ze mną w przypadku terminu GitOps jakiś czas temu. Uzbrojony w wiele istniejących artykułów oraz wiedzę kolegów z firmy , próbowałem zrozumieć, czym właściwie jest, i jak jego zastosowanie może wyglądać w praktyce.
A propos nowości terminu GitOps , świadczy również przeprowadzone przez nas ostatnio badanie: ponad połowa ankietowanych jeszcze nie zaczęła pracy z jego zasadami.
Zatem problem zarządzania infrastrukturą nie jest nowy. Wiele dostawców chmurowych jest dostępnych dla szerszej publiczności od ponad dziesięciu lat i wydawałoby się, że powinni uprościć pracę zespołów odpowiedzialnych za infrastrukturę. Jednak w porównaniu do procesu tworzenia aplikacji (gdzie poziom automatyzacji osiąga coraz wyższe horyzonty), projekty infrastrukturalne nadal często obejmują wiele ręcznych zadań i wymagają specjalistycznej wiedzy, szczególnie w obliczu współczesnych wymagań dotyczących odporności, elastyczności, skalowalności i wydolności.
Usługi chmurowe spełniły te wymagania z dużym powodzeniem i to one dały znaczący impuls do rozwoju podejścia IaC. To zrozumiałe. Przecież to one umożliwiły skonfigurowanie całkowicie wirtualnego centrum danych: brak serwerów fizycznych, szaf, komponentów sieciowych, cała infrastruktura może być opisana za pomocą skryptów i plików konfiguracyjnych.
Więc jaka jest właściwie różnica GitOps od IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
Cały kod jest przechowywany w repozytorium git
Wersjonowanie kodu nie jest obowiązkowe
Deklaratywne opisanie kodu / Idempotencja
Dopuszczalne jest zarówno opis deklaratywny, jak i imperatywny
Zmiany wchodzą w życie za pomocą mechanizmów Merge Request / Pull Request
Zatwierdzenie, akceptacja i współpraca nie są obowiązkowe
Proces wdrażania aktualizacji jest zautomatyzowany
Proces wdrażania aktualizacji nie jest normowany (automatyczny, ręczny, kopiowanie plików, przy użyciu wiersza poleceń itp.)
Innymi słowy GitOps pojawił się na świecie dzięki zastosowaniu zasad IaC. Po pierwsze, infrastrukturę i konfiguracje można teraz przechowywać dokładnie tak samo jak aplikacje. Kod jest łatwy do przechowywania, łatwo się nim dzielić, porównywać, korzystać z możliwości wersjonowania. Wersje, gałęzie, historia. I to wszystko w ogólnodostępnym miejscu dla całego zespołu. Dlatego naturalnym krokiem było zaczęcie używania systemów kontroli wersji, w szczególności git, jako najbardziej popularnego.
Z drugiej strony, pojawiła się możliwość automatyzacji procesów zarządzania infrastrukturą. Można to teraz zrobić szybciej, bardziej niezawodnie i taniej. Zwłaszcza, że zasady CI/CD były już znane i popularne wśród programistów oprogramowania. Konieczne było tylko przeniesienie i zastosowanie już znanej wiedzy i umiejętności w nowym obszarze. Jednak te praktyki wykraczały poza standardową definicję infrastruktury jako kodu, stąd pojawiło się pojęcie. GitOps.
Ciekawość GitOps, oczywiście, tkwi także w tym, że nie jest to produkt, wtyczka lub platforma związana z żadnym dostawcą. Jest to raczej paradygma i zestaw zasad, analogicznie do innego znanego nam terminu: DevOps.
W firmie Opracowaliśmy dwie definicje tego nowego terminu: teoretyczną i praktyczną. Zacznijmy od teoretycznej:
GitOps to metodologia, która wykorzystuje zaawansowane zasady DevOps stosowane w rozwoju aplikacji, takie jak kontrola wersji, współpraca, zatwierdzanie, CI/CD, i stosuje je do rozwiązywania zadań związanych z automatyzacją zarządzania infrastrukturą.
Wszystkie procesy GitOps działają przy użyciu już istniejących narzędzi. Cały kod infrastrukturalny jest przechowywany w znanym repozytorium git, zmiany przechodzą przez ten sam proces zatwierdzania, co każdy inny kod programistyczny, a proces wdrażania jest zautomatyzowany, co minimalizuje błędy ludzkie, zwiększa niezawodność i powtarzalność.
Z praktycznego punktu widzenia opisujemy GitOps w następujący sposób:
Infrastrukturę jako kod omówiliśmy już jako jeden z kluczowych elementów tego wzoru. Wyobraźmy sobie teraz pozostałych uczestników.
Merge Request (alternatywna nazwa Pull Request). W kontekście procesu MR to prośba o wprowadzenie zmian w kodzie i następne scalanie gałęzi. W zakresie narzędzi, których używamy, to raczej możliwość uzyskania pełnego obrazu wszystkich wprowadzonych zmian: nie tylko różnice kodu, zebrane z kilku commitów, ale także kontekst, wyniki testów i oczekiwany rezultat. Jeśli mówimy o kodzie infrastruktury, to interesuje nas, jak dokładnie zmieni się infrastruktura, ile nowych zasobów zostanie dodanych lub usuniętych i jakie zmiany będą miały miejsce. Wskazane byłoby, aby było to w bardziej przyjaznym i łatwym do odczytania formacie. W przypadku dostawców chmurowych dobrze byłoby wiedzieć, jakie finansowe konsekwencje pociągnie ta zmiana.
Ale MR to także narzędzie do współpracy, interakcji, komunikacji. To miejsce, gdzie wdrażany jest system zajęć i przeciwwag. Od prostych komentarzy po formalne zatwierdzenia i akceptacje.
A ostatni element: CI/CD, jak już wiemy, umożliwia automatyzację procesu wprowadzania zmian w infrastrukturze, testowania (od prostego sprawdzenia składni po bardziej skomplikowaną analizę statyczną kodu). A także w późniejszym wykrywaniu dryfu: różnic między rzeczywistym a pożądanym stanem systemu. Na przykład, w wyniku nieautoryzowanych ręcznych zmian lub awarii systemów.
Tak, termin GitOps nie wprowadza nas w nic zupełnie nowego, nie wymyśla koła na nowo, a jedynie stosuje już zdobyte doświadczenie w nowym obszarze. Ale w tym kryje się jego siła.
A jeśli nagle zainteresuje cię, jak to wszystko wygląda w praktyce, zapraszam do obejrzenia naszego , w którym krok po kroku opowiadam, jak za pomocą GitLab:
Wdrożyć podstawowe zasady GitOps
Tworzyć i wprowadzać zmiany w infrastrukturze chmurowej (na przykładzie Yandex Cloud)
Automatyzować wykrywanie dryfu systemu od pożądanego stanu za pomocą aktywnego monitorowania
https://bit.ly/34tRpwZ
Źródło: habr.com
