Większość z nas, zauważając kolejne nowe pojęcie w blogosferze czy konferencji IT, prędzej czy później zadaje sobie podobne pytanie: „Co to jest? Czy to tylko kolejne modne hasło, „modne hasło” czy coś naprawdę wartego szczególnej uwagi, przestudiowania i obietnicy nowych horyzontów?” To samo przydarzyło mi się z terminem GitOps jakiś czas temu. Uzbrojony w wiele istniejących artykułów, a także wiedzę kolegów z firmy
Przy okazji, o nowości tego terminu GitOps Z naszego ostatniego badania wynika również, że ponad połowa ankietowanych nie zaczęła jeszcze pracować zgodnie z jej zasadami.
Zatem problem zarządzania infrastrukturą nie jest nowy. Wielu dostawców usług chmurowych jest dostępnych dla ogółu społeczeństwa już od dobrych kilkunastu lat i wydawałoby się, że powinni byli sprawić, że praca zespołów odpowiedzialnych za infrastrukturę będzie prosta i przejrzysta. Jednak w porównaniu z procesem tworzenia aplikacji (gdzie automatyzacja osiąga coraz wyższy poziom), projekty infrastrukturalne nadal często obejmują wiele ręcznych zadań i wymagają specjalistycznej wiedzy i doświadczenia, szczególnie biorąc pod uwagę dzisiejsze wymagania dotyczące odporności na awarie, elastyczności, skalowalności i elastyczności.
Usługi chmurowe bardzo dobrze spełniły te wymagania i to właśnie one dały znaczący impuls do rozwoju podejścia IaC. To jest zrozumiałe. W końcu umożliwiły skonfigurowanie całkowicie wirtualnego centrum danych: nie ma tu fizycznych serwerów, stojaków ani komponentów sieciowych, a całą infrastrukturę można opisać za pomocą skryptów i plików konfiguracyjnych.
Jaka jest więc dokładnie różnica? GitOps od IaC? Od tego pytania zacząłem swoje dochodzenie. Po rozmowach z kolegami udało mi się dojść do następującego porównania:
GitOps
IaC
Cały kod jest przechowywany w repozytorium git
Wersjonowanie kodu jest opcjonalne
Deklaratywny opis kodu/Idempotencja
Dopuszczalne są zarówno opisy deklaratywne, jak i imperatywne
Zmiany wchodzą w życie za pomocą mechanizmów Merge Request / Pull Request
Zgoda, zatwierdzenie i współpraca są opcjonalne
Proces wdrażania aktualizacji jest zautomatyzowany
Proces wdrażania aktualizacji nie jest ustandaryzowany (automatyczny, ręczny, kopiowanie plików, korzystanie z wiersza poleceń itp.)
Innymi słowy GitOps narodził się właśnie poprzez zastosowanie zasad IaC. Po pierwsze, infrastrukturę i konfiguracje można teraz przechowywać w taki sam sposób, jak aplikacje. Kod jest łatwy do przechowywania, łatwy do udostępniania, porównywania i korzystania z funkcji wersjonowania. Wersje, gałęzie, historia. A wszystko to w miejscu publicznie dostępnym dla całego zespołu. Dlatego też stosowanie systemów kontroli wersji stało się całkowicie naturalnym zjawiskiem. W szczególności git, jako najpopularniejszy.
Z drugiej strony możliwa stała się automatyzacja procesów zarządzania infrastrukturą. Teraz można to zrobić szybciej, bardziej niezawodnie i taniej. Co więcej, zasady CI/CD były już znane i popularne wśród twórców oprogramowania. Pozostało jedynie przenieść i zastosować znaną już wiedzę i umiejętności w nowym obszarze. Praktyki te wykraczały jednak poza standardową definicję infrastruktury jako kodu, stąd koncepcja GitOps.
Ciekawość GitOpsoczywiście także pod tym względem, że nie jest to produkt, wtyczka czy platforma kojarzona z jakimkolwiek dostawcą. To raczej paradygmat i zbiór zasad, podobny do innego znanego nam terminu: DevOps.
Firma
GitOps to metodologia, która wykorzystuje najlepsze zasady DevOps stosowane przy tworzeniu aplikacji, takie jak kontrola wersji, współpraca, orkiestracja, CI/CD i stosuje je do wyzwań związanych z automatyzacją zarządzania infrastrukturą.
Wszystkie procesy GitOps Pracuję wykorzystując istniejące narzędzia. Cały kod infrastruktury jest przechowywany w znanym już repozytorium git, zmiany przechodzą ten sam proces zatwierdzania, co każdy inny kod programu, a proces wdrażania jest zautomatyzowany, co pozwala nam minimalizować błędy ludzkie, zwiększać niezawodność i powtarzalność.
Z praktycznego punktu widzenia opisujemy GitOps w następujący sposób:
Omówiliśmy już infrastrukturę jako kod jako jeden z kluczowych elementów tej formuły. Przedstawmy resztę uczestników.
Żądanie połączenia (alternatywna nazwa Żądanie ściągnięcia). W ujęciu procesowym MR jest prośbą o zastosowanie zmian w kodzie, a następnie połączenie oddziałów. Ale jeśli chodzi o narzędzia, których używamy, jest to raczej okazja, aby uzyskać pełny obraz wszystkich wprowadzanych zmian: nie tylko różnice w kodzie zebrane z określonej liczby zatwierdzeń, ale także kontekst, wyniki testów i ostateczny oczekiwany wynik. Jeśli mówimy o kodzie infrastruktury, to interesuje nas, jak dokładnie zmieni się infrastruktura, ile nowych zasobów zostanie dodanych, usuniętych, zmienionych. Najlepiej w wygodniejszym i łatwiejszym do odczytania formacie. W przypadku dostawców usług w chmurze dobrze jest wiedzieć, jakie będą skutki finansowe tej zmiany.
Ale MR to także sposób na współpracę, interakcję i komunikację. Miejsce, w którym wchodzi w grę system kontroli i równowagi. Od prostych komentarzy po formalne zatwierdzenia i zatwierdzenia.
No cóż, ostatni komponent: CI/CD, jak już wiemy, pozwala zautomatyzować proces wprowadzania zmian w infrastrukturze i testowania (od prostego sprawdzania składni po bardziej złożoną analizę kodu statycznego). A także w późniejszym wykrywaniu dryftu: różnic między rzeczywistym a pożądanym stanem systemu. Na przykład w wyniku nieautoryzowanych ręcznych zmian lub awarii systemu.
Tak, termin GitOps nie wprowadza nas w nic zupełnie nowego, nie wymyśla koła na nowo, a po prostu wykorzystuje zdobyte już doświadczenia w nowym obszarze. Ale właśnie w tym tkwi jego siła.
A jeśli nagle zainteresuje Cię, jak to wszystko wygląda w praktyce, to zapraszam do obejrzenia naszego
-
Wdrażaj podstawowe zasady GitOps
-
Twórz i wprowadzaj zmiany w infrastrukturze chmurowej (na przykładzie Yandex Cloud)
-
Zautomatyzuj wykrywanie odchylenia systemu od pożądanego stanu za pomocą aktywnego monitorowania
https://bit.ly/34tRpwZ
Źródło: www.habr.com