Notatka. przeł.: Po niedawnej publikacji o metodach pull i push w GitOps, widzieliśmy ogólne zainteresowanie tym modelem, ale rosyjskojęzycznych publikacji na ten temat było bardzo niewiele (na Habré po prostu nie ma ich). Dlatego mamy przyjemność zwrócić Państwa uwagę na tłumaczenie kolejnego artykułu – choć sprzed prawie roku! — od Weaveworks, którego szef ukuł termin „GitOps”. W tekście wyjaśniono istotę podejścia oraz najważniejsze różnice w stosunku do dotychczasowych.
Rok temu opublikowaliśmy . Opowiedzieliśmy wówczas, jak zespół Weaveworks uruchomił SaaS w całości oparty na Kubernetes i opracował zestaw najlepszych praktyk dotyczących wdrażania, zarządzania i monitorowania w natywnym środowisku chmurowym.
Artykuł okazał się popularny. Inni ludzie zaczęli mówić o GitOps i publikować nowe narzędzia , , , , i tak dalej. Pojawił się na naszej stronie publikacje i przypadki użycia GitOps. Ale niektórzy ludzie nadal mają pytania. Czym różni się ten model od tradycyjnego? i ciągłe dostarczanie ()? Czy konieczne jest korzystanie z Kubernetesa?
Szybko zdaliśmy sobie sprawę, że potrzebny jest nowy opis, oferujący:
- Duża liczba przykładów i historii;
- Specyficzna definicja GitOps;
- Porównanie z tradycyjną dostawą ciągłą.
W tym artykule staraliśmy się omówić wszystkie te tematy. Zawiera zaktualizowane wprowadzenie do GitOps oraz perspektywę programisty i CI/CD. Skupiamy się przede wszystkim na Kubernetesie, chociaż model można uogólnić.
Poznaj GitOps
Wyobraź sobie Alicję. Prowadzi firmę Family Insurance, która oferuje ubezpieczenia zdrowotne, samochodowe, mieszkaniowe i podróżne osobom, które są zbyt zapracowane, aby samodzielnie poznać tajniki umów. Jej działalność rozpoczęła się jako projekt poboczny, gdy Alice pracowała w banku jako analityk danych. Któregoś dnia zdała sobie sprawę, że może wykorzystać zaawansowane algorytmy komputerowe do skuteczniejszej analizy danych i formułowania pakietów ubezpieczeniowych. Inwestorzy sfinansowali projekt i obecnie jej firma przynosi ponad 20 milionów dolarów rocznie i dynamicznie się rozwija. Obecnie zatrudnia 180 osób na różnych stanowiskach. Obejmuje to zespół technologiczny, który opracowuje, utrzymuje witrynę internetową, bazę danych i analizuje bazę klientów. Na czele 60-osobowego zespołu stoi Bob, dyrektor techniczny firmy.
Zespół Boba wdraża systemy produkcyjne w chmurze. Ich podstawowe aplikacje działają w GKE i korzystają z Kubernetes w Google Cloud. Ponadto w swojej pracy korzystają z różnych narzędzi do przetwarzania danych i analiz.
Ubezpieczenie rodzinne nie miało zamiaru używać kontenerów, ale wpadło w entuzjazm Dockera. Firma szybko odkryła, że dzięki GKE wdrażanie klastrów w celu testowania nowych funkcji było łatwe i łatwe. Dodano Jenkinsa dla CI i Quay w celu zorganizowania rejestru kontenerów, napisano skrypty dla Jenkinsa, które wypchnęły nowe kontenery i konfiguracje do GKE.
Minęło trochę czasu. Alice i Bob byli rozczarowani skutecznością wybranego przez siebie podejścia i jego wpływem na biznes. Wprowadzenie kontenerów nie poprawiło produktywności w takim stopniu, jak liczył zespół. Czasami wdrożenia się psuły i nie było jasne, czy przyczyną są zmiany w kodzie. Śledzenie zmian w konfiguracji okazało się również trudne. Często konieczne było utworzenie nowego klastra i przeniesienie do niego aplikacji, ponieważ był to najłatwiejszy sposób na wyeliminowanie bałaganu, jaki powstał w systemie. Alicja obawiała się, że w miarę rozwoju aplikacji sytuacja będzie się pogarszać (dodatkowo przygotowywał się nowy projekt oparty na uczeniu maszynowym). Bob zautomatyzował większość pracy i nie rozumiał, dlaczego potok jest nadal niestabilny, słabo skalowany i wymaga okresowej interwencji ręcznej?
Potem dowiedzieli się o GitOps. Ta decyzja okazała się dokładnie tym, czego potrzebowali, aby pewnie ruszyć do przodu.
Alice i Bob od lat słyszą o Git, DevOps i infrastrukturze jako przepływach pracy związanych z kodem. Wyjątkowość GitOps polega na tym, że zapewnia zestaw najlepszych praktyk — zarówno ostatecznych, jak i normatywnych — służących wdrażaniu tych pomysłów w kontekście Kubernetes. Ten motyw , w tym w .
Family Insurance decyduje się na wdrożenie GitOps. Firma posiada teraz zautomatyzowany model działania, który jest kompatybilny z Kubernetesem i kombajnami prędkość poprzez stabilnośćponieważ oni:
- odkrył, że produktywność zespołu podwoiła się i nikt nie zwariował;
- przestał udostępniać skrypty. Zamiast tego mogą teraz skupić się na nowych funkcjach i udoskonalić metody inżynieryjne – na przykład wprowadzając wdrożenia Canary i ulepszając testowanie;
- usprawniliśmy proces wdrażania tak, aby rzadko ulegał awariom;
- uzyskano możliwość przywrócenia wdrożeń po częściowych awariach bez ręcznej interwencji;
- kupiony używanyоWiększe zaufanie do systemów dostaw. Alice i Bob odkryli, że mogą podzielić zespół na zespoły mikrousług pracujące równolegle;
- potrafi każdego dnia dokonać 30-50 zmian w projekcie dzięki wysiłkom każdej grupy i wypróbować nowe techniki;
- łatwo jest przyciągnąć do projektu nowych programistów, którzy mają możliwość wdrożenia aktualizacji na produkcję za pomocą pull requestów w ciągu kilku godzin;
- łatwo przejść audyt w ramach SOC2 (o przestrzeganiu przez usługodawców wymagań dotyczących bezpiecznego zarządzania danymi; czytaj więcej np. - około. tłumacz.).
Co się stało?
GitOps to dwie rzeczy:
- Model operacyjny dla Kubernetesa i cloud native. Zawiera zestaw najlepszych praktyk dotyczących wdrażania, zarządzania i monitorowania kontenerowych klastrów i aplikacji. Elegancka definicja w formie od :
- Ścieżka do stworzenia środowiska zarządzania aplikacjami zorientowanego na programistę. Stosujemy przepływ pracy Git zarówno w operacjach, jak i rozwoju. Pamiętaj, że nie chodzi tu tylko o wypychanie Gita, ale o uporządkowanie całego zestawu narzędzi CI/CD i UI/UX.
Kilka słów o Gicie
Jeśli nie znasz systemów kontroli wersji i przepływu pracy opartego na Git, zdecydowanie zalecamy zapoznanie się z nimi. Praca z gałęziami i żądaniami ściągnięcia może początkowo wydawać się czarną magią, ale korzyści są warte wysiłku. Tutaj zacząć.
Jak działa Kubernetes
W naszej historii Alice i Bob zwrócili się do GitOps po krótkiej pracy z Kubernetesem. Rzeczywiście, GitOps jest ściśle powiązany z Kubernetesem – jest to model operacyjny dla infrastruktury i aplikacji bazujących na Kubernetesie.
Co Kubernetes daje użytkownikom?
Oto kilka głównych funkcji:
- W modelu Kubernetesa wszystko można opisać w formie deklaratywnej.
- Serwer Kubernetes API przyjmuje tę deklarację jako dane wejściowe, a następnie stale próbuje doprowadzić klaster do stanu opisanego w deklaracji.
- Deklaracje wystarczą do opisania i zarządzania szeroką gamą obciążeń – „aplikacjami”.
- W rezultacie zachodzą zmiany w aplikacji i klastrze z powodu:
- zmiany w obrazach kontenerów;
- zmiany w specyfikacji deklaratywnej;
- błędy w środowisku - np. awaria kontenera.
Duże możliwości konwergencji Kubernetesa
Gdy administrator wprowadzi zmiany w konfiguracji, koordynator Kubernetes zastosuje je do klastra, o ile jego stan będzie aktualny nie zbliży się do nowej konfiguracji. Ten model działa w przypadku dowolnego zasobu Kubernetes i można go rozszerzyć za pomocą niestandardowych definicji zasobów (CRD). Dlatego wdrożenia Kubernetes mają następujące wspaniałe właściwości:
- Automatyzacja: Aktualizacje Kubernetes zapewniają mechanizm automatyzujący proces stosowania zmian sprawnie i terminowo.
- Konwergencja: Kubernetes będzie kontynuować próby aktualizacji, aż do skutku.
- Idempotencja: Powtarzające się zastosowania konwergencji prowadzą do tego samego rezultatu.
- Determinizm: Gdy zasoby są wystarczające, stan zaktualizowanego klastra zależy tylko od pożądanego stanu.
Jak działa GitOps
Dowiedzieliśmy się wystarczająco dużo o Kubernetesie, aby wyjaśnić, jak działa GitOps.
Wróćmy do zespołów mikrousług Family Insurance. Co zazwyczaj muszą zrobić? Spójrz na poniższą listę (jeśli jakiekolwiek elementy na niej wydają się dziwne lub nieznane, powstrzymaj się od krytykowania i pozostań z nami). To tylko przykłady przepływów pracy opartych na Jenkinsie. Podczas pracy z innymi narzędziami istnieje wiele innych procesów.
Najważniejsze jest to, że widzimy, że każda aktualizacja kończy się zmianami w plikach konfiguracyjnych i repozytoriach Git. Te zmiany w Git powodują, że „operator GitOps” aktualizuje klaster:
1. Proces pracy: "Kompilacja Jenkinsa - gałąź główna".
Lista zadań:
- Jenkins przesyła oznaczone zdjęcia do Quay;
- Jenkins wypycha konfigurację i wykresy Helm do głównego zasobnika pamięci;
- Funkcja chmury kopiuje konfigurację i wykresy z głównego zasobnika pamięci do głównego repozytorium Git;
- Operator GitOps aktualizuje klaster.
2. Kompilacja Jenkinsa — gałąź wydania lub poprawki:
- Jenkins przesyła nieoznaczone zdjęcia do Quay;
- Jenkins przesyła wykresy konfiguracji i Helm do zasobnika pamięci tymczasowej;
- Funkcja chmury kopiuje konfigurację i wykresy z zasobnika pamięci tymczasowej do tymczasowego repozytorium Git;
- Operator GitOps aktualizuje klaster.
3. Kompilacja Jenkinsa - rozwijaj lub rozwijaj gałąź:
- Jenkins przesyła nieoznaczone zdjęcia do Quay;
- Jenkins umieszcza wykresy konfiguracji i Helm w zasobniku pamięci masowej dla deweloperów;
- Funkcja chmury kopiuje konfigurację i wykresy z wiadra pamięci deweloperskiej do repozytorium Git dla deweloperów;
- Operator GitOps aktualizuje klaster.
4. Dodawanie nowego klienta:
- Menedżer lub administrator (LCM/ops) wywołuje Gradle, aby wstępnie wdrożyć i skonfigurować moduły równoważenia obciążenia sieciowego (NLB);
- LCM/ops zatwierdza nową konfigurację, aby przygotować wdrożenie do aktualizacji;
- Operator GitOps aktualizuje klaster.
Krótki opis GitOps
- Opisz pożądany stan całego systemu, używając specyfikacji deklaratywnych dla każdego środowiska (w naszej historii zespół Boba definiuje całą konfigurację systemu w Git).
- Repozytorium Git jest jedynym źródłem prawdy o pożądanym stanie całego systemu.
- Wszystkie zmiany żądanego stanu wprowadzane są poprzez zatwierdzenia w Git.
- Wszystkie pożądane parametry klastra można również zaobserwować w samym klastrze. W ten sposób możemy określić, czy są one zbieżne (zbiegają się, zbieżny) lub różnią się (odbiegają, odchodzić) stany pożądane i obserwowane.
- Jeżeli stany pożądane i obserwowane różnią się, to:
- Istnieje mechanizm konwergencji, który prędzej czy później automatycznie synchronizuje stan docelowy i obserwowany. Wewnątrz klastra robi to Kubernetes.
- Proces rozpoczyna się natychmiast od alertu „zmiana zatwierdzona”.
- Po pewnym konfigurowalnym okresie czasu może zostać wysłany alert „diff”, jeśli stany będą się różnić.
- W ten sposób wszystkie zatwierdzenia w Git powodują weryfikowalne i idempotentne aktualizacje klastra.
- Rollback to zbieżność do wcześniej pożądanego stanu.
- Zbieżność jest ostateczna. O jego wystąpieniu świadczą:
- Brak alertów różnicowych przez określony czas.
- Alert „konwergentny” (np. webhook, zdarzenie zapisu zwrotnego Git).
Czym jest rozbieżność?
Powtórzmy to jeszcze raz: wszystkie pożądane właściwości klastra muszą być obserwowalne w samym klastrze.
Kilka przykładów rozbieżności:
- Zmiana w pliku konfiguracyjnym w związku z łączeniem gałęzi w Git.
- Zmiana w pliku konfiguracyjnym spowodowana zatwierdzeniem Git dokonanym przez klienta GUI.
- Wiele zmian do pożądanego stanu z powodu PR w Git, po których następuje budowanie obrazu kontenera i zmiany konfiguracji.
- Zmiana stanu klastra na skutek błędu, konfliktu zasobów skutkującego „złym zachowaniem” lub po prostu przypadkowym odchyleniem od stanu pierwotnego.
Jaki jest mechanizm konwergencji?
Kilka przykładów:
- W przypadku kontenerów i klastrów mechanizm konwergencji zapewnia Kubernetes.
- Ten sam mechanizm można wykorzystać do zarządzania aplikacjami i projektami opartymi na Kubernetesie (takimi jak Istio i Kubeflow).
- Zapewnia mechanizm zarządzania interakcją operacyjną pomiędzy Kubernetesem, repozytoriami obrazów i Git , co jest częścią .
- W przypadku maszyn podstawowych mechanizm konwergencji musi być deklaratywny i autonomiczny. Z własnego doświadczenia możemy to powiedzieć najbliżej tej definicji, ale nadal wymaga kontroli człowieka. W tym sensie GitOps rozszerza tradycję Infrastruktury jako Kodu.
GitOps łączy Git z doskonałym silnikiem konwergencji Kubernetes, aby zapewnić model eksploatacji.
GitOps pozwala nam powiedzieć: Tylko te systemy, które można opisać i obserwować, można zautomatyzować i kontrolować.
GitOps jest przeznaczony dla całego stosu natywnego w chmurze (na przykład Terraform itp.)
GitOps to nie tylko Kubernetes. Chcemy, aby cały system był sterowany deklaratywnie i wykorzystywał konwergencję. Przez cały system rozumiemy zbiór środowisk współpracujących z Kubernetesem - np. „klaster deweloperski 1”, „produkcyjny” itp. Każde środowisko obejmuje maszyny, klastry, aplikacje, a także interfejsy dla usług zewnętrznych dostarczających dane, monitorujące i itp.
Zwróć uwagę, jak ważny jest Terraform dla problemu ładowania początkowego w tym przypadku. Kubernetes musi zostać gdzieś wdrożony, a korzystanie z Terraform oznacza, że możemy zastosować te same przepływy pracy GitOps, aby stworzyć warstwę kontroli, która stanowi podstawę Kubernetesa i aplikacji. Jest to przydatna, najlepsza praktyka.
Duży nacisk kładzie się na stosowanie koncepcji GitOps do warstw na platformie Kubernetes. W tej chwili dostępne są rozwiązania typu GitOps dla Istio, Helm, Ksonnet, OpenFaaS i Kubeflow, a także np. dla Pulumi, które tworzą warstwę do tworzenia aplikacji dla cloud native.
Kubernetes CI/CD: porównanie GitOps z innymi podejściami
Jak już wspomniano, GitOps to dwie rzeczy:
- Model operacyjny dla Kubernetesa i cloud native opisany powyżej.
- Ścieżka do środowiska zarządzania aplikacjami skupionego na programistach.
Dla wielu GitOps to przede wszystkim przepływ pracy oparty na wypychaniu Git. My też go lubimy. Ale to nie wszystko: przyjrzyjmy się teraz potokom CI/CD.
GitOps umożliwia ciągłe wdrażanie (CD) Kubernetes
GitOps oferuje mechanizm ciągłego wdrażania, który eliminuje potrzebę stosowania oddzielnych „systemów zarządzania wdrażaniem”. Kubernetes wykona całą pracę za Ciebie.
- Aktualizacja aplikacji wymaga aktualizacji w Git. Jest to aktualizacja transakcyjna do pożądanego stanu. „Wdrożenie” odbywa się wówczas w obrębie klastra przez sam Kubernetes na podstawie zaktualizowanego opisu.
- Ze względu na charakter działania Kubernetes aktualizacje te są zbieżne. Zapewnia to mechanizm ciągłego wdrażania, w którym wszystkie aktualizacje są niepodzielne.
- Uwaga: oferuje operator GitOps integrujący Git i Kubernetes oraz umożliwiający wykonanie CD poprzez uzgodnienie pożądanego i bieżącego stanu klastra.
Bez kubectl i skryptów
Powinieneś unikać używania Kubectl do aktualizacji klastra, a zwłaszcza unikać używania skryptów do grupowania poleceń kubectl. Zamiast tego za pomocą potoku GitOps użytkownik może zaktualizować swój klaster Kubernetes za pośrednictwem Git.
Korzyści obejmują:
- равильность. Można zastosować, połączyć i ostatecznie zweryfikować grupę aktualizacji, przybliżając nas do celu, jakim jest wdrożenie atomowe. Natomiast użycie skryptów nie daje żadnej gwarancji zbieżności (więcej na ten temat poniżej).
- bezpieczeństwo. Kelsey Hightower: „Ogranicz dostęp do klastra Kubernetes do narzędzi automatyzacji i administratorów odpowiedzialnych za jego debugowanie lub konserwację”. Zobacz też o bezpieczeństwie i zgodności ze specyfikacjami technicznymi, a także kradnąc dane uwierzytelniające z niedbale napisanego skryptu Jenkinsa.
- Doświadczenie użytkownika. Kubectl eksponuje mechanikę modelu obiektowego Kubernetes, który jest dość złożony. W idealnym przypadku użytkownicy powinni wchodzić w interakcję z systemem na wyższym poziomie abstrakcji. Tutaj ponownie nawiążę do Kelseya i polecam obejrzeć .
Różnica między CI a CD
GitOps ulepsza istniejące modele CI/CD.
Nowoczesny serwer CI to narzędzie do orkiestracji. W szczególności jest to narzędzie do orkiestracji potoków CI. Należą do nich kompilacja, testowanie, łączenie z magistralą itp. Serwery CI automatyzują zarządzanie złożonymi, wieloetapowymi potokami. Częstą pokusą jest utworzenie skryptu zestawu aktualizacji Kubernetes i uruchomienie go jako części potoku w celu wypchnięcia zmian do klastra. Rzeczywiście tak robi wielu ekspertów. Nie jest to jednak optymalne rozwiązanie i oto dlaczego.
Do przesyłania aktualizacji do magistrali należy używać CI, a klaster Kubernetes powinien się zmieniać na podstawie tych aktualizacji, aby wewnętrznie zarządzać dyskiem CD. Nazywamy to w przeciwieństwie do modelu push CI. Płyta CD jest częścią orkiestracja środowiska wykonawczego.
Dlaczego serwery CI nie powinny tworzyć płyt CD poprzez bezpośrednie aktualizacje w Kubernetes
Nie używaj serwera CI do organizowania bezpośrednich aktualizacji Kubernetes w postaci zestawu zadań CI. To jest antywzór, o którym mówimy na swoim blogu.
Wróćmy do Alicji i Boba.
Z jakimi problemami się borykali? Serwer CI Boba stosuje zmiany w klastrze, ale jeśli w trakcie tego procesu nastąpi awaria, Bob nie będzie wiedział, w jakim stanie jest klaster (lub powinien być) ani jak to naprawić. Podobnie jest w przypadku sukcesu.
Załóżmy, że zespół Boba zbudował nowy obraz, a następnie poprawił swoje wdrożenia, aby wdrożyć obraz (wszystko z potoku CI).
Jeśli obraz buduje się normalnie, ale potok nie działa, zespół będzie musiał ustalić:
- Czy aktualizacja została wdrożona?
- Czy uruchamiamy nową wersję? Czy doprowadzi to do niepotrzebnych skutków ubocznych – z możliwością posiadania dwóch kompilacji tego samego niezmiennego obrazu?
- Czy powinniśmy poczekać na następną aktualizację przed uruchomieniem kompilacji?
- Co dokładnie poszło nie tak? Które kroki należy powtórzyć (a które można bezpiecznie powtórzyć)?
Ustanowienie przepływu pracy opartego na Git nie gwarantuje, że zespół Boba nie napotka tych problemów. Nadal mogą popełnić błąd przy wysyłaniu zatwierdzenia, tagu lub innym parametrze; jednakże podejście to jest nadal znacznie bliższe wyraźnemu podejściu „wszystko albo nic”.
Podsumowując, oto dlaczego serwery CI nie powinny zajmować się CD:
- Skrypty aktualizacji nie zawsze są deterministyczne; Łatwo w nich popełnić błąd.
- Serwery CI nie są zbieżne z deklaratywnym modelem klastra.
- Trudno jest zagwarantować idempotencję. Użytkownicy muszą zrozumieć głęboką semantykę systemu.
- Trudniej jest odzyskać siły po częściowej awarii.
Uwaga dotycząca Helma: Jeśli chcesz używać Helma, zalecamy połączenie go z operatorem GitOps, takim jak . Pomoże to zapewnić konwergencję. Sam Helm nie jest ani deterministyczny, ani atomowy.
GitOps jako najlepszy sposób na wdrożenie Continuous Delivery dla Kubernetes
Zespół Alicji i Boba wdraża GitOps i odkrywa, że praca z oprogramowaniem, utrzymanie wysokiej wydajności i stabilności stało się znacznie łatwiejsze. Zakończmy ten artykuł ilustracją pokazującą, jak wygląda ich nowe podejście. Należy pamiętać, że mówimy głównie o aplikacjach i usługach, ale GitOps można wykorzystać do zarządzania całą platformą.
Model operacyjny dla Kubernetesa
Spójrz na poniższy diagram. Przedstawia Git i repozytorium obrazów kontenerów jako zasoby współdzielone dla dwóch zorganizowanych cykli życia:
- Potok ciągłej integracji, który odczytuje i zapisuje pliki w Git oraz może aktualizować repozytorium obrazów kontenerów.
- Potok Runtime GitOps, który łączy wdrażanie z zarządzaniem i obserwowalnością. Odczytuje i zapisuje pliki w Git oraz może pobierać obrazy kontenerów.
Jakie są główne ustalenia?
- Oddzielenie obaw: Należy pamiętać, że oba potoki mogą się komunikować tylko poprzez aktualizację Git lub repozytorium obrazów. Innymi słowy, pomiędzy CI a środowiskiem wykonawczym znajduje się zapora sieciowa. Nazywamy to „zaporą niezmienności” (zapora niezmienna), ponieważ wszystkie aktualizacje repozytorium tworzą nowe wersje. Więcej informacji na ten temat można znaleźć na slajdach 72-87 .
- Możesz użyć dowolnego serwera CI i Git: GitOps działa z dowolnym komponentem. Możesz nadal korzystać ze swoich ulubionych serwerów CI i Git, repozytoriów obrazów i zestawów testów. Prawie wszystkie inne narzędzia Continuous Delivery dostępne na rynku wymagają własnego serwera CI/Git lub repozytorium obrazów. Może to stać się czynnikiem ograniczającym rozwój rozwiązań chmurowych. Dzięki GitOps możesz używać znanych narzędzi.
- Eventy jako narzędzie integracji: Gdy tylko dane w Git zostaną zaktualizowane, Weave Flux (lub operator Weave Cloud) powiadamia środowisko wykonawcze. Za każdym razem, gdy Kubernetes akceptuje zestaw zmian, Git jest aktualizowany. Zapewnia to prosty model integracji do organizowania przepływów pracy dla GitOps, jak pokazano poniżej.
wniosek
GitOps zapewnia silne gwarancje aktualizacji wymagane przez każde nowoczesne narzędzie CI/CD:
- automatyzacja;
- konwergencja;
- idempotencja;
- determinizm.
Jest to ważne, ponieważ oferuje model operacyjny dla programistów natywnych w chmurze.
- Tradycyjne narzędzia do zarządzania i monitorowania systemów są powiązane z zespołami operacyjnymi działającymi w ramach elementu Runbook (zestaw rutynowych procedur i operacji - ok. przeł.), powiązane z konkretnym wdrożeniem.
- W zarządzaniu natywnym w chmurze narzędzia obserwowalności są najlepszym sposobem pomiaru wyników wdrożeń, dzięki czemu zespół programistów może szybko reagować.
Wyobraź sobie wiele klastrów rozproszonych w różnych chmurach i wiele usług z własnymi zespołami i planami wdrożeń. GitOps oferuje niezmienny pod względem skali model zarządzania całą tą obfitością.
PS od tłumacza
Przeczytaj także na naszym blogu:
- «";
- «";
- «".
W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. , Proszę.
Czy wiedziałeś o GitOps, zanim te dwa tłumaczenia pojawiły się na Habré?
-
Tak, wiedziałem wszystko
-
Tylko powierzchownie
-
Nie
Głosowało 35 użytkowników. 10 użytkowników wstrzymało się od głosu.
Źródło: www.habr.com