🥇GitOps: porównanie metod Pull i Push

Przyp. tłum.: W społeczności Kubernetes zyskuje na popularności trend zwany GitOps, w co osobiście się przekonaliśmy, uczestnicząc w KubeCon Europe 2019. Termin ten został stworzony stosunkowo niedawno przez szefa firmy Weaveworks — Alexisa Richardsona — i oznacza stosowanie znanych deweloperom narzędzi (przede wszystkim — Git, stąd nazwa) do rozwiązywania problemów związanych z eksploatacją. W szczególności chodzi o eksploatację Kubernetes poprzez przechowywanie jego konfiguracji w Git i automatyczne wdrażanie zmian w klastrze. O dwóch podejściach do tego wdrażania opowiada Matthias Jg w tym artykule. W zeszłym roku

GitOps: porównanie metod Pull i Push

(w rzeczywistości formalnie miało to miejsce w sierpniu 2017 r. — przyp. tłum.) pojawiło się nowe podejście do wdrażania aplikacji w Kubernetes. Nazywa się GitOps i jego podstawową ideą jest to, że wersjonowanie deploymentów odbywa się w bezpiecznym środowisku repozytorium Git. Główne zalety tego podejścia są następujące

Wersjonowanie deploymentów i historia zmian:

. Stan całego klastra jest przechowywany w repozytorium Git, a deploymenty są aktualizowane tylko poprzez commity. Ponadto wszystkie zmiany można śledzić za pomocą historii commitów.Odzyskiwanie za pomocą znanych poleceń Git
. Prostagit reset pozwala na cofanie zmian w deploymentach; zawsze dostępne są poprzednie stany. Gotowa kontrola dostępu
. Zwykle system Git zawiera wiele poufnych danych, dlatego większość firm zwraca szczególną uwagę na jego zabezpieczenia. Odpowiednio, ta ochrona obejmuje również operacje związane z deploymentami.Polityki dla wdrożeń
. Większość systemów Git domyślnie wspiera polityki dla różnych gałęzi — na przykład tylko pull requesty mogą aktualizować master, a zmiany muszą być zweryfikowane i zaakceptowane przez innego członka zespołu. Podobnie jak w przypadku kontroli dostępu, te same polityki stosuje się do aktualizacji deploymentów.Jak widać, metoda GitOps ma wiele zalet. W ciągu ostatniego roku szczególną popularność zdobyły dwa podejścia. Jedno opiera się na push, drugie — na pull. Zanim je omówimy, przyjrzyjmy się najpierw, jak wyglądają typowe deploymenty Kubernetes.

Metody wdrażania

W ciągu ostatnich kilku lat w Kubernetes ugruntowały się różne metody i narzędzia do wdrażania:

Na podstawie rodzimych szablonów Kubernetes/Kustomize

Na podstawie natywnych szablonów Kubernetes/KustomizeTo najprostszy sposób wdrażania aplikacji w Kubernetes. Programista tworzy podstawowe pliki YAML i je stosuje. Aby uniknąć ciągłego przepisywania tych samych szablonów, stworzono Kustomize (przekształca szablony Kubernetes w moduły). Przyp. tłum.: Kustomize został zintegrowany z kubectl w wydaniu Kubernetes 1.14.
Chartów Helm. Chartów Helm umożliwiają tworzenie zestawów szablonów, kontenerów inicjalizacyjnych, sidecarów itp., które są stosowane do wdrażania aplikacji z bardziej elastycznymi możliwościami konfiguracji niż w podejściu opartym na szablonach. W podstawie tej metody leżą szablonizowane pliki YAML. Helm wypełnia je różnymi parametrami, a następnie wysyła do Tiller — komponentu klastra, który wdraża je w klastrze i umożliwia aktualizacje oraz rollbacki. Ważne, że Helm po prostu wstawia odpowiednie wartości do szablonów i stosuje je tak samo, jak w tradycyjnym podejściu. (więcej o tym, jak to działa i jak można to wykorzystać, przeczytaj w naszej artykuł o Helm — przyp. tłum.). Istnieje wiele gotowych chartów Helm, obejmujących szeroki zakres zadań.
Alternatywne narzędzia. Istnieje wiele alternatywnych narzędzi. Wszystkie łączą, że przekształcają pewne pliki szablonów w zrozumiałe pliki YAML Kubernetes, a następnie je stosują.

W naszej pracy stale korzystamy z chartów Helm do ważnych narzędzi (ponieważ wiele z nich jest już gotowych, co znacznie ułatwia życie) oraz 'czystych' plików YAML Kubernetes do wdrażania własnych aplikacji.

Pull & Push

W jednym z moich ostatnich wpisów na blogu przedstawiłem narzędzie Weave Flux, które umożliwia commitowanie szablonów do repozytorium Git i aktualizowanie wdrożenia po każdym commicie lub pushu kontenera. Moje doświadczenie pokazuje, że to narzędzie jest jednym z kluczowych w promowaniu podejścia pull, dlatego będę często na nie powoływać. Jeśli chcesz się dowiedzieć więcej o tym, jak je używać, oto link do artykułu.

NB! Wszystkie zalety korzystania z GitOps są zachowane w obu podejściach.

Podejście oparte na Pull

GitOps: porównanie metod Pull i Push

Podstawą podejścia pull jest fakt, że wszystkie zmiany są wprowadzane wewnątrz klastra. W obrębie klastra znajduje się operator, który regularnie sprawdza powiązane repozytoria Git i Docker Registry. Jeśli dochodzi w nich do jakichkolwiek zmian, stan klastra jest aktualizowany od wewnątrz. Zazwyczaj uważa się, że taki proces jest dość bezpieczny, ponieważ żaden zewnętrzny klient nie ma dostępu do praw administracyjnych klastra.

Zalety:

Żaden zewnętrzny klient nie ma uprawnień do wprowadzania zmian w klastrze, wszystkie aktualizacje są wprowadzane od wewnątrz.
Niektóre narzędzia pozwalają również synchronizować aktualizacje Helm chartów i powiązywać je z klastrem.
Docker Registry można skanować w poszukiwaniu nowych wersji. Jeśli nowy obraz się pojawia, repozytorium Git i wdrożenie są aktualizowane do nowej wersji.
Narzędzia pull mogą być rozdzielone na różne przestrzenie nazw z różnymi repozytoriami Git i uprawnieniami dostępu. Dzięki temu można zastosować model wielodostępowy (multitenant). Na przykład zespół A może korzystać z przestrzeni nazw A, zespół B — z przestrzeni nazw B, a zespół zajmujący się infrastrukturą może korzystać z przestrzeni globalnej.
Zazwyczaj narzędzia są dość lekkie.
W połączeniu z takimi narzędziami jak operator Bitnami Sealed Secrets, sekrety mogą być przechowywane w zaszyfrowanej formie w repozytorium Git i wydobywane wewnątrz klastra.
Brak połączenia z pipeline'ami CD, ponieważ wdrożenia odbywają się wewnątrz klastra.

Minusy:

Zarządzanie sekretami wdrożeń z Helm chartów jest trudniejsze niż standardowymi, ponieważ najpierw muszą być generowane w formie, powiedzmy, sealed secrets, następnie odszyfrowywane przez wewnętrznego operatora i dopiero potem stają się dostępne dla narzędzia pull. Następnie można uruchomić wydanie w Helm z wartościami w już wdrożonych sekretach. Najprostszym sposobem jest stworzenie sekretu ze wszystkimi wartościami Helm używanymi do wdrożenia, odszyfrowanie go i zatwierdzenie w Git.
Używając podejścia pull, jesteś związany z narzędziami działającymi na pull'ach. Ogranicza to możliwości dostosowania procesu wdrażania w klastrze. Na przykład praca z Kustomize jest utrudniona, ponieważ musi być wykonywana przed złożeniem ostatecznych szablonów do repozytorium Git. Nie mówię, że nie można używać oddzielnych narzędzi, ale ich integracja w procesie wdrażania jest trudniejsza.

Podejście oparte na Push

GitOps: porównanie metod Pull i Push

W podejściu push zewnętrzny system (głównie pipeline'y CD) uruchamia wdrożenia w klastrze po zatwierdzeniu w repozytorium Git lub po pomyślnym zakończeniu poprzedniego pipeline'a CI. W tym podejściu system ma dostęp do klastra.

Zalety:

Bezpieczeństwo jest określane przez repozytorium Git i pipeline budowy.
Wdrażanie chartów Helm jest prostsze, istnieje wsparcie dla wtyczek Helm.
Zarządzanie sekretami jest łatwiejsze, ponieważ sekrety można stosować w pipeline'ach, a także przechowywać w Git w zaszyfrowanej formie (w zależności od preferencji użytkownika).
Brak przywiązania do konkretnego narzędzia, ponieważ można używać różnych ich typów.
Aktualizacje wersji kontenerów mogą być inicjowane przez pipeline budowy.

Minusy:

Dane do dostępu do klastra znajdują się wewnątrz systemu budowy.
Aktualizowanie kontenerów wdrożeń wciąż jest prostsze przy pomocy procesu pull.
Silne uzależnienie od systemu CD, ponieważ potrzebne pipeline'y mogą być pierwotnie napisane pod GitLab Runners, a później zespół zdecyduje się przejść na Azure DevOps lub Jenkins… więc będzie konieczne przeprowadzenie migracji dużej liczby pipeline'ów budowy.

Podsumowanie: Push czy Pull?

Jak to zwykle bywa, każdy z podejść ma swoje zalety i wady. Niektóre zadania łatwiej wykonać jednym sposobem, a trudniej innym. Na początku przeprowadzałem wdrożenia ręcznie, ale po natknięciu się na kilka artykułów o Weave Flux postanowiłem wdrożyć procesy GitOps dla wszystkich projektów. Dla podstawowych szablonów okazało się to łatwe, ale potem zacząłem napotykać trudności w pracy z chartami Helm. W tamtym czasie Weave Flux oferował tylko wczesną wersję operatora Helm Chart, ale nawet teraz niektóre zadania są trudniejsze z powodu konieczności ręcznego tworzenia sekretów i ich stosowania. Można powiedzieć, że podejście pull jest znacznie bardziej zabezpieczone, ponieważ dane uwierzytelniające klastra nie są dostępne poza nim, co tak bardzo zwiększa bezpieczeństwo, że warto ponieść dodatkowy wysiłek.

Po chwili refleksji doszedłem do zaskakującego wniosku, że nie jest to prawda. Mówiąc o komponentach, które wymagają maksymalnej ochrony, w takim zestawieniu znajdą się magazyny sekretów i systemy CI/CD, a także repozytoria Git. Informacje w nich są dość wrażliwe i potrzebują maksymalnej ochrony. Co więcej, jeśli ktoś dostanie się do twojego repozytorium Git i będzie w stanie do niego wysłać kod, to będzie mógł wdrożyć wszystko, co zechce (bez względu na to, czy będzie to podejście pull czy push), i wniknąć w systemy klastra. Dlatego najważniejszymi komponentami, które wymagają ochrony, są repozytorium Git oraz systemy CI/CD, a nie dane uwierzytelniające klastra. Jeśli masz dobrze skonfigurowane polityki i środki bezpieczeństwa dla takich systemów, a dane uwierzytelniające klastra są wydobywane do potoków tylko w postaci sekretów, dodatkowe bezpieczeństwo podejścia pull może nie być tak cenne, jak początkowo zakładano.

Zatem, jeśli podejście pull jest bardziej pracochłonne i nie przynosi korzyści w zakresie bezpieczeństwa, czy nie byłoby logiczne używać tylko podejścia push? Ale ktoś może zauważyć, że w podejściu push jesteś zbyt uzależniony od systemu CD i być może lepiej jest tego nie robić, aby w przyszłości ułatwić migracje.

Moim zdaniem (jak zawsze) należy używać tego, co najlepiej pasuje do konkretnej sytuacji lub łączyć różne podejścia. Osobiście korzystam z obu strategii: Weave Flux do wdrożeń opartych na pull, które głównie obejmują nasze własne usługi, oraz podejścia push z Helm i wtyczkami, co ułatwia zastosowanie chartów Helm w klastrze i pozwala na bezproblemowe tworzenie sekretów. Myślę, że nigdy nie będzie jedno idealne rozwiązanie pasujące do wszystkich przypadków, ponieważ zawsze jest wiele niuansów, a te zależą od konkretnego zastosowania. Przy tym gorąco polecam GitOps — znacznie ułatwia to życie i zwiększa bezpieczeństwo.

Mam nadzieję, że moje doświadczenie w tej dziedzinie pomoże zdecydować, która metoda najlepiej pasuje do Twojego rodzaju wdrożeń, a ja chętnie usłyszę Twoją opinię.

P.S. Notka od tłumacza

W minusach modelu pull pojawia się punkt mówiący o trudnościach z umieszczaniem odrenderowanych manifestów w Git, jednak nie ma minusów, że pipeline CD w modelu pull działa oddzielnie od wdrożeń i w zasadzie staje się pipeline'em z kategorii Continuous Apply. Dlatego potrzebne będą jeszcze większe wysiłki, aby zbierać statusy ze wszystkich wdrożeń i jakoś udostępniać logi/status, najlepiej z powiązaniem do systemu CD.

W tym sensie model push pozwala na zapewnienie jakichkolwiek gwarancji wdrożeń, ponieważ czas życia pipeline'a można związać z czasem życia wdrożeń.

Wypróbowaliśmy oba modele i doszliśmy do tych samych wniosków co autor artykułu:

Model pull nadaje się do organizacji aktualizacji komponentów systemowych w dużej liczbie klastrów (patrz artykuł o addon-operatorze).
Model push oparty na GitLab CI doskonale nadaje się do wdrożeń aplikacji za pomocą chartów Helm. W tym przypadku wdrożenia w ramach pipeline'ów są śledzone za pomocą narzędzia werf. Swoją drogą, w kontekście tego naszego projektu często słyszeliśmy "GitOps", kiedy omawialiśmy bieżące problemy inżynierów DevOps przy naszym stoisku na KubeCon Europe'19.