Notatka. przeł.: W społeczności Kubernetes trend zwany GitOps zyskuje wyraźną popularność, jak osobiście widzieliśmy, KubeCon Europe 2019. Termin ten powstał stosunkowo niedawno przez szefa Weaveworks – Alexisa Richardsona – i oznacza wykorzystanie narzędzi znanych programistom (przede wszystkim Git, stąd nazwa) do rozwiązywania problemów operacyjnych. W szczególności mówimy o działaniu Kubernetesa poprzez przechowywanie jego konfiguracji w Git i automatyczne wdrażanie zmian do klastra. Matthias Jg omawia w tym artykule dwa podejścia do tego wdrożenia.
W zeszłym roku, (właściwie formalnie stało się to w sierpniu 2017 r. – ok. tł.) Pojawiło się nowe podejście do wdrażania aplikacji w Kubernetesie. Nazywa się to GitOps i opiera się na podstawowej idei, że wersje wdrożeniowe są śledzone w bezpiecznym środowisku repozytorium Git.
Główne zalety tego podejścia są następujące::
- Wersjonowanie wdrożeń i historia zmian. Stan całego klastra jest przechowywany w repozytorium Git, a wdrożenia są aktualizowane tylko poprzez zatwierdzenia. Ponadto wszystkie zmiany można śledzić za pomocą historii zatwierdzeń.
- Wycofywanie przy użyciu znanych poleceń Git. Prosty
git resetumożliwia resetowanie zmian w wdrożeniach; stany przeszłe są zawsze dostępne. - Gotowa kontrola dostępu. Zazwyczaj system Git zawiera dużo wrażliwych danych, dlatego większość firm przywiązuje szczególną wagę do ich ochrony. W związku z tym ochrona ta dotyczy również operacji związanych z wdrożeniami.
- Zasady dotyczące wdrożeń. Większość systemów Git natywnie obsługuje zasady dotyczące poszczególnych gałęzi — na przykład tylko żądania ściągnięcia mogą zaktualizować plik główny, a zmiany muszą zostać sprawdzone i zaakceptowane przez innego członka zespołu. Podobnie jak w przypadku kontroli dostępu, te same zasady dotyczą aktualizacji wdrożeniowych.
Jak widać, metoda GitOps ma wiele zalet. W ciągu ostatniego roku szczególną popularność zyskały dwa podejścia. Jeden opiera się na push, drugi na pull. Zanim się im przyjrzymy, przyjrzyjmy się najpierw, jak wyglądają typowe wdrożenia Kubernetes.
Metody wdrażania
W ostatnich latach w Kubernetes ugruntowały się różne metody i narzędzia wdrożeń:
- W oparciu o natywne szablony Kubernetes/Kustomize. To najłatwiejszy sposób wdrażania aplikacji na Kubernetesie. Programista tworzy podstawowe pliki YAML i stosuje je. Aby pozbyć się ciągłego przepisywania tych samych szablonów, opracowano Kustomize (zamienia szablony Kubernetesa w moduły). Notatka. przeł.: Kustomize został zintegrowany z kubectl z .
- Wykresy Helma. Wykresy Helm umożliwiają tworzenie zestawów szablonów, kontenerów init, przyczepek itp., które służą do wdrażania aplikacji z bardziej elastycznymi opcjami dostosowywania niż w przypadku podejścia opartego na szablonach. Metoda ta opiera się na szablonach plików YAML. Helm wypełnia je różnymi parametrami, a następnie wysyła je do Tillera, komponentu klastra, który wdraża je w klastrze i umożliwia aktualizacje i wycofywanie zmian. Ważne jest to, że Helm w zasadzie po prostu wstawia pożądane wartości do szablonów, a następnie stosuje je w taki sam sposób, jak dzieje się to w tradycyjnym podejściu (więcej o tym, jak to wszystko działa i jak można z niego korzystać, przeczytasz w naszym - około. tłumacz.). Istnieje szeroka gama gotowych wykresów Helma obejmujących szeroki zakres zadań.
- Narzędzia alternatywne. Istnieje wiele alternatywnych narzędzi. Łączy je to, że przekształcają niektóre pliki szablonów w pliki YAML czytelne dla Kubernetesa, a następnie ich używają.
W naszej pracy stale wykorzystujemy wykresy Helma do ważnych narzędzi (ponieważ mają już wiele gotowych rzeczy, co znacznie ułatwia życie) oraz „czyste” pliki Kubernetes YAML do wdrażania własnych aplikacji.
Ciągnąć pchać
W jednym z moich ostatnich wpisów na blogu przedstawiłem to narzędzie , co umożliwia zatwierdzenie szablonów w repozytorium Git i aktualizację wdrożenia po każdym zatwierdzeniu lub wypchnięciu kontenera. Z mojego doświadczenia wynika, że to narzędzie jest jednym z głównych w promowaniu podejścia pull, dlatego będę często do niego odnosić się. Jeśli chcesz dowiedzieć się więcej o tym, jak z niego korzystać, tutaj .
UWAGA! Wszystkie zalety korzystania z GitOps pozostają takie same w przypadku obu podejść.
Podejście oparte na przyciąganiu
Podejście pull opiera się na tym, że wszystkie zmiany są stosowane z poziomu klastra. Wewnątrz klastra znajduje się operator, który regularnie sprawdza powiązane repozytoria Git i Docker Registry. Jeśli wystąpią w nich jakiekolwiek zmiany, stan klastra jest aktualizowany wewnętrznie. Proces ten jest ogólnie uważany za bardzo bezpieczny, ponieważ żaden klient zewnętrzny nie ma dostępu do uprawnień administratora klastra.
Plusy:
- Żaden klient zewnętrzny nie ma uprawnień do wprowadzania zmian w klastrze; wszystkie aktualizacje są wdrażane od wewnątrz.
- Niektóre narzędzia umożliwiają także synchronizację aktualizacji wykresów Helm i łączenie ich z klastrem.
- Rejestr Dockera można przeskanować w poszukiwaniu nowych wersji. Jeśli dostępny jest nowy obraz, repozytorium Git i wdrożenie zostaną zaktualizowane do nowej wersji.
- Narzędzia do ściągania mogą być dystrybuowane w różnych przestrzeniach nazw z różnymi repozytoriami Git i uprawnieniami. Dzięki temu można zastosować model multitenant. Na przykład zespół A może używać przestrzeni nazw A, zespół B może używać przestrzeni nazw B, a zespół ds. infrastruktury może używać przestrzeni globalnej.
- Z reguły narzędzia są bardzo lekkie.
- W połączeniu z narzędziami takimi jak operator sekrety mogą być przechowywane w postaci zaszyfrowanej w repozytorium Git i pobierane w klastrze.
- Nie ma połączenia z potokami CD, ponieważ wdrożenia odbywają się w klastrze.
Wady:
- Zarządzanie sekretami wdrożenia z wykresów Helma jest trudniejsze niż zwykłych, ponieważ najpierw muszą zostać wygenerowane w formie, powiedzmy, zapieczętowanych sekretów, następnie odszyfrowane przez operatora wewnętrznego i dopiero potem stają się dostępne dla narzędzia do ściągania. Następnie możesz uruchomić wydanie w Helmie z wartościami w już wdrożonych sekretach. Najłatwiej jest utworzyć sekret ze wszystkimi wartościami Helma używanymi do wdrożenia, odszyfrować go i przekazać do Git.
- Kiedy zastosujesz metodę ciągnięcia, zostaniesz przywiązany do narzędzi ciągnięcia. Ogranicza to możliwość dostosowania procesu wdrażania w klastrze. Na przykład Kustomize jest skomplikowane przez fakt, że musi zostać uruchomione, zanim ostateczne szablony zostaną zapisane w Git. Nie twierdzę, że nie można używać samodzielnych narzędzi, ale trudniej jest je zintegrować z procesem wdrażania.
Podejście oparte na pushie
W podejściu push system zewnętrzny (głównie potoki CD) uruchamia wdrożenia w klastrze po zatwierdzeniu w repozytorium Git lub po pomyślnym zakończeniu poprzedniego potoku CI. W tym podejściu system ma dostęp do klastra.
Plusy:
- Bezpieczeństwo jest określane przez repozytorium Git i potok kompilacji.
- Wdrażanie wykresów Helm jest łatwiejsze i obsługuje wtyczki Helm.
- Sekrety są łatwiejsze w zarządzaniu, ponieważ mogą być używane w potokach, a także mogą być przechowywane w postaci zaszyfrowanej w Git (w zależności od preferencji użytkownika).
- Nie ma połączenia z konkretnym narzędziem, ponieważ można zastosować dowolny typ.
- Aktualizacje wersji kontenera mogą być inicjowane przez potok kompilacji.
Wady:
- Dane dostępu do klastra znajdują się w systemie kompilacji.
- Aktualizowanie kontenerów wdrożeniowych jest nadal łatwiejsze dzięki procesowi ściągania.
- Duża zależność od systemu CD, ponieważ potrzebne nam potoki mogły zostać pierwotnie napisane dla Gitlab Runners, a następnie zespół decyduje się na przejście do Azure DevOps lub Jenkins... i będzie musiał migrować dużą liczbę potoków kompilacji.
Wyniki: pchanie czy ciągnięcie?
Jak to zwykle bywa, każde podejście ma swoje wady i zalety. Niektóre zadania są łatwiejsze do wykonania przy użyciu jednego, a trudniejsze przy innym. Na początku robiłem wdrożenia ręcznie, ale po tym jak natknąłem się na kilka artykułów o Weave Flux, zdecydowałem się na wdrożenie procesów GitOps dla wszystkich projektów. W przypadku podstawowych szablonów było to łatwe, ale potem zacząłem napotykać problemy z wykresami Helma. W tamtym czasie Weave Flux oferował jedynie podstawową wersję Operatora mapy steru, ale nawet teraz niektóre zadania są trudniejsze ze względu na konieczność ręcznego tworzenia sekretów i ich stosowania. Można argumentować, że metoda ściągania jest znacznie bezpieczniejsza, ponieważ poświadczenia klastra nie są dostępne poza klastrem, co poprawia bezpieczeństwo na tyle, że warto podjąć dodatkowy wysiłek.
Po chwili namysłu doszedłem do nieoczekiwanego wniosku, że tak nie jest. Jeśli mówimy o komponentach wymagających maksymalnej ochrony, lista ta będzie obejmować tajne przechowywanie, systemy CI/CD i repozytoria Git. Znajdujące się w nich informacje są bardzo wrażliwe i wymagają maksymalnej ochrony. Dodatkowo, jeśli ktoś dostanie się do Twojego repozytorium Git i będzie mógł tam wypchnąć kod, może wdrożyć, co chce (czy to metodą pull, czy push) i zinfiltrować systemy klastra. Zatem najważniejszymi komponentami, które należy chronić, są repozytorium Git i systemy CI/CD, a nie dane uwierzytelniające klastra. Jeśli masz dobrze skonfigurowane zasady i mechanizmy kontroli bezpieczeństwa dla tego typu systemów, a poświadczenia klastra są wyodrębniane do potoków jedynie jako sekrety, dodatkowe bezpieczeństwo wynikające z metody ściągania może nie być tak cenne, jak początkowo sądzono.
Jeśli zatem podejście pull jest bardziej pracochłonne i nie zapewnia korzyści w zakresie bezpieczeństwa, czy logiczne nie jest stosowanie wyłącznie podejścia push? Ktoś jednak mógłby zarzucić, że w podejściu push jest się za bardzo przywiązanym do systemu CD i może lepiej tego nie robić, żeby w przyszłości łatwiej było przeprowadzać migracje.
Moim zdaniem (jak zawsze) należy zastosować to, co w danym przypadku najbardziej pasuje lub połączyć. Osobiście stosuję oba podejścia: Weave Flux do wdrożeń opartych na ściąganiu, które obejmują głównie nasze własne usługi, oraz podejście push z Helmem i wtyczkami, które ułatwia stosowanie wykresów Helm do klastra i pozwala na płynne tworzenie sekretów. Myślę, że nigdy nie będzie jednego rozwiązania odpowiedniego dla wszystkich przypadków, ponieważ zawsze jest wiele niuansów i zależą one od konkretnego zastosowania. Biorąc to pod uwagę, bardzo polecam GitOps - znacznie ułatwia życie i poprawia bezpieczeństwo.
Mam nadzieję, że moje doświadczenie w tym temacie pomoże Ci zdecydować, która metoda jest bardziej odpowiednia dla Twojego rodzaju wdrożenia. Chętnie poznam Twoją opinię.
PS Notatka od tłumacza
Wadą modelu ściągania jest to, że trudno jest umieścić wyrenderowane manifesty w Git, ale nie ma tej wady, że potok CD w modelu ściągania działa oddzielnie od wdrożenia i zasadniczo staje się potokiem kategorii Ciągłe stosowanie. Dlatego jeszcze więcej wysiłku będzie wymagało zebranie ich statusu ze wszystkich wdrożeń i zapewnienie w jakiś sposób dostępu do logów/statusu, najlepiej w odniesieniu do systemu CD.
W tym sensie model push pozwala nam zapewnić przynajmniej pewne gwarancje wdrożenia, ponieważ czas życia rurociągu można zrównać z czasem życia wdrożenia.
Wypróbowaliśmy oba modele i doszliśmy do tych samych wniosków, co autor artykułu:
- Model pull nadaje się do organizowania aktualizacji komponentów systemu na dużej liczbie klastrów (patrz. ).
- Model push oparty na GitLab CI dobrze nadaje się do wdrażania aplikacji przy użyciu wykresów Helma. Jednocześnie za pomocą narzędzia monitorowany jest przebieg wdrożeń w ramach rurociągów . Swoją drogą, w kontekście tego naszego projektu, podczas omawiania palących problemów inżynierów DevOps na naszym stoisku na KubeCon Europe'19 słyszeliśmy ciągłe „GitOps”.
PPS od tłumacza
Przeczytaj także na naszym blogu:
- «";
- «";
- «";
- «".
W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. , Proszę.
Czy korzystasz z GitOpsa?
-
Tak, podejście ciągnące
-
Tak, pchnij
-
Tak, pociągnij + pchnij
-
Tak, coś innego
-
Nie
Głosowało 30 użytkowników. 10 użytkowników wstrzymało się od głosu.
Źródło: www.habr.com