GitOps: kolejne modne hasło czy przełom w automatyzacji?

GitOps: kolejne modne hasło czy przełom w automatyzacji?

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 GitLab, próbowałem dociec, co to za bestia i jak mogłoby wyglądać jej zastosowanie w praktyce.

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.

GitOps: kolejne modne hasło czy przełom w automatyzacji?

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 GitLab opracowaliśmy dwie definicje tego nowego terminu: teoretyczną i praktyczną. Zacznijmy od teorii:

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:

GitOps: kolejne modne hasło czy przełom w automatyzacji?

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 Master Class, w którym krok po kroku opowiadam jak korzystać z GitLaba:

  • 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

GitOps: kolejne modne hasło czy przełom w automatyzacji?https://bit.ly/34tRpwZ

Źródło: www.habr.com

Dodaj komentarz